Bits and pieces about DLLs in BizTalk

Here’s some of the things to watch out for when GACing DLLs

Gacing BizTalk DLLs 

When an dll file is GAC’d, the changes won’t come into effect until the host instances are restarted.

Although it’s not good practise, the dll gacing and host restarting can be done when there are existing instances that use the updated dll.

Example: There are existing orchestration instances and an updated orchestration dll is gac’d and host instances are restarted. The orchestration has 5 shapes in a sequential order A,B,C,D,E and changes have been made on shape C. All shapes are persistence points.

When the host instance is stopped, all the running orchestration instances will be saved to the database at their last persistence point (dehydrated) and the dll will be unloaded.

Persistent point: http://msdn.microsoft.com/en-us/library/aa547090(v=bts.20).aspx

As the host instance is started again, the saved orchestration instances will be rehydrated and the updated dll will be loaded.

For the saved instances, only the ones that were saved into the database before reaching shape C will pick up the changes.

Gacing DLLs and export to msi

When an dll is GAC’d and not property stored into the BizTalk management database, the exported msi file will not contain the latest dll but the dll which has been stored into the BizTalk management database.

To store a dll into the management database, it has to be imported from a msi or refreshed on the resources tab.

Same schema in different DLLs

The combination of namespace and root element name must be unique across all schemas in the same BizTalk group. It may not be obvious because biztalk allows you to deploy multiple DLLs with the same schemas and it doesn’t complain about it until the schema is used. When a non-unique schema is used, the following error will be raised.

“This Assembler cannot retrieve a document specification using this type:namespace#root”