BTSTask AddResource Fails Even with Shared Assemblies in GAC

Question

I am trying to create a BizTalk application (App1) and add resources using the BTSTask command line utility. Some of the App1 BizTalk assemblies depend on a few SharedApp BizTalk assemblies. I added the SharedApp assemblies to the GAC using gacutil and verified they were present in the GAC. When I run BTSTask AddResource, the command fails for any App1 BizTalk assembly that depends on any of the SharedApp assemblies.

The error message tells me a specific SharedApp dll cannot be found for reference. I have verified the details (name, version, etc.) on the SharedApp assembly are correct; it is the correct assembly and is present in the GAC.

Shouldn't BizTalk be able to detect those SharedApp assemblies in the GAC and allow them to be used as reference assemblies when I call AddResource?

Any thoughts on why adding the SharedApp assemblies to the GAC did not solve my problem?

EDIT: Adding command line example text

BTSTask.exe AddApp -ApplicationName:App1 -Server:BTServer1 -Database:BTDatabase1 -Description:App1_instance
BTSTask.exe AddResource -ApplicationName:App1 -Source:"path_to_App1.Assembly.dll" -Destination:"destination_path_for_App1.Assembly.dll" -Type:BizTalkAssembly -Options:GacOnAdd,GacOnInstall -Overwrite -Server:BTServer1 -Database:BTDatabase1

Are the 'SharedApp' assemblies .NET assemblies, or biztalk assemblies? Also, can you post your script? — brunch, Apr 15 '13 at 04:30
The `SharedApp` assemblies are BizTalk assemblies, as noted. — Michael, Apr 16 '13 at 18:21

score 0 · Answer 1 · answered Apr 12 '13 at 08:09

0

Is this BizTalk 2010? In that case, it might be something to do with the 'dual cache' that was introduced with .NET 4.0. As you might know, there are now 2 global assembly caches and assemblies from the 2.0 GAC cannot use 4.0 GAC assemblies.
So maybe your SharedApp is in the .NET4.0 cache and the resource you want to add is compiled against an older version of BizTalk?

Just thinking out loud, you never know if it helps. Cheers

answered Apr 12 '13 at 08:09

Sam Vanhoutte

3,247
27
48

This is BizTalk 2006, using .NET 2.0, so no issues with the 4.0 GAC. – Michael Apr 12 '13 at 13:49
Sorry, seems to be something else then. One thing I remember from the past was that there were files in a system folder somewhere (like a hidden GAC) that contained older versions of dlls from me and these were being used instead of the real GAC'ed ones. It's probably nothing, but maybe do a dir /s on your c-drive to search for your dlls and see if you have items that should not be there. – Sam Vanhoutte Apr 12 '13 at 15:49

score 0 · Accepted Answer · answered Apr 16 '13 at 20:19

After spelunking into our automation and enabling detailed logs, I was able to get a clearer error message:

Error: Assembly "App1.Assembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=xxxxxxxxxx" references the following assemblies that must be deployed before deploying this assembly: Assembly "SharedApp.Services, Version=1.0.0.0, Culture=neutral, PublicKeyToken=yyyyyyyyyyyyyyyy"

After an online search for that error, I uncovered the following from a discussion post:

If [a] DLL contains XSD (BizTalk) schemas it must also be deployed to the BizTalk management database.

Apparently, this must be done in addition to adding the assemblies to the GAC. This is the reason why adding App1 assemblies to my application would fail; although I added the SharedApp BizTalk assemblies to the GAC, they were also needed in the BizTalk management database.

Thank you to those who took a look at this issue.

BTSTask AddResource Fails Even with Shared Assemblies in GAC

2 Answers2