We have upgraded a BizTalk 2006 application to 2013. After deploying this, we imported the binding file of 2006 (exported from 2006); it creates all ports, however it doesn't bind the orchestrations (host and ports). Any suggestions?
Found out the issue - binding file had a different assembly version than the deployed assemblies
Well, probably you don't have those hosts and host instances, that you had before, or you haven't created handlers for adapters, that you use.
Guess you should create exactly same hosts and host instances as you had on BT 2006. And then specify exaclty same adapter handlers, that you had on BT 2006.
Related
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
In our Visual Studio development (VS2015), we share one virtualized machine with several developers. We had to solve several minor problems with this setup but discovered a more annoying problem now.
Our solution consists of a client that uses web services, that are implemented in a ASP.NET project. When we start our client, we also start the services so that the calls can be made from the client. The services get started on the localhost port that is entered in the project properties. But when we work with several developers we have the problem that Visual Studio would use the same port for all developers and as we are on the same machine, the web project will not start because the port is already used. We now have following questions:
We can separate the ports by editing the IIS config file but we also have to change the port in the client and after each checkin all developers again have the same port.
1) Is there a clever way to manage the ports in the local IIS express?
2) How can we configure the ports in the clients so that the configuration is not overwritten by each checkin of other developers?
I am not sure whether we can only use registry file to deploy the adapter for BizTalk.
I tried but it didn't work.
Yes, you can because the Registry entries include ones for the path.
However, I strongly recommend against this. Adapters and Pipeline Components should be in the GAC.
BizTalk Server itself uses the GAC for Adapters and Pipeline Components.
i'm a newbie in biztalk.
i have data service access dll which are linked to the wcf.
i've just added a new column so i've updated my wcf.
so the next thing would be to update the dll which are already in the GAC.
just wondering if there's any msdn documentation about this?
or what's the best practice here?
and what exactly goes on when you restart host instance vs restarting the application?
thanks
Stopping/starting a BizTalk application simply stops and restarts the associated Receive and Send ports, and prevents the Orchestrations from acting on any pending subscription items. If you go one step further and un-enlist the Orchestration/Send Port, this removes the relevant subscription from the BizTalk Message Box database.
By compiling and deploying a new definition of your WCF datatype, you have changed the assembly within the GAC (all schemas are compiled and represented as .Net datatypes under the hood). To have this change reflected inside the running Host Instance, you would effectively need to alter the existing DLL that is in the .Net AppDomain. The .Net runtime does not support the removal of assembly types from an AppDomain, so you need to stop, and restart the Host Instance to effect this.
Short answer: Restart your Host Instance for any changes in data definition.
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.