BizTalk Server deployment: The database or the database version is incompatible with the installed version of this product

BizTalk Server deployment: The database or the database version is incompatible with the installed version of this product

Errors rarely appear alone; from time to time, it’s as if a project is determined to challenge you. But I find it rather enjoyable. It offers me inspiration and creative material for writing! Today’s U found an unfamiliar (or rare) problem that happened while I was migrating an old BizTalk Server 2013 solution into a recent version of the BizTalk Server.

Following the migration of the Visual Studio solution to a newer version, which also involved changing the target .NET framework, I encountered the following error when attempting to deploy the BizTalk Server Visual Studio solution:

The database or the database version is incompatible with the installed version of this product.

Causes

Normally, when we are migrating side-by-side BizTalk Server solutions, that means that we are creating a new BizTalk Server developer environment that, most of the time, does not have access to the previous environment. But you must know that if you copy a BizTalk Server Visual Studio folder solution from the old environment to the new one, it will also copy the *.btproj.user files. This is an XML file that contains not only the BizTalk deployment Settings but also several personal user settings like References path, test file names, and so on.

Regarding BizTalk deployment properties, all this setting are stored in the “*.btproj.user” file:

  • Application Name (ApplicationName): This is the name of the BizTalk application that we want 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 (“BizTalk Application 1”). Names that include spaces must be enclosed in double quotation marks (“).
  • Configuration Database (ConfigurationDatabase): This is the name of the BizTalk Management database for the group. The default value is “BizTalkMgmtDb”.
  • Server (Server): This is the name of the SQL Server instance that hosts the BizTalk Management database on the local computer. By default, this is usually the name of the local computer.
  • Redeploy (Redeploy): Boolean property that indicates if you want to allow redeployments from within Visual Studio. Setting this to “True” (the default) enables you to redeploy the BizTalk assemblies without changing the version number.
  • Install to Global Assembly Cache (Register): Setting this to “True” (the default) installs the assemblies to the Global Assembly Cache (GAC) on the local computer when you install the application. Set this to False only if you plan to use other tools for this installation, such as gacutil.
  • Restart Host Instances (RestartHostInstance): Setting this to “True” automatically restarts all host instances running on the local computer when the assembly is redeployed. If set to False (the default), you must manually restart the host instances when redeploying an assembly.

Well, if you do not change, it will contain the previous SQL Server name and instance.

So, if this SQL Server is accessible by this machine and if you try to deploy the solution, you will get an error saying that the database version is incompatible because now you are using a higher version of the product.

Solutions

The solution is quite simple to accomplish:

  • Access the Deployment tab of the Properties of each BizTalk Server project inside the solution.
  • And make sure that you set correctly at least the Server name (or name and instance)

If you want to play safe, it will give you a little bit of more work, but you can:

  • Close the solution.
  • 2Open Explorer and delete *.btproj.user files.
  • Reopen the solution, reconfigure the Deployment properties – this time mainly the Application name, because the rest will be properly configured by default – rebuild and deploy the solution.

Both these options will fix this problem.

Hope you find this helpful! So, if you liked the content or found it helpful and want to help me write more content, you can buy (or help buy) my son a Star Wars Lego! 

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 deployment: Access to the path is denied.

BizTalk Server deployment: Access to the path is denied.

It is always fun to return to one of my favorite topics: Errors and warnings, causes and solutions – aka Troubleshooting! Regardless of the technology, language, or service we are using. Today’s problem was another classic (and annoying) issue that happened while I was migrating an old BizTalk Server 2013 solution into a recent version of the BizTalk Server.

While trying to deploy a BizTalk Server Visual Studio solution that I copied from the old developer server environment into the new environment using, of course, Visual Studio, I got the following error message:

Access to the path is denied.

Causes

As the error clearly mentions, Visual Studio is trying to access somewhere that it does not have access to, even if you are an admin and you open in admin mode. The reason for that is that many times, when we copy the files between servers, they may become read-only for various reasons/situations. Maybe the files already were in read-only mode before we copied them.

Solutions

The solution is quite simple to accomplish:

  • Go to the project folder of your solution.
  • Right-click on the project folder and choose Properties from the menu.
  • Now, On the Properties window, go to the Attributes panel under the General tab and turn off the Read-only option. Click on the OK to apply the changes.
  • A new Confirm Attribute Changes window may rise, asking if you to confirm. Make sure you select the option Apply changes to this folder, subfolders and files and click OK.

After that, if you go to your BizTalk Server Visual Studio solution you will be able to successfully deploy it to the new environment.

Hope you find this helpful! So, if you liked the content or found it helpful and want to help me write more content, you can buy (or help buy) my son a Star Wars Lego! 

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 2020 – 20 days, 20 posts: BizTalk Bindings Exporter Tool for BizTalk Server 2020

BizTalk Server 2020 – 20 days, 20 posts: BizTalk Bindings Exporter Tool for BizTalk Server 2020

BizTalk Server 2020 – 20 days, 20 posts – day 3. Sorry for the delay but with this COVID-19 situation and with 3 small kids at home, sometimes it can be a challenge to find time to do community work and to write. Nevertheless, for today I have chosen to migrate another crucial and productivity tool that I really enjoy using it: BizTalk Bindings Exporter Tool to be compatible with BizTalk Server 2020. Once again, I hope you enjoy it as much as I do.

BizTalk Bindings Exporter Tool

BizTalk Binding Exporter Tool is a simple tool that will suppress the absence of advanced binding file generation capabilities in the BizTalk Server Administration Console allowing you to generate and export a binding file from BizTalk Applications in an intuitive and easy way.

Exporting a BizTalk Server Application binding is, at first sight, a simple and quick task that can be done using the BizTalk Server Administration Console. But even in simple tasks, we may encounter challenges that require us to perform some monotonous and boring manual operations that consume some of our precious time and are always subject to failures.

Normally the binding exportation starts in development, but we also will need to generate the same bindings for other environments like production and for that we normally need to open the binding file and replace/fix the differences for each different environment… which is normally a tedious operation. What we need to replace is mainly:

  • the URI’s: it should be fixed, but it is not mandatory. If you know what you are doing, you can fix them directly on the environment after you import the Binding.
  • the host instances: not mandatory, if you have the same host and host instances names across all your different environments (as best practices will tell you to do).
  • the NT Group Name associated in the Services (Orchestrations): according to securities best practices you shouldn’t use the same BizTalk Groups in different environments, so in this case, if you follow these best practices, you need to change these parameters in your binding file.

Normally, everyone changes the URI’s but neglecting the other parameters may be causing problems during the Binding import.

This tool will extend default BizTalk Server capabilities transforming the tedious and sometimes complicate binding generation a little simple and easy.

DevScope BizTalk Bindings Exporter Tool

You just need to specify the connection string to the BizTalk Management database (BizTalkMgmtDb)

DevScope BizTalk Bindings Exporter Tool

And this tool allows you to generate and export binding files with the following capabilities:

  • Export binding(s) file(s) for an entire Application or a list of Applications;
  • Export binding(s) file(s) from a specify Assembly or list of Assemblies;
  • Export binding(s) file(s) from a Receive Port or list of Receive Ports;
  • Export binding(s) file(s) from a Send Port or list of Send Ports;
  • Or Generate different binding files for each environment if you create an Excel File with the mapping for each environment ;

Other versions

This tool is also available for the following BizTalk Server versions:

Download

You can download BizTalk Bindings Exporter Tool from:
BizTalk Bindings Exporter ToolBizTalk Bindings Exporter Tool
GitHub

The post BizTalk Server 2020 – 20 days, 20 posts: BizTalk Bindings Exporter Tool for BizTalk Server 2020 appeared first on SANDRO PEREIRA BIZTALK BLOG.

BizTalk Visual Studio Deploy Issue: The “MapperCompiler” task failed unexpectedly. Access to the path ‘…’ is denied

BizTalk Visual Studio Deploy Issue: The “MapperCompiler” task failed unexpectedly. Access to the path ‘…’ is denied

Back to one of my favorite topics: Errors and Warnings, Causes, and Solutions since I have several issues to report in my internal OneNote. But in fact, this one happened today while I was implementing a new RosettaNet PIP on a client… nevertheless, this is not specific to RosettaNet.

I
was making a small improvement to an existing process/project to allow specific
orchestrations to be activated based on some properties promoted from the
message by applying a filter on the activate Receive Message shape. Everything
was going peacefully well until I tried to redeploy the Visual Studio solution.
Once I try to redeploy the BizTalk Server Visual Studio solution from Visual
Studio, I got the following error:

Error The “MapperCompiler” task failed unexpectedly.

System.UnauthorizedAccessException: Access to the path ‘C:……MapsmapNotifyOfShipmentReceipt_To_PIP4B2.btm.cs’ is denied.

   at Microsoft.VisualStudio.BizTalkProject.Compiler.MapCompiler.Compile(BizTalkBuildSnapshot buildSnapshot, IEnumerable`1 mapFilesToCompile, IEnumerable`1 schemaFiles, List`1& generatedCodeFiles, List`1& xsltFiles)

   at Microsoft.VisualStudio.BizTalkProject.BuildTasks.MapperCompiler.Execute()

   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()

   at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext() EAI.RosettaNet.4B2.

BizTalk Server: The MapperCompiler task failed unexpectedly

The funny part was that this was a small change that I did in an existing solution that already was running fine in the environment… and the change was a small improvement in the orchestration, not on the map!

Cause

Well,
I don’t know why the compiler decided to pick the mapper to complain. But This
issue is not related to any kind of maps you may have in your solution.

And
yes, the user that I was using to open, and build the solution had full rights
to access the file in question, all full rights to deploy stuff to the BizTalk
Server environment.

There are several possible causes for you to get such Access Denied errors when deploying BizTalk solutions directly from Visual Studio. Most common is that you don’t have the right BizTalk privileges to deploy artifacts, or in other words, you are not a local Administrator.

But most of the time is simpler than that and indeed is related to additional securities setting present in recent Windows Server versions. For you to be able to successfully deploy a BizTalk Server solution directly from Visual Studio, you must run Visual Studio as an Administrator, or with elevated permissions, because BizTalk assemblies need to be deployed into the GAC. What normally happens, is that if you have User Account Control (UAC) activated, or sometimes even deactivated, there are some additional securities setting present in recent Windows Server versions that, by default, doesn’t run Visual Studio with elevated permissions.

This
was indeed one of these cases, Visual Studio was not open with elevated
permissions.

Solution

The quick solution is for you to run
Visual Studio as an Administrator by simply run below step:

  • Right-click
    under Visual Studio and choose Run as administrator option.
Visual Studio: Run as Administrator

The problem with this approach is that
you need to remember yourself to do it every time you want to run Visual Studio.
Otherwise, the next time you try to deploy the solution, it will fail again
with the same error.

You may find more how to configure Visual Studio to run with elevated permissions as administrator by default here: https://blogs.biztalk360.com/biztalk-server-tips-and-tricks-configure-visual-studio-to-run-with-elevated-permissions-as-administrator/

If you try now to deploy your solution, you will see that this problem goes aways and you will be able to deploy it successfully (assuming that the solution does not actually have errors).

The post BizTalk Visual Studio Deploy Issue: The “MapperCompiler” task failed unexpectedly. Access to the path ‘…’ is denied appeared first on SANDRO PEREIRA BIZTALK BLOG.

BizTalk Bindings Exporter Tool for BizTalk Server 2013 R2

BizTalk Bindings Exporter Tool for BizTalk Server 2013 R2

Recently my team and I developed and released several tools that extend the out-of-box capabilities of BizTalk Server 2016 for developer and administration teams to be more productive, saving times in some simple but time-consuming tasks that should d supposed to be. One of these tools was BizTalk Bindings Exporter Tool.

Because many clients still are using BizTalk Server 2013 R2, and because I had received some requests from the community, I will be releasing these tools for BizTalk Server 2013 R2 also. And today, we will stat with the BizTalk Bindings Exporter Tool

BizTalk Bindings Exporter Tool

BizTalk Binding Exporter Tool is a simple tool that will suppress the absence of advanced binding file generation capabilities in the BizTalk Server Administration Console, allowing you to generate and export a binding file from BizTalk Applications in an intuitive and easy way.

Exporting a BizTalk Server Application binding is, at first sight, a quick and straightforward task that can be done using the BizTalk Server Administration Console:

  • Click Start, click All Programs, click Microsoft BizTalk Server 20xx, and then click BizTalk Server Administration
  • In the console tree, expand BizTalk Server Administration, expand the BizTalk Group, and then expand Applications
  • Right-click the application whose bindings you want to export, point to Export, and then click Bindings…
  • On the Export Bindings page, in Export to file, type the absolute path of the .xml file to which to export the bindings
  • Ensure that Export all bindings from the current application option is selected, and then click OK

But even in simple tasks, we may encounter challenges that require us to perform some monotonous and boring manual operations that consume some of our precious time and are always subject to failures. Because out-of-the-box BizTalk Administration Console doesn’t allow you to:

  • Export a Binding file of a specif Receive Port or list of Receive Ports;
  • Export a Binding file of a specif Send Port or list of Send Ports;
  • Export a Binding file of a specif Assembly or list of Assemblies;

And these are just a few scenarios. You can only fully Export the binding files of an entire application, which will lead you to sometimes extensive and fallible manual work to clean the binding files.

Usually, the binding exportation starts in development. Still, we also need to generate the same bindings for other environments like production, and for that, we usually need to open the binding file and replace/fix the differences for each different environment… which usually is a tedious operation. What we need to replace is mainly:

  • the URI’s: it should be fixed, but it is not mandatory. If you know what you are doing, you can fix them directly on the environment after you import the Binding.
  • the host instances: not mandatory, if you have the same host and host instances names across all your different environments (as best practices will tell you to do).
  • the NT Group Name associated in the Services (Orchestrations): according to securities best practices you shouldn’t use the same BizTalk Groups in different environments, so in this case, if you follow these best practices, you need to change these parameters in your binding file.

Normally, everyone changes the URI’s but neglecting the other parameters may be causing problems during the Binding import.

Once again, this tool will extend default BizTalk Server capabilities transforming the tedious and sometimes complicate binding generation a little simple and easy.

DevScope BizTalk Bindings Exporter Tool

You just need to specify the connection string to the BizTalk Management database (BizTalkMgmtDb)

DevScope BizTalk Bindings Exporter Tool

And this tool allows you to generate and export binding files with the following capabilities:

  • Export binding(s) file(s) for an entire Application or a list of Applications;
  • Export binding(s) file(s) from a specify Assembly or list of Assemblies;
  • Export binding(s) file(s) from a Receive Port or list of Receive Ports;
  • Export binding(s) file(s) from a Send Port or list of Send Ports;
  • Or Generate different binding files for each environment if you create an Excel File with the mapping for each environment ;

Credits also to my team member at DevScope, Pedro Almeida that collaborated in the development of this tool.

Download

You can download BizTalk Bindings Exporter Tool from:
BizTalk Bindings Exporter ToolBizTalk Bindings Exporter Tool
GitHub

The post BizTalk Bindings Exporter Tool for BizTalk Server 2013 R2 appeared first on SANDRO PEREIRA BIZTALK BLOG.

BizTalk Bindings Exporter Tool

BizTalk Bindings Exporter Tool

Following my commitment with the attendees at Integrate 2019 London and US that shared with me the same headaches and concerns, and following my series of posts about “BizTalk Bindings Exportation” published on BizTalk360 blog. I’m happy to announce the birth of a new BizTalk Server tool: BizTalk Bindings Exporter Tool.

BizTalk Binding Exporter Tool” is a simple tool which will suppress the absence of advanced binding file generation capabilities in the BizTalk Server Administration Console allowing you to generate and export a binding file from BizTalk Applications in an intuitive and easy way.

Exporting a BizTalk Server Application binding is, at first sight, a simple and quick task that can be done using the BizTalk Server Administration Console:

  • Click Start, click All Programs, click Microsoft BizTalk Server 20xx, and then click BizTalk Server Administration
  • In the console tree, expand BizTalk Server Administration, expand the BizTalk Group, and then expand Applications
  • Right-click the application whose bindings you want to export, point to Export, and then click Bindings…
  • On the Export Bindings page, in Export to file, type the absolute path of the .xml file to which to export the bindings
  • Ensure that Export all bindings from the current application option is selected, and then click OK

But even in simple tasks, we may encounter challenges that require us to perform some monotonous and boring manual operations that consume some of our precious time and are always subject to failures. Because out-of-the-box BizTalk Administration Console doesn’t allow you to:

  • Export a Binding file of a specif Receive Port or list of Receive Ports;
  • Export a Binding file of a specif Send Port or list of Send Ports;
  • Export a Binding file of a specif Assembly or list of Assemblies;

And these are just a few scenarios. You can only fully Export the binding files of an entire application which will lead you sometimes an extensive and fallible manual work to clean the binding files.

Normally the binding exportation starts in development, but we also will need to generate the same bindings for other environments like production and for that we normally need to open the binding file and replace/fix the differences for each different environment… which is normally a tedious operation. What we need to replace is mainly:

  • the URI’s: it should be fixed, but it is not mandatory. If you know what you are doing, you can fix them directly on the environment after you import the Binding.
  • the host instances: not mandatory, if you have the same host and host instances names across all your different environments (as best practices will tell you to do).
  • the NT Group Name associated in the Services (Orchestrations): according to securities best practices you shouldn’t use the same BizTalk Groups in different environments, so in this case, if you follow this best practices, you need to change these parameters in your binding file.

Normally, everyone changes the URI’s but neglecting the other parameters may be causing problems during the Binding import.

Once again, this tool will extend default BizTalk Server capabilities transforming the tedious and sometimes complicate binding generation a little simple and easy.

DevScope BizTalk Bindings Exporter Tool

You just need to specify the connection string to the BizTalk Management database (BizTalkMgmtDb)

DevScope BizTalk Bindings Exporter Tool

And this tool allows you to generate and export binding files with the following capabilities:

  • Export binding(s) file(s) for an entire Application or a list of Applications;
  • Export binding(s) file(s) from a specify Assembly or list of Assemblies;
  • Export binding(s) file(s) from a Receive Port or list of Receive Ports;
  • Export binding(s) file(s) from a Send Port or list of Send Ports;
  • Or Generate different binding files for each environment if you create an Excel File with the mapping for each environment ;

Credits also to my team member at DevScope, Pedro Almeida that collaborated in the development of this tool.

You can download BizTalk Bindings Exporter Tool from:
BizTalk Bindings Exporter ToolBizTalk Bindings Exporter Tool
GitHub

Or from:
BizTalk Bindings Exporter ToolBizTalk Bindings Exporter Tool
Microsoft | Code Gallery

The post BizTalk Bindings Exporter Tool appeared first on SANDRO PEREIRA BIZTALK BLOG.

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