Question

I have Common.dll that’s shared/used by (far more than) two SharePoint packages being deployed to the same GAC used by a single SharePoint instance. The shared assembly evolves from product deployment to product deployment, and it’s not treated as a product in and of itself. It is not released, per se. It evolves only in the context of other SharePoint products/packages.

The common assembly is primarily just a repository for highly reusable code. It’s used only by a small internal team of developers.

Branching/merging allows various products to take on the latest version of Common.dll whenever it suits the developers. Each product’s development effort schedules the risk of taking on the new version of Common.dll.

My need is to have those assemblies act in isolation from product to product — from SharePoint package to SharePoint package.

But that’s not happening. Instead, every time I deploy, Common.dll is overwritten in the GAC such that all products using it receive the behavior of this most recent version of Common.dll. Depending on what that behavior is, it can break a product that hasn’t been deployed in some time.

I’m trying to prevent that deployment “surprise!” potential w/o having to treat Common.dll like a public product that has to carefully avoid breaking changes/etc.

What technique do you use to preserve distinct versions of common assemblies when deploying various SharePoint packages to a single SharePoint instance’s GAC?

Answer 1

We use this command in the pre-build event of the common assembly’s Visual Studio project:

if not "$(SolutionName)" == "ABC" if not "$(TargetFileName)" == "$(ProjectName).$(SolutionName).dll" exit 1

This pre-build command does not have to change as the common assembly gets consumed by various products. When you replace “ABC” with the name of the common assembly’s solution file, it reads like this:

If we’re compiling the common assembly in its own solution (which is rare, but it happens), there’s
nothing to consider — compile away! Otherwise, fail the build unless someone has
renamed the common assembly per the consuming product’s Visual Studio
solution file name.

To avoid build failure, we rename the common assembly after we branch it into the codebase of the consuming product (via the common assembly project’s Properties Pages). The common assembly’s project name is not changed in Solution Explorer, nor is its Default Namespace changed in its Properties Pages. Only the “Assembly name” changes. So, except for product-specific changes which have been made, maintaining and consuming the common code always feels familiar: Solution Explorer and namespaces stay the same regardless of the product you’re developing.

The rename changes one line in the common assembly’s project file, which creates friction as you merge back into the trunk (and/or later, when you merge back out of the trunk into other products).

If the common project file makes its way into the codebase of ProductB while still naming its assembly for ProductA, its pre-build command will prevent compilation in ProductB, where the developers there can easily change the “Assembly name” to allow for compilation. This friction opportunity increases the more you merge.

The common assembly gets a unique name (and instance) in the GAC each time a new SharePoint product arrives in the GAC. Various products can use, evolve, and deploy the common assembly w/o fear of suddenly breaking other products/packages when they deploy.