As the title says: every time I deploy from Visual Studio to BizTalk 2013 R2 the orchestration gets unbounded and unenlisted. The receive/send port looses its pipeline.
I have tried to clean cached bindings on C:\Users\<your_user>\AppData\Roaming\Microsoft\BizTalk Server\Deployment\BindingFiles and do a redeployment on everything, but no success.
Any ideas on how to solve this?
Export the bindings before the deployment and re-import them after the deployment.
Another option is to install BizTalk Deployment Framework which has an option to Quick Deploy, that just simply re-GACs the DLLs, useful for when making small changes to existing objects that don't need to update the BizTalk DB
Related
I am stuck with a problem that I could use some feedback on to solve it in the best possible way.
The issue revolves around source control -> automated builds -> deployment. Basically ALM (Application Lifecycle Management).
We have a product – an ASP.NET Web application with a MS SQL database. This product is running on hundreds of websites with associated databases across multiple virtual machines in our production environment. At the moment the web applications and database are running on servers with IIS 7 and SQL Database Server 2008 R2. The product itself is source controlled in Team Foundation 2012.
For years the release of new versions of the product has been once or twice a year for years. Now we are going to focus on releasing more frequently and hence we need a strategy for the ALM for the product.
The deployment strategy now:
In the development period between the releases, the SQL update scripts has been created manually – each time a database change was made a script was updated. When the application is ready to be deployed it gets compiled on a developer machine. The database with all the changes used would be backed up into a .BAK file. The web application, the .BAK file and the update SQL script would be packaged (.zip) and uploaded to the production environment ready for deployment.
Update existing running products:
Copy/paste the web application in the target website physical folder.
Update the web.config file – connectionstring and application
variables. Run the update script via SQL Management Studio
This would be done for each and every customer – hundreds of times.
This is a very tedious and error prone task and I don’t like it at all!
What I would like to do instead is;
Source control the database as a Database Project in Team Foundation
Automatically build the web application with Team Foundation 2012
Build Server.
Deploy the output from the Build Server to the multiple websites of
the production environment along with automatically generated SQL
update scripts run against the SQL Server.
I have been googling my ass off - only finding bits and pieces regarding builds, deployment, automatic SQL update script etc.
What I think is partly the right direction is to source control the database and use the TFS Build Server. I am very confused on how to do the deployment itself in an easy and controlled way using the output from the TFS Build server.
Ideally I would want to the TFS Build server to create a package with the latest version of the Web application, the latest version of the database, post deployment script including an auto generated SQL Update script from the previous build to the current build. This could be contained in e.g. a nuget package. Then I would want to be able to create an additional web application which should manage the deployment – target, version, iis website, sql server, web.config connectionstrings etc.
Does anyone have any advice on how to achieve this? How do you do this?
You can use a release management tool to do this, no need to create an additional web application.
One such example is Deployment Manager, from Red Gate. (Disclaimer: I work there.) It has built-in deployment actions for ASP.NET apps and SQL Server databases. The command line tool RgPublish.exe can be used to create a package for the web app as you describe from TFS Build. The same can be done for the database using the sqlCI.exe command line and associated NANT/MSBuild scripts.
The same packages can then be deployed to each of your servers. You may run into scalability issues with 100s of websites though.
The database deployment works by generating the upgrade script automatically, though you can change the behaviour to put the upgrade script in the package, when the package is first built. These are called "dynamic" and "static" upgrade methods respectively.
I am developing against a BizTalk 2009 environment. I am using BizTalk Deployment Framework (BTDF) to deploy my solution to the server. The problem I am facing is that when I tweak any aspect of my maps, the changes are not reflected in the BizTalk message body or output messages I use for testing. For instance, removing a link to a mapped element still shows the data being mapped from source to destination as if nothing has changed.
Between each deployment, the BTDF uninstalls the application, re-GAC's the assemblies, installs the application, and then bounces the host application. Ever so often BizTalk essentially catches up to my map version and it is working without issue until I make another tweak.
Is it possible that BizTalk is caching the map in a way that I cannot refresh?
Are you making your map changes in the BizTalk Mapper, or an XSLT?
Visual Studio does not recognise changes in an XSLT as requiring a re-build of the assembly. You would need to explicitly perform a "Rebuild" of the Map assembly in order to see these sort of mapping changes apply.
Hope this helps.
Are you building your dll's for deployment on your development machine?
Then remember that version of the map from GAC will take priority over your local map from visual studio.
I was many times cought by map dll taken from GAC instead of local folder.
Hope it helps
I'm working on a BizTalk project and don't understand the reason for both installing (double-clicking) and importing (using biztalk admin console) is needed.
I have a BizTalk project and I added bindings to it's resources and exported an msi file. Now I want to install the application on another server.
As far as I can tell this is what an MSI install does:
Copies files to the file system
Registers assemblies into the GAC
Adds the Application to the Add/Remove programs applet
However, here are my issues:
Installing using the msi doesn't add the application to the Biztalk admin console. We need to import the msi.
Uninstalling using the msi doesn't remove the assemblies from the GAC. It only removes the files it copied to the file system. Is there away for the uninstall to remove the GAC assemblies as well?
If I just import the MSI I'm able to start my biztalk application and it seems to run fine. Combined with issue #1 and #2 why is the MSI needed at all? I can see just importing doesn't add it to the GAC so if other applications depend on it they won't work.
I'm sure I'm missing features/configuration that the msi provides, but could someone help me understand why the msi needs to both be installed and imported into biztalk and why when you uninistall it does not fully uninstall everything it installed?
Two operations need to be undertaken when deploying a BizTalk solution.
Why Deploying BizTalk Solutions is a Two-Step Operations?
Register the BizTalk Solution to the BizTalk Management Database
Install the BizTalk Artefacts and Dependencies to the File System
First, BizTalk assemblies that comprise your solution must be registered to the BizTalk Management Database. This will allow BizTalk to know what Schemas, Maps, Pipelines and Orchestrations are available.
This is done by Importing your Windows Installer package to BizTalk.
Please, remember that a typical BizTalk plaform usually consists of many physical servers. However, all the servers in the BizTalk Group share a single BizTalk Management Database.
Therefore, the import operation needs to be done once for the whole BizTalk Group.
Second, the BizTalk assemblies that have been registered to BizTalk need to physically exist somewhere. Therefore, they must be installed to the file system.
This is done by double-clicking the Windows Installer package.
Notice that the install operation needs to be repeated on any physical server that is part of the BizTalk Group. And since, there is only one definition in the BizTalk Management Database as to what assemblies are part of the solution, this explains why BizTalk assemblies must be installed to the Global Assembly Cache (GAC).
Notice that, so far, the rule is simple :
BizTalk assemblies must be installed in the GAC on each server in the BizTalk Group
BizTalk assemblies must be imported (or registered) in the BizTalk Management Database once
However, we have only dealt with BizTalk assemblies. All other assemblies or other dependencies (Business Rules definitions, COM objects, bindings, configuration files, etc.) that a BizTalk solution needs at runtime are not covered by this two-step operation.
Inter-Environment Deployment
However, when the solution runs, those dependencies must also be present on each BizTalk server as appropriate.
That is why most of those artefacts are also registered to the BizTalk Management Database. But this time, this is only done so that the dependencies are brought in when the Windows Installer package for a BizTalk solution is created, and so that those dependencies can be installed appropriately on the target servers.
Why BizTalk Assemblies are Not Removed from the GAC upon Uninstall?
As a general rule of thumb, assemblies that are registered to the Global Assembly Cache are considered shared resources. Therefore, for safety reasons, BizTalk assemblies are not removed from the GAC upon uninstall. Consider what would happen when a custom BizTalk pipeline is used by more than one application. In that case, the BizTalk pipeline must be part of a separate, common, BizTalk application. Uninstalling this shared BizTalk application would break all other applications that depend on this pipeline...
When adding resources to the BizTalk Management Database, you have the choice to have assemblies be installed to the GAC at import or at install time. I strongly recommend against using the "GacOnImport" feature, that does not make sense in most typical multi-server BizTalk Groups.
However, there is an easier and most flexible way to customize what can be done to BizTalk assemblies or other dependencies, with regards to the Windows Installer package. This is done with Pre Processing and Post Processing Scripts.
Those scripts allow for running arbitrary applications at four specific times during the import/installation operations.
Before Importing
After Importing
Before Installing
After Intalling
If you want assemblies to be removed from the GAC upon uninstall, it is a simple matter of scheduling the appropriate command-line during the "Before Installing" phase of the operation.
Importing the MSI file adds the assemblies from the MSI into the BizTalk database. As you stated, running the MSI adds the assemblies to the GAC. Both are requires for the BizTalk application to be "installed". Only BizTalk assemblies have to be imported onto the BizTalk management database. All DLLs used by BizTalk must be in the GAC.
It may be worth a look at http://msdn.microsoft.com/en-us/library/aa578463(v=BTS.10).aspx to see that you can customize the behavior for install and import for each resource in your BizTalk application. This will allow you to only import the MSI and have that both add the assemblies to the database and install them in the GAC as well, leaving you without additional clutter in your Add/Remove Programs.
As to why the DLLs aren't removed from the GAC when you uninstall an installed MSI, I can tell you that this was by design. If you take a look at this page on MSDN http://msdn.microsoft.com/en-us/library/aa562001(v=bts.10).aspx you can see that this behavior is described as expected. That MSDN article also includes the link, under how to remove an assembly from the GAC, which explains how to use a post-processing script to have your MSI actually remove your assemblies from the GAC upon uninstall of the MSI.
Something went wrong with my BizTalk applications; I am unable to delete them and at the same time unable to deploy the latest from Visual Studio. I am working with BizTalk 2009.
The error being displayed on Visual Studio:
A referenced BizTalk project is being in use by other process and thus is unable to update it
My host instance and the application are in stopped state. I tried deleting the dll s from GAC, but no use.
Have you checked that you don't have any suspended instances associated with any of the orchestrations, ports and schemas the app had?
I have a DLL which is GAC'ced (c:\windows\assembly) which is being used by my Biztalk Application, for some requirement, I changed a function in that DLL and:
I uninstalled the old DLL which was in GAC (version 1.0.0.0)
I GAC'ced the newly built DLL into GAC (version 1.0.0.0)
I also restarted the BizTalk Host Instances.
But still the output seems to be from the old DLL's function. I am not getting the problem, why still I am getting the old output.
Can anybody help me?
Some tips that might be helpful:
(1) If you have multiple BizTalk servers in your group, be sure to update all of the servers!
Depending on your host instance configuration, your instance may run on any server the host instance is active on.
(2) Make sure you restart the correct biztalk host instance. This is often overlooked. Don't forget about the BizTalk Isolated Host! Perform a recycle of the specific IIS application pool if necessary. If you are unsure, perform an iisreset.exe
(3) To update a DLL in BizTalk it is often necessary to update it in the BizTalk database as well. For some changes it may work just updating the DLL in the GAC, but often I find that this is not enough (especially with orchestrations).
What you are describing here is correct. You should see the new DLL taking over. A couple things to check:
Did you recycle the correct host instances?
Did you recylce the host instances on all servers?
Did you veriiify the Create date on the GAC'd DLL to ensure the new one was installed?
Another issue might be based on what you changed in the Application. You can only Gac/Restart under particular circumstances. See this When can you just re-gac and re-start on Jon Flander's blog for reference.
If you want to be really sure that the correct assembly that has been GAC:ed, click "Run" and type "%systemroot%\assembly\gac" for .Net 1.1 or "%systemroot%\assembly\gac_msil" for > 2.0.
There you have the physical files for each version number to be checked (or overwrited).
It might help us support you if you let us know what part of BizTalk you are using the assembly, pipeline, functoid, schema etc.
Is that DLL used under a BizTalk process (BTSNTSvc.exe) or by an Isolated Host Instance?
If this DLL is used in a Receive Location which Receive Handler (Host) is Isolated, for example a SOAP Receive Location, you have to restart the Application pool from IIS and not the Host Instance.