2010-11-14 5 views
6

La situazione è la seguente:Rilascio dell'origine della libreria di classi, senza firma del file chiave, ma i test unitari richiedono l'accesso alle classi interne, cosa fare?

  1. voglio rilasciare il sorgente completo per una libreria di classi
  2. Voglio liberare i binari e, firmata da me, con un file di chiave che non voglio Pubblicare
  3. Fornirò file batch e stepbuild pre-build, che creano un nuovo file di chiavi localmente se non presente, in modo che chiunque possa iniziare rapidamente a utilizzare il codice sorgente
  4. Il progetto di test deve fare riferimento a una classe interna in il progetto principale
  5. Per accedere al classe interna, ho bisogno di aggiungere un attributo [assembly: InternalsVisibleTo("...")] ai principali AssemblyInfo.cs file di progetto
  6. Dal momento che sto firmando l'output del progetto, ho bisogno di specificare una parte PublicKey di quell'attributo
  7. Questo sarà quindi vincolato al file chiave, che non sono disposto a pubblicare

Quindi, come posso risolvere questo?

Se firmo l'uscita principale del progetto, e non la libreria di test, e si specifica solo il nome assembly nell'attributo InternalsVisibleTo, ottengo questo errore di compilazione:

Error 1 Friend assembly reference 'Mercurial.Net.Tests' is invalid. Strong-name signed assemblies must specify a public key in their InternalsVisibleTo declarations. C:\Dev\VS.NET\Mercurial.Net\Mercurial.Net\Properties\AssemblyInfo.cs 22 31 Mercurial.Net

Quindi a quanto pare non firmare il test l'output del progetto non è abbastanza

È la mia unica opzione per rimuovere le impostazioni che firmano i progetti e modificare i file di progetto come parte dello script di compilazione dei miei binari? vale a dire. cacciare l'elemento <SignAssembly>false</SignAssembly> del file di progetto e modificarlo, prima di costruire?

risposta

2

È un'opzione per avere un file SNK rilasciato solo per il test?

Si può quindi avere due InternalsVisibleTo e passare quale si utilizza con una #if, ad es .:

#if FOR_RELEASE 
[InternalsVisibleTo(... your private SNK ...)] 
#else 
[InternalsVisibleTo(... test SNK which you release ...)] 
#endif 

È quindi possibile impostare FOR_RELEASE quando si sta creando il build che si desidera pubblicare.

+0

Sì, sembra un piano. –

+0

Ho usato solo '#if DEBUG', RELEASE-build ora richiede la mia chiave privata, e posso facilmente scriptare quella parte come parte dello script che produrrà i miei binari. Non sono ancora lì comunque, quindi mi occuperò di quella parte più tardi. Buone opzioni da tutte le risposte qui però, ma questo era quello che ho finito per fare, quindi ho accettato questo. –

+0

Beh, ecco qua. Sono contento di poterti aiutare. –

1

Quello che ho fatto con i miei progetti OS è semplice: ho un SNK privato che utilizzo solo quando realizzo i progetti per una versione. I progetti sono firmati solo quando compilo per un rilascio e normalmente i progetti non fanno riferimento a un SNK. Ciò semplifica l'utilizzo dell'attributo InternalsVisibleTo, perché senza un SNK funziona sempre.

1

Un #ifdef salta in mente, utilizzando una chiave "eval" a cui non ti importa.

Problemi correlati