Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>We use this command in the pre-build event of the common assembly's Visual Studio project:</p> <pre><code>if not "$(SolutionName)" == "ABC" if not "$(TargetFileName)" == "$(ProjectName).$(SolutionName).dll" exit 1 </code></pre> <p>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 <em>common assembly's solution file</em>, it reads like this:</p> <blockquote> <p>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.</p> </blockquote> <p>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 <em>name</em> is <em>not</em> 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.</p> <p>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 <em>out</em> of the trunk into other products).</p> <p><em>If</em> 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.</p> <p>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.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload