Tuesday, November 23, 2010

Tip: Verification of imported BizTalk assemblies after deployment

As we all know, we need to import and install BizTalk assemblies in order to use at run time and these assemblies get GACed during install operation and inserted into BizTalkMgmtDb database during import operation. If we are not updating version for the assemblies and overwrite with new assemblies each time(although this is not preferrable), it is important to make sure that assemblies are imported and installed correctly.

We can easily verify the timestamp on assemblies in GAC to make sure that Install operation is successful. We can verify import operation of Schemas by looking at schema content(not timestamp though) inside BizTalk Admin Console( =>Schemas=> =>Right click and choose Schema View). But unfortunately there is no such direct way to verify contents or timestamp of  other types of BizTalk artifacts like map, orchestration etc. A work around to verify that would be to query against bts_assembly table in BizTalkMgmtDb database*. Here is a sample query to view recently deployed assemblies on top of the result set,

select * from bts_assembly order by dtDateModified desc

*Microsoft does not recommend accessing BizTalk databases directly.

HTH.

Monday, November 8, 2010

Tip: Specifying Key file path for BizTalk projects

As we know, key file needs to be specified for any BizTalk project in order for assembly to have strong name before GAC/deploy the same. We could specify this key file either through project properties or in AssemblyInfo.cs file. We can conveniently specify the path to key file if we choose the later. But if we specify the path to key file using Project Properties window, I observed that a copy of key file is being created in respective project folder and same is being referenced. But there may be times where we might want to specify key file from a different location to avoid multiple copies of key file. Here are couple of such scenarios,

1. When we like to maintain key file at some common location(like at root level) and share the same across multiple BizTalk projects/solutions

2. When we migrate BizTalk solutions from previous versions, they might contain the path to key file. If we need to change this through browse option, we get local copy of key file and lose the ability to choose different location.

Here is a manual work around to specify key file path at BizTalk project level,

Open BizTalk project in some text editor (like Notepad), and we can observe the following section in that,

For BizTalk Server 2010 project:
< PropertyGroup >
<SignAssembly > true/false</SignAssembly>
</PropertyGroup>
<PropertyGroup>
<AssemblyOriginatorKeyFile><path to key file here></AssemblyOriginatorKeyFile>
</PropertyGroup>

For BizTalk Server 2009 project:

<PropertyGroup >
<AssemblyOriginatorKeyFile><path to key file here></AssemblyOriginatorKeyFile>
<SignAssembly > true/false</SignAssembly>
</PropertyGroup>

Specify key file path in the AssemblyOriginatorKeyFile node and save the file. Now we can see the same path in Properties window as well.

Fix : Dll locking issue by Visual Studio

I have observed the following error while building BizTalk schemas and maps projects.

Unable to copy file "obj\Deployment\Schemas.dll" to "bin\Deployment\Schemas.dll". The process cannot access the file 'bin\Deployment\Schemas.dll' because it is being used by another process.

I could get rid of this annoying error after doing following tasks,

1. Paste the following script in PreBuild events section of
Schema Project->Properties window (found about this script on this blog entry),

if exist "$(TargetPath).locked" del "$(TargetPath).locked"

if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"

2.Set CopyLocal property of Schemas dll to False

UPDATE [06.14.2015]:
Here is another alternative to get rid of this error:

We get this error most likely when we add references to other projects or dll file from project bin directory directly. Instead build and GAC the referenced project and then add reference from GAC. This way even if we open both projects in different Visual Studio windows, we will not see this locking error.

HTH.