views:

106

answers:

2

Hi,

we are using some kind of plug-in architecture in one of our products (based on .NET). We have to consider our customers or even 3rd party devs writing plug-ins for the product. The plug-ins will be .NET assemblies that are loaded by our product at run-time. We have no control about the quality or capabilities of the external plug-ins (apart from checking whether they implement the correct interfaces).

So we need to implement some kind of safety check while loading the plug-ins to make sure that our product (and the hosting environment) can actually host the plug-in or deliver a meaningful error message ("The plug-in your are loading needs .NET version 42.42 - the hosting system is only on version 33.33.").

Ideally the plug-ins would do this check internally, but our experience regarding their competence is so-so and in any case our product will get the blame, so we want to make sure that this "just works". Requiring the plug-in developers to provide the info in the metadata or to explicitly provide the information in the interface is considered "too complicated".

I know about the Assembly.ImageRuntimeVersion property. But to my knowledge this tells me only the needed CLR version, not the framework version. And I don't want to check all of the assembly's dependencies and match them against a table of "framework version vs. available assemblies".

Do you have any ideas how to solve this in a simple and maintainable

fashion?

Thanks & regards, Bon

+1  A: 

Hi there.

I really don't think this can be done. I've been researching into this and many other people have asked the same question, for example:

http://www.developersdex.com/csharp/message.asp?p=1111&r=6905306

For each question the answer seems the same - you will need to iterate through the referenced assemblies of the target assembly and analyse those to work out which version of the .NET framework is being used.

EDIT:

Not sure if it's any help, but you could use something like this:

static void Main()
        {
            var g = Assembly.GetExecutingAssembly().GetReferencedAssemblies();

            foreach (AssemblyName assemblyName in g)
            {
                Console.WriteLine(assemblyName.FullName);
                Console.WriteLine(assemblyName.Version);

            }
        }

So you can iterate through the referenced assembly of the third-party assembly, looking for 'mscorlib' and checking its version.

Cheers. Jas.

Jason Evans
This is probably the best you can do. However, it should be borne that this does not cover dynamically loaded assemblies and references to native libraries. In addition, there might be other non-code related dependencies that a plug-in might rely on, e.g. the existance of Registry settings, the availability of services etc.
0xA3
Thanks for the link, looks like I have to bite the bullet.
Bonfire Burns
+1  A: 

The CLR version is the .NET framework version. .NET 3.0, 3.5 and 3.5 SP1 only distinguish themselves by adding assemblies to the original 2.0 set. Accordingly, the base assemblies for 3.5 SP1 still carry a 2.0.0.0 [AssemblyVersion]. You can see this in the Add Reference dialog.

Hans Passant
It's often forgotten that e.g. .NET 3.0 brings more than just additional assemblies. There are also additional services, native images, Registry settings etc. so it's unfortunately not as simple as just deploying some additional referenced assemblies.
0xA3