BizTalk: BizTalkAssemblyResourceManager Unable to Add\Update the Assembly

by matt 30. May 2007 13:53
A recent problem we’ve come in to in deploying BizTalk solutions was that there seemed to be some kind of hard-coded path in the MSI that was created using the BizTalk Administrator.  Almost as an after thought, running the MSI would eventually present the following error:
    An error occurred while attempting to install the BizTalk application: Change requests failed for some resources.
    BizTalkAssemblyResourceManager failed to complete end type change request.
    Unable to add\update the assembly with LUID=”[My Assembly Name], Version=1.0.0.0, Culture=neutral, PublicKeyToken=8def881f8d2f6324”.
    Failed to create file “D:\[Some Directory]\[Some Assembly].dll”.
    Could not find a part of the path “D:\ [Some Directory]”.
    Could not find a part of the path “D:\ [Some Directory]”.
After a good bit of head scratching and (at the time) no useful search results on Google we noticed the ‘Resources’ view in the BizTalk administrator (see below).  In here is a list of all of the assemblies that you have deployed and are using in BizTalk.  If look at the Destination Location column you might notice a hard-coded path (although not always the case).
This is the path the BizTalk Administrator uses for the destination of resources on the BizTalk box where you are going to install the application.
BizTalk Administrator Resources View
 
If the server that you are deploying to can not create that path, then the deployment will fail and the MSI will (for the most part) roll back.  What you need to do is change the destination path from:
    D:\MyFolder\MyAssembly.dll
to
    %BTAD_InstallDir%\MyAssembly.dll
This will then ask the assemblies/resources to install in the target directory specified at the time the MSI is installed.
Problem avoided.

Tags:

BizTalk Server

Comments

1/24/2008 9:24:28 AM #

What can I say... - Thanks Matt!

This was one of the most valuable posts I've used in 2008 Wink

Saved me a lot of time....I allready started some serious head scratching like you mentioned....
It makes no sense with these hardcoded paths by default...!

Lars Wolter |

1/24/2008 9:31:03 AM #

I'm glad this was useful for you Smile

As far as I can see, the only place it ever gets set to a hard coded path is when you deploy from Visual Studio, if you have found somewhere else, I woudl be glad to know of it.

Matt Nield |

6/23/2008 11:07:55 PM #

Thanks a lot, this is a very usefull trick for deploy buztalk applications

Ivan |

6/26/2008 11:24:25 AM #

You are a genius...U saved me a lot of time..keep ur blogs goin Smile

ashwin sidharthan |

8/4/2008 9:38:05 PM #

I faced this issue and I figured out the same solution but some time i dont even get this error.

I normally don't install the application just import the application.I have configured to GAC resources on import instead of install.
I have .Net assembly as one of my resource and this dll never gets updated while importing.I dont have any other instance of dll.

I am wondering from where its gettign dll when I create my MSI file.

Do you have any idea about this?

Mayur |

1/23/2009 11:57:59 PM #

Thanks man, I was after 2 hours of pulling hair when I discovered your post.

Claudiu |

4/7/2009 10:52:32 PM #

Cheers - you saved me a lot of time.  Keep up the good work.

Krs |

Powered by BlogEngine.NET 1.5.0.7
Theme by Interakting

Interakting

A full service digital agency offering online strategy, design and usability, systems integration and online marketing services that deliver real business benefits and ensure your online objectives are met.

Calendar

<<  July 2010  >>
MoTuWeThFrSaSu
2829301234
567891011
12131415161718
19202122232425
2627282930311
2345678

View posts in large calendar