Demystify Invalid type name error on BizTalk Schemas (Part I)

Demystify Invalid type name error on BizTalk Schemas (Part I)

A few days ago, while trying to compile a BizTalk Server solution I got the following error: Invalid type name. The root node type has to be a valid C# identifier. I end up solving this problem but while I was preparing this post the reason I realize that the cause and respective solution that I thought to be behind this error was, in fact, incomplete and not accurate.

Most of the documentation available state 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!

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 a 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.

BizTalk Schemas: Invalid type name doesn't happen

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 other value like “MyNAMESANDRO” – without any hyphens (-)?

Nothing will happen, we will still be able to compile and successfully deploy our schema.

BizTalk Schemas: Invalid type name doesn't happen

In fact, this is the best approach.

3) Now, what happens if we try to change the “RootNode TypeName” property to other 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

BizTalk Schemas: Invalid type name

Cause

Official Microsoft documentation state 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 hyphen, or any other punctuation characters, are “not allowed”, you should “removed it” 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 event “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 change 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!

BizTalk Schemas: Invalid type name

Humm… what? How that’s possible if in point 1 we saw that if the root node name and type name is the same it should work, and it did work before?

Cause

Again, official Microsoft documentation state 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, once you change the name for something else without hyphens or any other punctuation characters, you cannot rollback to the origin (or default) RootName TypeName “My-NAME-SANDRO”.

Solution

The same solution here, as a hyphen, or any other punctuation characters, are “not allowed”, you should “removed it” 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 event “My-NAME_SANDRO”

However, if you want to rollback to the default RootNode TypeName value, you need to delete the root node and recreate from the 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 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 point 3 and 4 you just need to open the Schema with XML (Text) Editor:

05-BizTalk-Schema-Invalid-type-name-OK

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 now can open it again with BizTalk Schema Editor, compile it and deploy it with any problem.

Keep posted for Part II of this blog post.

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira

BizTalk Deploy operation failed… Assembly “XY” references the following assemblies that must be deployed before deploying this assembly Assembly “YZ”

BizTalk Deploy operation failed… Assembly “XY” references the following assemblies that must be deployed before deploying this assembly Assembly “YZ”

I’m back with “Errors and Warnings, Causes and Solutions” and this time targeting developers – BizTalk Deploy operation failed – that work until late and they are a bit tired… believe me, It’s never a good recipe!

Today will I was deploying a BizTalk Server Solution from Visual Studio I had a rookie problem that, because I was tired, I took 20 minutes to find out the problem:

Severity Code Description Project File Line

Error Assembly “Finance.Orchestrations, Version=1.0.0.0, Culture=neutral, PublicKeyToken=d149e7c1ed8e238f” references the following assemblies that must be deployed before deploying this assembly:

Assembly “Staging.Orchestrations, Version=1.0.0.0, Culture=neutral, PublicKeyToken=d149e7c1ed8e238f”.

Deploy operation failed…

At Microsoft.BizTalk.Deployment.BizTalkAssembly.PrivateDeploy(String server, String database, String assemblyPathname, String applicationName)…

BizTalk Deploy operation failed

… a rookie problem that if you read carefully the error message you will know the problem.

Cause

Basically, this is a dependency problem… “Finance.Orchestrations” assembly references certain “Staging.Orchestrations” artifacts, and for this reason, this last assembly (Staging.Orchestrations) must be deployed before deploying the assembly that references these artifacts (Finance.Orchestrations).

When you deploy BizTalk assembly you must ensure that any referenced assembly is deployed first. BizTalk actually, helps you out, by enforcing that “deployment rule” by not letting you applying adding resource action without deploying all its references and that is the reason why this error is happens

Although I’m almost sure that I had deployed all the resources – common schemas, maps, and orchestrations – that was being consumed in this BizTalk Solution. When I decide to check if they were actually deployed in the environment, I found out that they weren’t… again a rookie mistake.

Solution

The solution to this problem is easy, make sure that all the dependencies are deployed before you deploy your solution.

In my case, I deployed the “Staging.Orchestrations” assembly and then I was able to indeed deploy the “Finance.Orchestrations”.

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira

BizTalk Server Administration Console: Concurrency Violation encountered while Updating the ReceivePort. The local, cached version of the BizTalk Server group configuration is out of date.

BizTalk Server Administration Console: Concurrency Violation encountered while Updating the ReceivePort. The local, cached version of the BizTalk Server group configuration is out of date.

The funniest part of having an intern working and learning from you, especially for a person like me that really love to write about “Errors and Warnings, Causes and Solutions”, is that they are able to make the funniest and unexpected questions, they will find things that because we are so accustomed to doing the job and to avoiding them, that we do not even realize anymore that they exist and they are there.

So yesterday, after a solution deployment, my intern was complaining that he was always receiving the following error while creating a receive port:

TITLE: BizTalk Server Administration
——————————
Concurrency Violation encountered while Updating the ReceivePort ‘rprtReceive’. The local, cached version of the BizTalk Server group configuration is out of date. You must refresh the BizTalk Server group configuration before making further changes. (Microsoft.BizTalk.ExplorerOM)

For help, click: http://go.microsoft.com/fwlink/?LinkId=47400&ProdName=Microsoft+BizTalk+Server+2016&ProdVer=3.12.774.0&EvtSrc=Microsoft.BizTalk.ExplorerOM.Resources&EvtID=IDS_ERR_OBJECT_CONCURRENCY
——————————
BUTTONS:
OK
—————————–

Concurrency Violation encountered while Updating the ReceivePort

Cause

While open and navigating in the BizTalk Administration Console you will notice that the first request on expanding the navigation tree or open a BizTalk Server Application or Host Instance will take longer time that further interactions, this because in the first request the Administration Console will query your BizTalk databases for information and after that in cache the result.

So, unless you force a refresh it will use that cache information, nevertheless it will have some kind of mechanism (like a hash) to verify if the cache is updated will the current BizTalk Server Configuration on the database when you try to perform an operation like create or change a Receive Location.

Assuming that you deploy a new version or new artifact to a BizTalk Application, you need to refresh that Application before you perform any kind of operations, otherwise, you will receive this or similar errors.

The reason for this error to happen was that my intern already had the BizTalk Administration Console running and he was already focused (selected) the Application in concern before he went and deploy a new version of the solution from Visual Studio. After he deploy

SOLUTION

This is, in fact, a simple problem to solve:

  • Concurrency Violation encountered while Updating the ReceivePort – Option 1:
    • Close the BizTalk Administration Console and open again (stupid and simple)
  • Concurrency Violation encountered while Updating the ReceivePort – Option 2:
    • Right-click on the BizTalk Application you want to refresh, and then select the “Refresh” option

Concurrency Violation encountered while Updating the ReceivePort: BizTalk Application Refreshed

  • Concurrency Violation encountered while Updating the ReceivePort – Option 3:
    • Select the resource inside your BizTalk Application you want to refresh, for example, “Receive Locations” and press F5

There are several alternatives. The important is to refresh the BizTalk Administration Console if something had changed in your BizTalk Server environment.

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira

BizTalk Server Visual Studio Deployment: A network-related or instance-specific error occurred while establishing a connection to SQL Server

BizTalk Server Visual Studio Deployment: A network-related or instance-specific error occurred while establishing a connection to SQL Server

Typical basic error for beginners that also occur sometimes even with experienced BizTalk developers… While trying to deploy a BizTalk Server solution directly from Visual Studio 2017 I got the following errors messages:

Severity Code Description Project File Line Suppression State
Error A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 – Could not open a connection to SQL Server) The network path was not found 0
Severity Code Description Project File Line Suppression State
Error Deployment cannot initialize the connection to the database “BizTalkMgmtDb” on server “BIZTALKDEMO”. Verify that you have the required security permissions and that communication between Distributed Transaction Coordinator services on the machines involved is not prevented by current DTC security, firewall or authentication settings. A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 – Could not open a connection to SQL Server) The network path was not found 0

 A network-related or instance-specific error occurred: Deploy BizTalk Server Solution From Visual Studio

Cause

This error may occur for several reasons, like BizTalk Server cannot communicate with SQL Server machine because some firewall restrictions or SQL Server does not accept Remote Connections or that SQL Server Network Protocols are not properly configured – I wrote a few days ago a blog post about that: WCF-SQL Adapter: Connecting to the LOB system has failed. A network-related or instance-specific error occurred while establishing a connection to SQL Server– and so on.

However, in the cause of this problem is quite different, the first error doesn’t tell us to much about the main cause of the problem but the second one:

Deployment cannot initialize the connection to the database “BizTalkMgmtDb” on server “BIZTALKDEMO”…

Gives you a good clue about the problem.

In fact, I was migrating an existing BizTalk Server solution to a new server and I forgot to update the Visual Studio deployment properties and the Server was pointing an incorrect to an incorrect an inaccessible SQL Server.

 A network-related or instance-specific error occurred: Visual Studio Deployment Properties

Solution

Again, this is a typical a beginner error and quite easy to fix, so to solve the problem you just need to properly configure the BizTalk Server deployment properties in all your Visual Studio projects inside your solution by:

  • In Visual Studio Solution Explorer, right-click a project for which you want to configure properties, and then click “Properties”.
  • Click the “Deployment” tab in Project Properties Designer.
  • And make sure you properly configure the following properties:
    • Application Name: Name of the BizTalk application to which to deploy the assemblies in this project. If the application already exists, the assemblies will be added to it when you deploy the project. If the application does not exist, the application will be created. If this field is blank, the assemblies will be deployed to the default BizTalk application in the current group. Names that include spaces must be enclosed by double quotation marks (“).
    • Configuration Database: Name of the BizTalk Management database for the group, “BizTalkMgmtDb” by default.
    • Server: Name of the SQL Server instance that hosts the BizTalk Management database on the local computer. In a single-computer installation, this is usually the name of the local computer. Note: If you move this BizTalk project to a different computer, you probably will need to modify the Server property to reflect the new computer name before you will be able to deploy the assembly.

Note: there are other properties but these three (3) are the most important ones (see the full list of properties here: How to Set Deployment Properties in Visual Studio)

  • Save the file and then redeploy the BizTalk Server solution (or project).

 A network-related or instance-specific error occurred: Error solved

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira