A few days ago, while trying to compile a BizTalk Server solution, I encountered the following error: “Invalid type name.” The root node type has to be a valid C# identifier. I ended up solving this problem, but while I was preparing this post, I realized that the cause and respective solution that I thought were behind this error were, in fact, incomplete and not accurate.
Most of the documentation available states that:
- The .NET Framework doesn’t allow the “-” within TypeNames because the “-” is reserved.
- The use of a hyphen (-) in RootNode TypeName is not allowed.
And that statement is incorrect, or at least incomplete!
📝 One-Minute Brief
A deep‑dive explanation of the BizTalk schema error “Invalid type name,” clarifying how RootNode TypeName and NodeName behave, why hyphens sometimes work, and what truly causes the error during schema compilation.
1) What happens if I create a root node with hyphens (-)?
If we create a root node with hyphens, let’s say My-NAME-SANDRO, by default, the:
- The NodeName property will be set as My-NAME-SANDRO.
- And the RootName TypeName property will also be set as My-NAME-SANDRO.
And as you can see in the picture below, you will be able to create a schema with one or more hyphens (-) on the root node name and type name; in fact, they should be the same if you only have one root node in the schema.
And again, as you see in the picture, you will be able to build and deploy it with success.
But let’s play a little in order to demystify this Invalid type error that sometimes happens.
2) What happens if we try to change the “RootNode TypeName” property to another value, like “MyNAMESANDRO” – without any hyphens (-)?
Nothing will happen; we will still be able to compile and successfully deploy our schema.
In fact, this is the best approach.
3) Now, what happens if we try to change the “RootNode TypeName” property to another value, like “My-NAMESANDRO” – with hyphens (-)?
Note that we are changing to a RootNode TypeName property to a different value than the Node Name, but this time including one or more hyphens (-).
If we try to do that, we will receive the following error:
Invalid type name. The root node type name has to be a valid C# identifier. It cannot be same as the type name of any other root nodes in this schema
Cause
Official Microsoft documentation states that the Type Name property of this schema file is not valid. Because the value of the Type Name property is used as the name of an automatically generated C# class name, it must be a valid C# identifier and cannot be a reserved BizTalk keyword.
In fact, it will not allow any hyphens or other punctuations like “.”, “!” and so on, with the exception of the underscore (_)… directly from the BizTalk Editor – we will get that sorted out (properly cleared) later.
Solution
As hyphens, or any other punctuation characters, are not allowed, you should remove them from the RootNode TypeName property. For example:
- For the node My-NANE-SANDRO, the RootNode TypeName value can be MyNAMESANDRO or My_NAME-SANDRO instead of My-NAMESANDRO or even My-NAME_SANDRO.
By removing all hyphens or any other punctuation characters from this property in all schemas, you will guarantee that you will not face this issue again, at least in this project.
4) I changed to “MyNAMESANDRO”. What happens if we try to roll back and change the “RootNode TypeName” property again to the original “My-NAME-SANDRO”?
Here’s where the story becomes funny: it will fail!
Humm… what? How is that possible if in point 1 we saw that if the root node name and type name are the same, it should work, and it did work before?
Cause
Again, the official Microsoft documentation states that the Type Name property of this schema file is invalid. Because the value of the Type Name property is used as the name of an automatically generated C# class name, it must be a valid C# identifier and cannot be a reserved BizTalk keyword.
In fact, once you change the name for something else without hyphens or any other punctuation characters, you cannot roll back to the origin (or default) RootName TypeName My-NAME-SANDRO.
Solution
The same solution here, like a hyphen, or any other punctuation character, is not allowed; you should remove them from the RootNode TypeName property. For example:
- For the node My-NANE-SANDRO, the RootNode TypeName value can be MyNAMESANDRO instead of My-NAMESANDRO or even My-NAME_SANDRO.
However, if you want to rollback to the default RootNode TypeName value, you need to delete the root node and recreate it from scratch, at least directly from the BizTalk Schema Editor.
What is actually the Cause
I think at some point in the past, this was a limitation, or maybe a limitation in certain scenarios (we will check this on Part II later on in a different blog), but not really at the moment, or in this case: a schema with a single root node.
So, if it worked in the first approach – point 1 – why doesn’t it work in the other approaches – point 3 and 4?
Well, in this case, this is just a BizTalk Schema Editor limitation or bug, but let’s call it a limitation.
What is actually the Solution
To solve points 3 and 4, you just need to open the Schema with XML (Text) Editor:
And fix the rootTypeName for the value you want: My-NAMESANDRO or back to My-NAME-SANDRO.
<?xml version="1.0" encoding="utf-16"?>
<xs:schema xmlns="http://BizTalk_Server_Project1.Schema1" xmlns:b="http://schemas.microsoft.com/BizTalk/2003" targetNamespace="http://BizTalk_Server_Project1.Schema1" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="My-NAME-SANDRO">
<xs:annotation>
<xs:appinfo>
<b:recordInfo rootTypeName="My-NAMESANDRO" />
</xs:appinfo>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="First-Name" type="xs:string" />
<xs:element name="Last_Name" type="xs:string" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
Save it, you can now open it again with BizTalk Schema Editor, compile it, and deploy it without any problem.
Keep posted for Part II of this blog post.
Hope you find this helpful! If you liked the content or found it useful and would like to support me in writing more, consider buying (or helping to buy) a Star Wars Lego set for my son.
