BizTalk Custom Pipeline component in GAC not updating

Question

I've recently started following this method for Pipeline Component Development and it's been working great for the development part of things. It even worked nicely for the first deploy of the components/pipelines.

However, the problem is now, when I deploy changes to the pipeline component DLLs, I cannot get them to update.

I follow the post as far as adding the assemblies to the GAC. I then Export the MSI containing my assemblies from BizTalk and import, with "Overwrite" option. I restart hosts instances, restart IIS (since my isolated host is using the component) but the changes I've made to the dll are not happening on the (in this case) staging server.

I've checked the MSIL folder and the folders and dlls are indeed getting updated date-modified, but my changes are not happening when I send messages through.

Is there a step I'm missing? Do I have to increase version numbers on the components themselves? I've increased versions and redeployed the pipelines that reference the components, and even that doesn't kick off the changes.

Answer 1

I found my issue. In my development environment, I had to:

• right-click on the resources in <myApplication>/Resources
• choose 'Modify' and then press the
• 'Refresh' button.
• navigate to the GAC directory where the dll for the custom pipeline is installed C:\Windows\Microsoft.NET\assembly\GAC_MSIL\<myComponent>\v4.0_<myVersion>__<myPublickey>
• restart host instances (unsure if this is totally necessary)

THEN I could export the dll and import it on the destination server (with Overwrite Resources checked). Without that Refresh, the dll changes were not being recognized on the destination server. Hopefully this save someone some time someday.

Answer 2

You do not have to export the assembly into an msi to install it. Adding it, or updating it, in the resources area will do the same thing as the import. We use this method regularly.

I usually do increment the version number because it helps ensure the code I expect to run is being run. It also makes rolling back to a previous version simple in case of a production issue.

Answer 3

It is also worth checking in C:\Windows\Microsoft.NET\assembly\GAC_64 and C:\Windows\Microsoft.NET\assembly\GAC_32 to see if there are any references to the old version of same DLL.

We had a similar issue and after days of debugging we ended up finding an old reference in the other two GAC folders.