Compare GACs from two servers?

Question

I need a easy and trusted way to compare GAC (Global Assembly Cache) from two servers, during BizTalk migration. I also want to move the GAC from QA to Production if it doesn't exist in the destination server. These are both BizTalk servers and have tons of assemblies GAC'd. I saw some tools online but the link to one was broken (winmerge) and others did not seem really authentic. Thanks for your help.

Answer 1

Whenever I need to find something in the GAC, I always just run Gacutil.exe /l > c:/gac.txt from a Visual Studio (or, if that's not available, Windows SDK) command prompt, and then search the output file in a text editor. You could do that on both machines and use a tool like Beyond Compare to compare the contents of the two GACs. Beyond Compare also let's you do directory comparisons, so that may be easier (if you follow the next part of this answer) than exporting a listing of what's in the GAC.

To export assemblies, you can follow the instructions at http://blogs.msdn.com/b/johnwpowell/archive/2009/01/14/how-to-copy-an-assembly-from-the-gac.aspx to make the GAC behave like a normal Windows directory, enabling you to copy and paste the files that you need.

I will say, though, that the best option is to have your BizTalk assemblies in packaged MSI files that you can simply import into whatever BizTalk server you want (and then actually execute to GAC). This ensures that what you need is in the BizTalk database, because GACing is often not enough.

If you don't already have your MSI files ready to go, though, then now would be a good time to make them. If have made the local GAC browseable then it should be easy to browse to and add assemblies as a resource to whatever BizTalk application you want and to then export the application as an MSI file, which will include all of the application's resources. That way you don't have to do it all totally manually.

Not having everything ready to be deployed to a new server (and documented too) is a great way to find yourself stuck in a bind when a disaster strikes, or if you just need to add another BizTalk server for load balancing.