Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Choose dynamically at runtime which version of a .dll to use

I'm working on a utility for SharePoint. It's an app that works for both SharePoint 2007 and 2010. When I have a reference to the 12.0.0.0 version of the SharePoint.dll, the app works for SharePoint 2007, but not for 2010. If I reference version 14.0.0.0 of the dll, then the app works great for 2010, but not for 2007.

I can easily tell which .dll that I need to use by looking on the file system with the following code, checking for 12 in the path (SharePoint 2007) or 14 (SharePoint 2010).

System.IO.File.Exists(
                    Environment.GetFolderPath(Environment.SpecialFolder.CommonProgramFiles) + 
                    @"\Microsoft Shared\web server extensions\14\ISAPI\Microsoft.SharePoint.dll"));

When developing, I make the reference in Visual Studio, so it builds either for 2007 or 2010. I want to be able to release the app where it works on BOTH version of SharePoint. So, I need some way to load/use whatever .dll makes sense for the user running the app.

How do I dynamically choose and load a .dll at runtime?

like image 987
Ryan Hayes Avatar asked Aug 15 '10 18:08

Ryan Hayes


3 Answers

Reflection? Dependency Injection? You are making life hard for yourself!

Compile against Microsoft.SharePoint.dll v12 and it will work on 2007.

Deploy to 2010 and it will 'just work' (in nearly all cases) as SharePoint 2010 already has binding redirects setup so any reference to v12 will be redirected to v14.

You don't need to do anything configuration wise.

The only situations where you need to get more complex than this are

  • Instances where something would work on 2007 but not on 2010 (I can't think of anything to hand).

  • Where you may want to make use of 2010 specific features.

If this is the case then what I, personally, would do is to dual compile. Modify the .csproj file to produce 2 slightly different versions, use a parameter and conditional compilation (just like you would with #if DEBUG) for product specific versions of code where necessary (there will be very few of these). You can also use these conditions in the references in .csproj e.g.

 <Reference Include="Microsoft.SharePoint">
    <HintPath Condition="'$(SP2010)'!='true'">PathToV12\Microsoft.SharePoint.dll</HintPath>
    <HintPath Condition="'$(SP2010)'=='true'">PathToV14\Microsoft.SharePoint.dll</HintPath>        
 </Reference>

Disadvantages

  • You end up with 2 versions of your program

Advantages

  • You end up with 2 versions of your program! Many of the changes you might want to make in the 2010 version would be in manifet.xml, feature.xml and the other config files - reflection, dependancy injection etc isn't going to do anything for you here.
  • Still have a single version of source code (with minor conditional compilation)
  • Compiler will pick up more errors (it can't for example figure out at compile time that that funky thing you are doing with Reflection to call a new method in v14 will actually work)
like image 185
Ryan Avatar answered Oct 16 '22 15:10

Ryan


You need to use reflection. Have a look at Assembly.LoadFile and Assembly.Load.

If you need to work with class methods in it you can use it like this :

        Assembly u = Assembly.LoadFile(path);
        Type t = u.GetType(class title);
        if (t != null)
        {
            MethodInfo m = t.GetMethod(method);
            if (m != null)
            {
                if (parameters.Length >= 1)
                {
                    object[] myparam = new object[1];
                    myparam[0] = ......;
                    return (string)m.Invoke(null, myparam);
                }
                else
                {
                    return (string)m.Invoke(null, null);
                }
            }
        }
        else
        {
             // throw exception. type not found
        }
like image 32
Incognito Avatar answered Oct 16 '22 15:10

Incognito


By way of AppDomain.AssemblyResolve, you can check for the existence of the DLL and return whichever one is present:

AppDomain.AssemblyResolve += delegate(object sender, ResolveEventArgs e)
{
    if (e.Name == "Microsoft.SharePoint")
    {
        // do your check here and return the appropriate Assembly
        // or maybe just skip an explicit check and instead return either
        // Assembly.Load("Microsoft.SharePoint, Version=14.0.0.0") or
        // Assembly.Load("Microsoft.SharePoint, Version=12.0.0.0"), whichever works first
        // but beware of recursion!
    }
};

An assembly binding redirect won't work for you in this case because that is static in your config file and you want this to dynamically work on any machine with either SP2007 or SP2010.

like image 42
Kent Boogaart Avatar answered Oct 16 '22 16:10

Kent Boogaart