Your SlideShare is downloading. ×
Assemblies versioning and signing
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Assemblies versioning and signing

1,713

Published on

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

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

Published in: Software
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,713
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
39
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Robert.Sayegh@gmail.com
    1
    .Net assemblies versioning
  • 2. Agenda
    Robert.Sayegh@gmail.com
    2
    Assembly Build numbering
    Best practices
    Assembly Strong names
    Best practices
    Recommendations
  • 3. Assembly Names
    Robert.Sayegh@gmail.com
    3
    Assembly names in .NET framework consist of 4 parts
    The short name.
    On Windows this is the name of the Portable Executable file without the extension.
    The culture.
    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.
    The version.
    This is a dotted number made up of 4 values — major, minor, build, & revision.
    A public key token.
    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.
  • 4. Version Numbers
    Robert.Sayegh@gmail.com
    4
    <major version>.<minor version>.<build number>.<revision>
    • 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. 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. 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. 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.
  • Default Versioning
    Robert.Sayegh@gmail.com
    5
    The build process allows applying default version number (e.g. 1.0.*)
    Asterisk sign instructs Visual Studio to assign on each build a version [1.0.d.s] as follows
    d is the number of days since February 1, 2000
    s is the number of seconds since midnight / 2
    Problems with this mechanism include:
    Only X.Y.* format is allowed (e.g. 1.0.*.0 is not allowed)
    There’s no clear incremental progress of build numbers (especially for s)
    Recurring build will automatically generate a new version
  • 8. Applying Common Version
    • Microsoft recommends sharing versioning via a common file, added as Link in each relevant project.
    choose “Add as Link.”
    in VS2008 and earlier msut use Right-click
  • 9. Versioning in Microsoft Products
    Robert.Sayegh@gmail.com
    7
    Major number: incremental (office 2007 is version 12)
    Minor number: incremental
    Build number: four digits encoding the date of release(64 months since 1/1/2002)(23rd day of the month)
    Revision: incremental – start at 1000, incrementing beta revisions.
  • 10. Versioning Best Practices – None!
    Robert.Sayegh@gmail.com
    8
  • 11. Strong Names – Why & when(MSDN Summary)
    Robert.Sayegh@gmail.com
    9
    What Must Be Strong-Named
    DLLs in GAC (global assembly cache)
    Especially for mixed deployment of x64 & x32 versions of the same DLL.
    ClickOnce application and deployment manifests.
    The Visual Studio project system enables this by default for ClickOnce-deployed applications.
    Primary interop assemblies.
    The TLBIMP utility enforces strong-naming when creating a primary interop assembly.
    What Should Be Strong-Named
    Shared DLLs should be strong-named.
    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
  • 12. Robert.Sayegh@gmail.com
    10
    Strong Names – Why & when
    What Should Not Be Strong-Named
    EXE Assemblies
    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.
    Private DLLs
    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.
    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.
  • 13. Strong Names – Security
    Robert.Sayegh@gmail.com
    11
    Strong signed assembly ensures the following
    your assembly cannot be modified and still retain your strong name signature.
    The strong name does not make your assembly tamper proof.
    It is still possible to remove a strong name, modify the IL code, and then reapply a different strong name.
    An attacker cannot claim they are “you”
    Private key secures against recreating a valid signature from your original publisher's key unless your publisher's private key has been compromised.
    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.
    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.
  • 14. Strong names – Complications
    Robert.Sayegh@gmail.com
    12
    All assemblies referenced by a strong-named assembly must also be strong-named.
    This includes third party DLLs as well!
    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 1.0.0.0 of a strong-named assembly and you fix a bug in the assembly, bumping the version number to 1.0.0.1, the existing application will not find the updated assembly.
    Some (like it) call it DLL Hell, some (against it) call it Deployment Hell
    Performance: loading signed assemblies (not from GAC) takes more time due to decryption overhead.
  • 15. More related issues…
    Robert.Sayegh@gmail.com
    13
    This presentation covered a portion of the subject ; more related topics include:
    Digital Certificates
    Digital signatures
    Strong signatures
    Delayed signing
    Test vs. Release signing
    Embedded signatures
    Managing the private key.
    “MS signing best practices” document (~70 pages) http://www.microsoft.com/whdc/winlogo/drvsign/best_practices.mspx
  • 16. References
    Robert.Sayegh@gmail.com
    14

×