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?
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
Advantages
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
}
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With