Scegli dinamicamente in runtime quale versione di .dll usare

Question

Sto lavorando a un'utilità per SharePoint. È un'applicazione che funziona sia per SharePoint 2007 che per il 2010. Quando ho un riferimento alla versione 12.0.0.0 di SharePoint.dll, l'app funziona per SharePoint 2007, ma non per il 2010. Se faccio riferimento alla versione 14.0.0.0 del dll, quindi l'app funziona alla grande per il 2010, ma non per il 2007.

Posso facilmente dire quale .dll che devo usare cercando sul file system con il seguente codice, cercando 12 nel percorso (SharePoint 2007) o 14 (SharePoint 2010).

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

Durante lo sviluppo, faccio il riferimento in Visual Studio, in modo che costruisce sia per il 2007 o il 2010. Voglio essere in grado di rilasciare l'applicazione in cui si lavora su ENTRAMBI versione di SharePoint. Quindi, ho bisogno di un modo per caricare/utilizzare qualsiasi cosa. Dll ha senso per l'utente che esegue l'app.

Come faccio a scegliere e caricare dinamicamente una DLL al runtime?

Answer 1

riflessione? Iniezione di dipendenza? Stai rendendo la vita dura per te!

Compile contro Microsoft.SharePoint.dll V12 e funzionerà su 2007.

Distribuire al 2010 e sarà 'solo il lavoro' (in quasi tutti i casi) come SharePoint 2010 è già vincolante reindirizza l'installazione in modo che qualsiasi il riferimento a v12 verrà reindirizzato a v14.

Non è necessario eseguire alcuna configurazione.

Le uniche situazioni in cui è necessario per ottenere più complessa di questo sono

• I casi in cui qualcosa sarebbe lavorare al 2007, ma non rispetto al 2010 (non riesco a pensare a niente a portata di mano).

• Dove si desidera utilizzare le funzionalità specifiche del 2010.

Se questo è il caso allora quello che, personalmente, farei è quello di doppia compilazione. Modifica il file .csproj per produrre 2 versioni leggermente diverse, usa un parametro e una compilazione condizionale (proprio come faresti con #if DEBUG) per le versioni specifiche del codice del prodotto dove necessario (ce ne saranno davvero poche). È inoltre possibile utilizzare queste condizioni nei riferimenti in .csproj, ad es.

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

Svantaggi

• si finisce con 2 versioni del programma

Vantaggi

• Si finisce con 2 versioni del programma! Molte delle modifiche che potresti voler fare nella versione 2010 dovrebbero essere in manifet.xml, feature.xml e gli altri file di configurazione: riflessione, dipendenza, ecc non faranno nulla per te qui.
• Ancora una singola versione del codice sorgente (con compilazione condizionale minore)
• Il compilatore raccoglierà più errori (non è possibile ad esempio capire al momento della compilazione che quella cosa funky che si sta facendo con Reflection per chiamare un il nuovo metodo in v14 funzionerà effettivamente)

Answer 2

Penso che sia necessario esaminare il reindirizzamento del binding dell'assieme nel framework.

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

È possibile utilizzare il 'strumento di configurazione .net framework' per configurare il reindirizzamento.

Answer 3

A titolo di AppDomain.AssemblyResolve, è possibile verificare l'esistenza della DLL e tornare a seconda di quale uno è presente:

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

Un reindirizzamento di associazione di assembly non funziona per voi, in questo caso, perché questo è statico il tuo file di configurazione e vuoi che funzioni in modo dinamico su qualsiasi macchina con SP2007 o SP2010.

Answer 4

Questo sembra un ottimo caso per Iniezione delle dipendenze utilizzando uno dei framework DI come Unity o Castle Windsor. Ce ne sono altri là fuori, ma sto già rischiando una guerra religiosa semplicemente citando questi due. :)

Answer 5

È necessario utilizzare la riflessione. Date un'occhiata a Assembly.LoadFile e Assembly.Load.

Se avete bisogno di lavorare con i metodi di classe in esso si può usare in questo modo:

 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 
     }