Chọn động tại thời gian chạy phiên bản nào của .dll để sử dụng

Question

Tôi đang làm việc trên tiện ích dành cho SharePoint. Đây là một ứng dụng hoạt động cho cả SharePoint 2007 và 2010. Khi tôi có tham chiếu đến phiên bản 12.0.0.0 của SharePoint.dll, ứng dụng hoạt động cho SharePoint 2007, nhưng không phải cho năm 2010. Nếu tôi tham chiếu phiên bản 14.0.0.0 của dll, sau đó các ứng dụng hoạt động tuyệt vời cho năm 2010, nhưng không cho năm 2007.

Tôi có thể dễ dàng cho biết .dll mà tôi cần sử dụng bằng cách nhìn vào hệ thống tập tin với mã sau đây, kiểm tra 12 trong đường dẫn (SharePoint 2007) hoặc 14 (SharePoint 2010).

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

Khi xây dựng, tôi làm tài liệu tham khảo trong Visual Studio, vì vậy nó được xây dựng trong hai năm 2007 hoặc 2010. Tôi muốn để có thể phát hành các ứng dụng mà nó hoạt động trên CẢ phiên bản của SharePoint. Vì vậy, tôi cần một số cách để tải/sử dụng bất cứ điều gì .dll có ý nghĩa cho người dùng chạy ứng dụng.

Làm cách nào để tự động chọn và tải .dll trong thời gian chạy?

Answer 1

Reflection? Dependency Injection? Bạn đang làm cho cuộc sống khó khăn cho chính mình!

Compile chống Microsoft.SharePoint.dll v12 và nó sẽ làm việc trên 2007.

Triển khai đến năm 2010 và nó sẽ 'chỉ làm việc' (trong hầu hết các trường hợp) như SharePoint 2010 đã có ràng buộc chuyển hướng thiết lập để bất kỳ tham chiếu đến v12 sẽ được chuyển hướng đến v14.

Bạn không cần phải làm bất kỳ điều gì về cấu hình một cách khôn ngoan.

Các tình huống duy nhất mà bạn cần phải nhận được phức tạp hơn này là

• Instances nơi một cái gì đó sẽ làm việc vào năm 2007 nhưng không phải trên 2010 (tôi không thể nghĩ về bất cứ điều gì để tay).

• Nơi bạn có thể muốn sử dụng các tính năng cụ thể của năm 2010.

Nếu trường hợp này xảy ra thì cá nhân tôi sẽ làm là biên dịch kép. Sửa đổi tệp .csproj để tạo ra 2 phiên bản hơi khác nhau, sử dụng tham số và biên dịch có điều kiện (giống như bạn làm với #if DEBUG) cho các phiên bản mã sản phẩm cụ thể khi cần thiết (sẽ có rất ít trong số này). Bạn cũng có thể sử dụng các điều kiện này trong các tham chiếu trong .csproj ví dụ:

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

Nhược

• Bạn kết thúc với 2 phiên bản của chương trình bạn

Ưu

• Bạn kết thúc với 2 phiên bản của chương trình của bạn! Nhiều thay đổi bạn có thể muốn thực hiện trong phiên bản 2010 sẽ có trong manifet.xml, feature.xml và các tệp cấu hình khác - sự phản chiếu, tiêm phụ thuộc v.v. sẽ không làm bất cứ điều gì cho bạn ở đây.
• Vẫn có một phiên bản mã nguồn duy nhất (với biên dịch có điều kiện nhỏ)
• Trình biên dịch sẽ nhận thêm lỗi (ví dụ: không thể tìm ra thời gian biên dịch mà bạn đang làm với Reflection để gọi phương pháp mới trong v14 sẽ thực sự hoạt động)

Answer 2

Tôi nghĩ bạn cần xem xét chuyển hướng ràng buộc lắp ráp trong khung công tác.

http://msdn.microsoft.com/en-us/library/2fc472t2.aspx

Bạn có thể sử dụng 'công cụ cấu hình khung lưới' để cấu hình chuyển hướng.

Answer 3

Bằng cách AppDomain.AssemblyResolve, bạn có thể kiểm tra sự tồn tại của các DLL và trả lại bất cứ một hiện diện:

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! 
    } 
}; 

Một chuyển hướng lắp ráp ràng buộc sẽ không làm việc cho bạn trong trường hợp này bởi vì đó là tĩnh trong tệp cấu hình của bạn và bạn muốn tệp này hoạt động động trên bất kỳ máy nào có SP2007 hoặc SP2010.

Answer 4

Điều này nghe có vẻ giống như một trường hợp tuyệt vời cho Dependency Injection sử dụng một trong các khung DI như Unity hoặc Castle Windsor. Có những người khác ngoài kia, nhưng tôi đã mạo hiểm một cuộc chiến tôn giáo chỉ bằng cách đề cập đến hai cuộc chiến này. :)

Answer 5

Bạn cần sử dụng sự phản chiếu. Hãy xem Assembly.LoadFile và Assembly.Load.

Nếu bạn cần phải làm việc với các phương pháp lớp học trong đó bạn có thể sử dụng nó như thế này:

 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 
     }