This repository has been archived by the owner on Mar 11, 2020. It is now read-only.
Managing assembly versions and assembly dependencies
taoneill edited this page Oct 28, 2016
·
2 revisions
Avoid the pitfalls of full-trust (GAC-based) development scenarios by understanding the basics of GAC deployments and DLL hell
Best practices for assembly versioning and dependency management:
- You should avoid changing the
AssemblyVersion
of your SharePoint projects (WSP solutions). Use theAssemblyFileVersion
to track updated version numbers (ideally using SemVer) whenever you plan to release an upgrade. - This is ideal since, no matter what happens, having two different versions of the same WSP solution package to the same farm is impossible. If you keep your
AssemblyVersion
stable, it make your life easier refering to the assembly strong names (e.g. in ASP control template imports). - Applying the correct
AssemblyFileVersion
should be the responsiblity of your continuous integration build server, to avoid manual versioning errors as much as possible Don't trust the "Specific Version" parameter when you add a project reference:- Its only meaning is: "use this specific AssemblyVersion of my dependency when building my own projet"
- At runtime (i.e. once deployed to GAC), your own assemblies will always require the same AssemblyVersion'd dependencies (i.e. those used at build time with the same assembly strong name) be present in the GAC as
- So you should always use "SpecificVersion=TRUE" to ensure you don't compile using a rogue-version assembly (otherwise, once you deploy, at runtime you may have "Missing assembly" problems