2010-03-22 8 views
6

Per vari motivi preferisco non utilizzare assembly con un nome sicuro (firmato) nel mio progetto. tuttavia, uno dei progetti è referenziato da una web part sharepoint che significa che deve essere firmato.C#: è possibile creare un riferimento all'assieme "debole" a un assembly con un nome sicuro

è possibile avere questo assembly firmato ma quando faccio riferimento ad altri progetti, per farlo utilizzando un riferimento non forte. questo mi darebbe i vantaggi di avere un assembly non firmato per il resto del mio codice, ma permetterò comunque che venga caricato da sharepoint.

risposta

3

Il modo più semplice per eseguire questa operazione è probabilmente disporre di due diverse configurazioni di progetto, una delle quali crea un assembly con un nome molto elevato e uno non lo fa. Ovviamente è necessario fare attenzione a come si costruisce e si fa riferimento all'assembly, ma ciò si accompagna al territorio in cui si hanno requisiti in conflitto.

+0

Come impostare "due diverse configurazioni di progetto" in Visual Studio? –

+0

@PavelChuchuva: vedere http://msdn.microsoft.com/en-us/library/kkz9kefa.aspx –

+0

L'elenco a discesa della configurazione è disabilitato nella scheda Firma nelle proprietà del progetto: http://i.imgur.com/vwZKy. png –

0

Questo è il PO, ma io non ho un OpenID login quindi immagino di non poter rispondere come me stesso.

Grazie per entrambe le risposte. Penso che entrambi avrebbero funzionato, ma la situazione si è rivelata un po 'più complessa. Ho documentato le mie scoperte qui nel caso in cui qualcun altro fosse interessato.

In realtà i riferimenti SharePoint assemblaggio e montaggio A A sua volta i riferimenti di montaggio B.

posso costruire il montaggio A e B sia firmato con nessun problema, ma poi se voglio firmare A, devo cambiare la progetto stesso per fare riferimento alla versione firmata dell'assembly B.

Anche se ci potrebbe essere stato un modo per farlo, abbiamo deciso che i possibili conflitti di DLL e problemi di controllo della configurazione con avere diversi set di DLL con lo stesso nome non valevano la pena problemi.

Quindi abbiamo deciso di firmare entrambi questi assembly in tutte le build, rielaborando il codice in diversi assembly dove necessario per assicurarsi che solo la quantità minima di codice sia nelle firme firmate in modo che abbiano meno probabilità di cambiare.

Tim