|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Dealing with Evolving AssembliesI'm in the process of amassing a set of .NET support libraries that I use in many of my projects.
In a number of cases instances of Types from these libraries are created indirectly (e.g., my calling Invoke on a ConstructorInfo object derived from the Type). Since I strong-name the assemblies this tends to cause a problem as the libraries evolve because the assembly-qualified name of a Type changes whenever the version of the strong-named assembly changes. Since this can hardly be a novel issue (but it's not one I've been successful googling, probaby because it's abstract), I'd love to hear ideas for best practices. Or should I just stop strong-naming the assemblies? - Mark Hi Mark,
Yes, strongnamed assembly need to match the qualified name(e.g. the version, name, culture... need to be same). Commonly the strongnamed assembly is most used for share assembly and put it into GAC. Commonly we will not update a strongnamed assembly very frequently. In case the version is changed, we can deploy another version of the strong named assembly, that is to say two version of the same assembly can coexist. We can use the <bindingRedirect> Element to tell the runtime to bind to another version B when it want version A. Redirecting Assembly Versions http://msdn2.microsoft.com/en-us/library/7wd6ex19.aspx Or you can maintain the assembly version unchangable. Otherwise, I think you may try to use a private assembly(not strong named assembly). Best regards, Peter Huang Microsoft Online Partner Support Get Secure! - www.microsoft.com/security This posting is provided "AS IS" with no warranties, and confers no rights. |
|||||||||||||||||||||||