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

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

问题描述

我正在开发适用于 SharePoint 的实用程序.这是一个适用于 SharePoint 2007 和 2010 的应用程序.当我引用 12.0.0.0 版本的 SharePoint.dll 时,该应用程序适用于 SharePoint 2007,但不适用于 2010.如果我引用了 14.0.0.0 版dll,那么该应用程序在 2010 年运行良好,但不适用于 2007 年.

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.

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

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 Sharedweb server extensions14ISAPIMicrosoft.SharePoint.dll"));

在开发时,我在 Visual Studio 中进行引用,因此它是为 2007 或 2010 构建的.我希望能够发布适用于 BOTH 版本的 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.

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

推荐答案

反思?依赖注入?你是在给自己找麻烦!

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

针对 Microsoft.SharePoint.dll v12 编译,它将在 2007 上运行.

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

部署到 2010,它将正常工作"(几乎在所有情况下),因为 SharePoint 2010 已经设置了绑定重定向,因此对 v12 的任何引用都将重定向到 v14.

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

  • 可以发挥作用的实例在 2007 年但不是在 2010 年(我不能想想手头的任何东西).

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

您可能希望使用 2010 年特定功能的地方.

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

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

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'">PathToV12Microsoft.SharePoint.dll</HintPath>
    <HintPath Condition="'$(SP2010)'=='true'">PathToV14Microsoft.SharePoint.dll</HintPath>        
 </Reference>

缺点

  • 您最终会得到 2 个版本的程序

优势

  • 您最终得到了 2 个版本的程序!您可能希望在 2010 版本中进行的许多更改都在 manifet.xml、feature.xml 和其他配置文件中 - 反射、依赖注入等在这里不会为您做任何事情.
  • 仍然只有一个版本的源代码(带有少量条件编译)
  • 编译器会发现更多错误(例如,它无法在编译时确定您正在使用反射来调用 v14 中的新方法的时髦事情实际上会起作用)

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

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