Our client recently decided to upgrade their BizTalk instances from 2006R2 to 2010, and as we support several BizTalk applications it fell to myself and a coworker to upgrade them. I thought I would share my thoughts and experiences with this process...
Overall the upgrade has gone a lot smoother than I would have thought as BizTalk does have a tendency to be... temperamental. Although to be fair this is more than likely inexperience on my part than any serious fault of BizTalk (although there is one thing which is a Bad Thing, which Ill get to later). I find that (like anything I suppose) once you get your head around BizTalk's 'mentality', troubleshooting issues is a straightforward process. Ok, so lets get into the meat and potatoes of the post :).
Global Assembly Cache
So, the first thing to note when upgrading a 2006R2 solution to 2010 is the GAC is now completely separate for .Net 4.0 DLLs. Yes, that's right the 'Global' Assembly Cache is now two different folders:
- C:\Windows\Assembly [Anything pre .Net 4.0]
- C:\Windows\Microsoft.Net\assembly [.Net 4.0 DLLs ONLY].
So basically, if you have any legacy DLLs floating around, you will have to manage these in the old GAC and the resource DLLs generated as a result of the BizTalk orchestrations/maps/schemas in the new GAC. This is the 'Bad Thing' I was referring to earlier, as I find it quite annoying to have to switch between GACs when I'm deploying an application. While I don't doubt there are valid technical reasons for the split part of me really wishes this could have been handled differently. Ah well.
Related to this, we now have two separate GacUtil executables, one for each GAC. These are located at:
- C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0a\Bin\GacUtil.exe [this is the .net 2.0 GacUtil]
- C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0a\Bin\NETFX 4.0 Tools\GacUtil.exe [this is the .net 4.0 GacUtil].
Third Party DLLs and Resources
This is something that took a bit of effort to resolve. When you have third-party DLLs being referenced in your orchestrations/schemas BizTalk is very specific about how it wants these DLLs deployed. In our case, we needed to register the DLLs in the GAC AND add the DLL as a resource to the application. This is a bit tricky if you are trying to do a first time deployment from Visual Studio (ie. It wont let you deploy the application). So after much stuffing around I decided to write a batch file that handles all of these actions beforehand, after all automation is king ;) . Once I have a spare few hours I will convert these to PowerShell... mainly because I love PowerShell! But in any case, the end result is that before someone goes to deploy one of our orchestrations, they run the batch file. This batch file will:
- Register the DLL in the relevant GAC.
- Creates a new Application on the BizTalk Management Server DB (more on this later).
- Adds the DLL as a resource to the newly created application.
And hey presto! Visual Studio will deploy your BizTalk application nicely.
BTSTask All The Things!
BTSTask is an executable found in the BizTalk installation directory. This handy little tool can do various things such as:
- Create a new Application
- Add a resource to an Application
- Import/Export Bindings
This was used in our pre-deployment scripts to get BizTalk into a state that Visual Studio doesnt complain. It would be nice if there was a way to do this sort of thing from Visual Studio without having to invoke command line utilities, but at least it gives us something new to learn! Speaking of which, the command line reference for BTSTask can be found here.
So thats the end for tonight. This was just a general overview type post, showing the main three issues/considerations I needed to be aware of when upgrading BizTalk 2006R2 solutions to BizTalk 2010. I will follow up in the next few days with the 'nitty-gritty' details, such as considerations for how BizTalk handles the AssemblyInfo files when upgrading the soultion (hint: it doesnt). So thats something to look forward to :)