Search code examples
.netassembliesversioning

Runtime version resolution for assemblies referenced as projects


For our enterprise application, we have some assemblies that are referenced as dlls and others that are referenced as projects.

For the ones that are referenced as dlls, we have changed the "Specific Version" setting to be false.

The ones referenced as projects do not have such a setting. If we have to deploy a fix to one of the referenced project assemblies, how will the runtime know what version to search for? Do we also have to deploy the main project as well?


Solution

  • The critical thing to understand here - is that "Specific Version" has nothing to do with how the application behaves at runtime - it does not affect the way in which the .net runtime resolves assemblies.

    All "Specific Version" does, is tell Visual Studio (not the compiler) that when the project is loaded into the IDE, if the DLL reference is not available at resolvable locations, whether or not to accept a different version of the same DLL. If "Specific Version" is set to TRUE, and you uninstall/delete some dependency of the project, then Visual Studio will place a little exclamation mark over that reference in the Solution Explorer. If "Specific Version" is set to FALSE, and there is ANOTHER VERSION of that DLL available (assuming VS can find it), then Visual Studio will fall back to referencing that DLL instead. Of course, this will only manifest the next time you build... your new output will be referencing the 'fallback DLL'.

    The resulting output is the same, however - in that whatever DLL version your project was referencing when it was compiled, is the DLL version that will be REQUIRED at runtime - it CANNOT be substituted by another version (I am, of course, referring only to strongly named DLLs here, and ignoring explicitly declared version redirection).

    What this means for your specific scenario - is that in the case where you are NOT using specific versioning - you will need to track what dependencies your project had when you compiled them (Excel Spreadsheet anyone? Yuck...) - because you will not be able to guarantee if you look in your source control, that the version the project is referencing is the one that actually got compiled into the project. Of course, you should be keeping copies of all the binaries you release into the wild, so you can inspect those to see what got deployed to the customer...

    To answer your question - no, you do not have to deploy the main project - you just need to know the version of those dependency projects, at the time you deployed them, so you can EITHER build a compatible hot-fix...

    • compatible: the DLL looks the same from the outside, same classes/properties/methods etc
    • hot-fix: keeping the assembly version the same as the one in the wild) -

    ...OR write a new DLL and do an assembly binding redirect from the old version to the new version.