I think you need to look at assembly binding redirection in the framework.
http://msdn.microsoft.com/en-us/library/2fc472t2.aspx
You can use the '.net framework configuration tool' to configure the redirection.
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.
HTH,
Kent
This sounds like a great case for Dependency Injection using one of the DI frameworks like Unity or Castle Windsor. There are others out there, but I'm already risking a religious war simply by mentioning these two. :)
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
}
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