0

If you've used two or more open sourced frameworks then I'm sure you've come across the following problem. 

Project 1
   FrameWork 1 - v2.0
   FrameWork 2 - v1.0
     FrameWork 1 - v1.0

Project 1 has references to Framework 1 & 2, whilst Framework 2 contains a reference to Framework 1. Unfortunately there is a breaking change in v2.0 of Framework 1 and whilst Project 1 needs v2.0, Framework 2 will only work with v1.0. As the assemblies and namespaces are the same, they can't live happily alongside each other (unless you require that they go into the GAC).

However, if at the time the open sourced frameworks were built they had the version number included into the namespace and assembly name it would negate all of this. Any number of the same framework could live happyily alongside each other in the same bin folder / appDomain. Of course there is the question of how to get this incorporated into open sourced frameworks as it is a manual step, but it would solve the problem for everyone that consumes it. Wouldn't it?

Paul Hadfield
  • 6,088
  • 2
  • 35
  • 56
  • Are you allergic to GAC? – Task Sep 10 '10 at 13:56
  • @Task: The GAC adds an extra level of complexity to deployment, etc. Also to put something in the GAC then you need to sign it, which means compiling the open sourced framework to assign a strong name. Then any strong named assemblies that reference other assemblies require that those referenced assemblies are also strong named and so on. Not sure if this is any better or less complex than the above, but that would still work with xcopy deployment. – Paul Hadfield Sep 10 '10 at 14:04
  • Signing an assembly is a 5 second task that you do once. Basic installers easily install assemblies into the GAC. This isn't a significant amount of complexity. Is there some reason for a *framework* to not be in the GAC? Do you think it would be acceptable if mscorlib and System.dll were local assemblies? I don't think 'being open source' is an excuse for laziness; frameworks should be GAC'ed and applications should have installers. You understand the problem with local DLLs, you know the solution: Just GAC it! (tm) – Task Sep 10 '10 at 14:14

1 Answers1

0

It's a double-edged sword:

So, to sum up, a strongly named assembly uses more than just the simple name to determine an assembly's identity - changing its version could be thought of as changing its name completely.

References

Community
  • 1
  • 1
Paul Sweatte
  • 24,148
  • 7
  • 127
  • 265