As known, Revit API libraries are not strong named.
We talked about the benefits of the fact for the Revit API SDK itself. Obviously, it avoids a lot of maintenance and support work and different version Revit API libraries seem to be compatible, judging from the loading perspective only. The fact is they are NOT compatible at all, as discussed in detail before.
Now, let's talk about what it gives Revit addin developers.
The most prominent thing is that of course our Revit addins have to be non-strong-named as well because of the simple fact that strong named assemblies can not reference to non-strong-named such as the Revit API libs. From the other side though, non-strong-named assemblies can refer to strong-named assemblies such as almost all those native .NET assemblies.
It looks good as the same addins could be theoretically loaded into different Revit versions and flavors. However, it does not really bring about any good results, only weird behavior here and there as analyzed earlier. In addition, it causes serious assembly mix-up loading problems (the DLL Hell as called in the old C/C++ era) in case the names of your assemblies are too common, including not only the main one but also dependant ones, such as RevitTools.dll, Tools.dll, Managers.dll, LIBs.dll and so on. If other people have the same named assemblies deployed to the same Revit platform, users will get assembly loading issues now and then.
So, it is not good in practise. That is exactly what strong-named mechanism tries hard to resolve, which practice the .NET Framework development and deployment have been following, from our understanding. By the way, in case the strong-name key (or the assembly token) and the assembly name along with version number are the same, the size and date of the assembly itself do not seem to matter as far as the assembly identification is concerned. That may be what the .NET Framework updating system applies since their new versions and updates are also coming out from time to time. In that way, .NET users can avoid the DLL Hell in each major .NET Framework upgrade and are not interrupted by each minor update either. Of course, that practice may just look so over killed for a simple SDK like Revit API. People can understand.
So, it looks quite necessary to add some developer symbol/prefix to every Revit API assembly to avoid troubles like such. The Revit Addin Wizard (RevitAddinWizard) will think about adding this feature in the future.
Our Software http://netspiderstudio.com/Software.html