How NOT to unGAC external assemblies

[fernandodsanjos]

Is it possible to NOT unGAC external assemblies? As external assemblies often are shared by other applications or other .NETassembies.

Same applies to custom components

[tfabraham]

In .btdfproj:

<PropertyGroup>
  <!-- Existing properties here -->
  <UndeployExternalAssemblies>false</UndeployExternalAssemblies>
</PropertyGroup>

There is not a clean/elegant way to prevent undeployment of Component DLL's. You can override the entire UndeployComponents target with an empty implementation, which will do it:

<Target Name="UndeployComponents" Condition="'$(IncludeComponents)' == 'true' and '$(SkipUndeploy)' == 'false'">
</Target>

Thanks, Tom

[eloekset]

Windows Installer should count references to assemblies in GAC and not remove assemblies on uninstall until the reference count gets down to 0. I’ve never seen this actually work as intended, but I found this hint about a possible reason for that: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Shared-assemblies-in-GAC-and-reference-counts-td709783.html

[tfabraham]

The Deployment Framework uses two-phase delivery to deploy a BizTalk solution to a server. Phase 1 is the MSI, which is simply used as a convenient packaging/delivery vehicle for all required files. Phase 2 is MSBuild, which does the actual installation. The MSI never GAC's DLL's from your BizTalk solution, MSBuild does.

[eloekset]

Ok, I didn’t know that. Another issue, that I suspect, is related to not using Windows Installer to GAC shared assemblies, is versioning. I’m new to BizTalk in general, so I don’t know the history behind this - but my team has decided never to update version numbers of our projects, to not break existing applications sharing assemblies in GAC. Normally GAC would keep several versions of the same assemblies, but that’s probably also dependent on Windows Installer and the reference count.

[tfabraham]

Leaving AssemblyVersion alone and updating only AssemblyFileVersion has been common practice in the BizTalk world since BizTalk 2004, the first to use .NET. It's simply not worth the effort when so many things have to be in version lockstep to work properly. The AssemblyFileVersion attribute conveys the necessary detail without the hassle.

[fernandodsanjos]

@tfabraham @eloekset unfortunally ExternalAssemblies do sometimes have different versions and this is somthing we have a problem with with our growing library of common assemblies. Is there someway to put ExternalAssemblies in different folders in the deployment package? At the moment all ExternalAssemblies are added to the same ExternalAssemblies folder.