在运行时动态选择要使用的.dll版本 [英] Choose dynamically at runtime which version of a .dll to use

查看:168
本文介绍了在运行时动态选择要使用的.dll版本的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在使用SharePoint的实用工具。这是一个适用于SharePoint 2007和2010的应用程序。当我引用了12.0.0.0版本的SharePoint.dll时,该应用程序适用于SharePoint 2007,但不适用于2010年。如果引用14.0.0.0版本的dll,那么这个应用程序在2010年应用的很好,但不是2007年。



我可以通过查看文件系统来轻松地告诉我需要使用哪个以下代码,检查路径中的12(SharePoint 2007)或14(SharePoint 2010)。

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

在开发过程中,我在Visual Studio中提供参考,因此它可以在2007年或2010年建立。希望能够发布适用于 BOTH 的SharePoint版本的应用程序。所以,我需要一些方法来加载/使用任何.dll对运行该应用程序的用户是有意义的。



如何动态选择和加载一个.dll在运行时?

解决方案

反思?依赖注射?你正在为自己而努力!



编译Microsoft.SharePoint.dll v12,它将在2007年工作。



部署到2010年,它将工作(几乎所有情况),因为 SharePoint 2010已经具有绑定重定向设置,所以对v12的任何引用将被重定向到v14。



您不需要明智地做任何配置。



您需要比这更复杂的唯一情况是




  • 2007年发生什么事情
    的实例,但不在2010年(我不能
    想到


  • 您可能希望利用2010年的具体功能。




如果是这样的话,我个人会做的是双重编译。修改.csproj文件以产生2个稍微不同的版本,使用参数和条件编译(就像您使用#if DEBUG一样),对于特定产品版本的代码,必要时(将很少有这些)。您也可以在.csproj中的引用中使用这些条件,例如。

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

缺点




    <你最终得到
    程序的两个版本


优点




  • 最终你的程序有2个版本!许多您可能希望在2010版本中进行的更改将在manifestet.xml,feature.xml和其他配置文件中进行。反射,依赖注入等不会为您做任何事情。

  • 仍然有一个单一版本的源代码(具有较小的条件编译)

  • 编译器将会收到更多错误(例如,在编译时无法确定您正在使用Reflection的funky事情在v14中调用新的方法实际上可以正常工作)


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

  • 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)

这篇关于在运行时动态选择要使用的.dll版本的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆