DEV343.NET Application and Library Versioning Juval Löwy

Software architect Former corporate architect of a Fortune 500 company Consults on.NET migration and design MS Regional Director for the Silicon Valley Participates in.NET design reviews Authored Programming.NET Components (2003, O’Reilly) COM and.NET Component Services (2001, O’Reilly) Contributing editor and columnist to several magazines Contact at About Juval Löwy

Outline Sharing and versioning Side-by-side execution Custom version policies CLR versioning

Shared Assemblies Assemblies can be private or shared A private assembly resides in the app directory A shared assembly is in a known location, called the global assembly cache (GAC) Shared assembly used for: Sharing Side-by-side execution

Shared Assemblies Shared assemblies must have a unique name Called Strong Name Strong name authenticates assembly’s origin and identity Shared assembly implies trust Strong name cannot be generated by a party other than the original publisher Strong name is based on public/private keys pair

Shared Assemblies Digitally signs the assembly to verify origin Encrypt manifest using the private key Append signature to manifest Incorporated public key into the assembly To verify authenticity.NET loader generates the hash Decrypts the manifest-stored hash Compare Can only call signed assembly from within signed assemblies

[assembly: AssemblyKeyFile("MyAssembly.snk")] Shared Assemblies To generate keys pair: sn.exe –k MyAssembly.snk Add the snk file to assembly info file: Installing in the GAC Drag and drop.NET configuration tool gacutil –i MyAssembly.dll

Shared Assemblies You need to reference assembly to build the client But not to deploy it

Shared Assemblies Disable client local copy of a shared assembly Set to False automatically if in the GAC already, and not added using the Projects tab Side-by-Side Demo

Versioning Assemblies are not necessarily backward- compatible Each client assembly records in manifest exact version of ot5her server assemblies.NET resolves compatibility at runtime Version number is the product of: Major,Minor,Build,Revision Recorded as assembly attribute [assembly: AssemblyVersion(" ")] Major Minor Build Revision

Either explicitly specify version numbers, or rely on compiler What is not specified is zeroed If you provide major & minor, can * build and revision Build is number of days since January 1, 2000, LIMA Revision is half number of seconds since midnight, LIMA [assembly: AssemblyVersion("2")] [assembly: AssemblyVersion("2.1")] [assembly: AssemblyVersion("2.1.*")]//best [assembly: AssemblyVersion(" ")] [assembly: AssemblyVersion(" *")] Versioning

Resolving Version When trying to use a shared assembly Possible many versions of the same assembly in the GAC Client always gets assembly with exact version match Can provide custom policy Developers must be disciplined Release procedures

Resolving Version Private assembly can be strongly named.NET ignores version of private assemblies with friendly name only.NET enforces version compatibility of private assembly with strong name

Resolving Version Conclusions Private assemblies with only friendly names must be backward compatible Private assemblies with strong name may not be backward compatible Even if a private assemblies with strong name is backward compatible (content wise), if the version number is not compatible, it may result in an exception Private assembly deployment model is really intended to work with friendly names only

Custom Version Policy Application can provide version binding policy Override default policy For shared and private assemblies Can deploy machine-wide policy.NET configuration tool MMC snap-in

Custom Version Binding Binding policy:

Custom Version Binding Codebase policy: Redirect to new location

CLR Versioning.NET rigorous version computability enforcement makes CLR versioning an interesting problem Different set of ground rules for CLR versioning CLR version used depends on: What the app is built with Available.NET versions Application CLR versioning policy

CLR Versioning CLR and application frameworks assemblies treated as one versioning unit Avoid mix-and-match Intend to be backward compatible, but not forward Developers must test and certify support for each CLR version

CLR Versioning CLR Side-By Side execution Multiple CLR versions on same machine Can install and uninstall versions separately

CLR Versioning Version unification Host process uses single CLR version.NET always runs unified stack of framework assemblies EXE application assembly and class libraries it loads use same CLR version Application select CLR and application frameworks version Class libraries have no say

CLR Versioning Default CLR version resolution.NET detects version app compiled with Loads latest compatible CLR version on machine Compatibility list maintained in Registry Can lead to undetermined results

CLR Versioning Applications that rely on default typically mainstream applications Use subset of types and services supported by all CLR versions Implicitly stating any compatible CLR version is allowed

Specifying supported CLR versions in config file For deterministic results In order of priority CLR Versioning

If no supported version is found,.NET refuses to load CLR Versioning

Can specify supported runtime at project setting

CLR Versioning Can specify supported runtime at project setting

More at TechEd C# Best Practices Day July 01 Distributed Security Practices Day July 02 Building High-Performance Applications with Visual Studio.NET Day July 03 Application and Library Versioning Day July 03 Software Legends Friday July 04

Resources Programming.NET components By Juval Lowy, O'Reilly April Master Class 3-4 annually Upcoming events on

Community Resources Most Valuable Professional (MVP) Newsgroups Converse online with Microsoft Newsgroups, including Worldwide User Groups Meet and learn with your peers

evaluations evaluations

SOFTWARE LEGEND Juval Lowy THURSDAY 3rd JULY at hrs Meet the Author’s Book signing

© 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.