Assemblies versioning and signing


Published on

Introduction to assembly versioning in .Net, including strong names discussion

Published in: Software
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Assemblies versioning and signing

  1. 1.<br />1<br />.Net assemblies versioning<br />
  2. 2. Agenda<br /><br />2<br />Assembly Build numbering<br />Best practices<br />Assembly Strong names <br />Best practices<br />Recommendations<br />
  3. 3. Assembly Names<br /><br />3<br />Assembly names in .NET framework consist of 4 parts<br />The short name. <br />On Windows this is the name of the Portable Executable file without the extension. <br />The culture. <br />This is an RFC 1766 identifier of the locale for the assembly. In general, library and process assemblies should be culture neutral; the culture should only be used for satellite assembliesas part of localization deployment effort. <br />The version. <br />This is a dotted number made up of 4 values — major, minor, build, & revision. <br />A public key token. <br />This is a 64-bithash of the public key which corresponds to the private key used to sign[1] the assembly. A signed assembly is said to have a strong name.<br />
  4. 4. Version Numbers<br /><br />4<br /><major version>.<minor version>.<build number>.<revision><br /><ul><li>Major version: The component owner usually assigns this number. It should be the internal version of the product. It rarely changes during the development cycle of a product release.
  5. 5. Minor version: The component owner usually assigns this number. It is normally used when an incremental release of the product is planned instead of a full feature upgrade. It rarely changes during the development cycle of a product release.
  6. 6. Build number: The build team usually assigns this number based on the build that the file was generated with. It changes with every build of the code.
  7. 7. Revision: The build team usually assigns this number. It can have several meanings: bug number, build number of an older file being replaced, or service pack number. It rarely changes. This number is used mostly when servicing the file for an external release.</li></li></ul><li>Default Versioning<br /><br />5<br />The build process allows applying default version number (e.g. 1.0.*)<br />Asterisk sign instructs Visual Studio to assign on each build a version [1.0.d.s] as follows<br />d is the number of days since February 1, 2000<br />s is the number of seconds since midnight / 2<br />Problems with this mechanism include:<br />Only X.Y.* format is allowed (e.g. 1.0.*.0 is not allowed)<br />There’s no clear incremental progress of build numbers (especially for s)<br />Recurring build will automatically generate a new version<br />
  8. 8. Applying Common Version<br /><ul><li>Microsoft recommends sharing versioning via a common file, added as Link in each relevant project.</li></ul>choose “Add as Link.”<br />in VS2008 and earlier msut use Right-click<br />
  9. 9. Versioning in Microsoft Products<br /><br />7<br />Major number: incremental (office 2007 is version 12)<br />Minor number: incremental<br />Build number: four digits encoding the date of release(64 months since 1/1/2002)(23rd day of the month)<br />Revision: incremental – start at 1000, incrementing beta revisions.<br />
  10. 10. Versioning Best Practices – None!<br /><br />8<br />
  11. 11. Strong Names – Why & when(MSDN Summary)<br /><br />9<br />What Must Be Strong-Named<br />DLLs in GAC (global assembly cache)<br />Especially for mixed deployment of x64 & x32 versions of the same DLL.<br />ClickOnce application and deployment manifests. <br />The Visual Studio project system enables this by default for ClickOnce-deployed applications.<br />Primary interop assemblies. <br />The TLBIMP utility enforces strong-naming when creating a primary interop assembly.<br />What Should Be Strong-Named<br />Shared DLLs should be strong-named.<br />Regardless of whether a DLL will be deployed to the GAC, a strong name is recommended when the DLL is not a private implementation detail of the application, but is a general service that can be used by more than one application<br />
  12. 12.<br />10<br />Strong Names – Why & when<br />What Should Not Be Strong-Named<br />EXE Assemblies<br />In general, you should avoid strong-naming application EXE assemblies. A strongly named application or component cannot reference a weak-named component, so strong-naming an EXE prevents the EXE from referencing weak-named DLLs that are deployed with the application.<br />Private DLLs<br />In addition, you may want to avoid strong-naming components that are private to your application. In this case, strong-naming can make it harder to manage dependencies and add unnecessary overhead for private components.<br />For this reason, the Visual Studio project system does not support strong-name application EXEs. Instead, it strong-names the Application manifest, which internally points to the weak-named application EXE.<br />
  13. 13. Strong Names – Security<br /><br />11<br />Strong signed assembly ensures the following<br /> your assembly cannot be modified and still retain your strong name signature. <br />The strong name does not make your assembly tamper proof. <br />It is still possible to remove a strong name, modify the IL code, and then reapply a different strong name.<br />An attacker cannot claim they are “you”<br />Private key secures against recreating a valid signature from your original publisher's key unless your publisher's private key has been compromised. <br />If an attacker strips a strong name signature, signs the code, and then installs the code in the global assembly cache, the code will have a different identity. <br />Any callers looking for the original assembly will not bind to an assembly signed with a different private key. Strong names prevent this type of substitution attack.<br />
  14. 14. Strong names – Complications<br /><br />12<br />All assemblies referenced by a strong-named assembly must also be strong-named. <br />This includes third party DLLs as well!<br />Strong-name signing makes servicing more complicated. Under current versioning policy, an assembly will always attempt to load the exact version of the assembly it was built against. If, for example, your application was built against version of a strong-named assembly and you fix a bug in the assembly, bumping the version number to, the existing application will not find the updated assembly.<br />Some (like it) call it DLL Hell, some (against it) call it Deployment Hell<br />Performance: loading signed assemblies (not from GAC) takes more time due to decryption overhead.<br />
  15. 15. More related issues…<br /><br />13<br />This presentation covered a portion of the subject ; more related topics include:<br />Digital Certificates<br />Digital signatures <br />Strong signatures <br />Delayed signing<br />Test vs. Release signing<br />Embedded signatures<br />Managing the private key.<br />“MS signing best practices” document (~70 pages)<br />
  16. 16. References<br /><br />14<br />