Perché sto ottenendo 'Assembly' * .dll 'deve essere fortemente firmato per essere contrassegnato come prerequisito.'?

Sto cercando di compilare il mio componente aggiuntivo Excel utilizzando C # 4.0 e ho iniziato a riscontrare questo problema durante la creazione del mio progetto in Visual Studio. È importante dirti che non ho mai avuto questo problema prima. Cosa potrebbe causare ciò?

La mia ipotesi è che non stai lavorando con assemblee con un nome forte. Ho avuto questo errore quando due progetti fanno riferimento a versioni leggermente diverse dello stesso assieme e un progetto più dipendente fa riferimento a questi progetti. La risoluzione nel mio caso era quella di rimuovere la chiave e le informazioni sulla versione dal nome dell'assembly nei file .csproj (non importava comunque), e quindi fare una build pulita.

Le modifiche tra le diverse versioni dell'assieme erano compatibili con le parti della soluzione che si riferivano ad esse. Se questo non è il tuo caso, potresti dover fare un po 'più di lavoro per risolvere il problema.

NuGet

Con NuGet è facile entrare in questa situazione se:

1. Installi un pacchetto in un progetto nella tua soluzione.
2. Una nuova versione di quel pacchetto viene distribuita all'origine del pacchetto.
3. Lo installi in un altro progetto nella stessa soluzione.

Ciò comporta due progetti nella soluzione che fanno riferimento a versioni diverse degli assiemi di quel pacchetto. Se uno di essi fa riferimento all'altro ed è un'app ClickOnce, vedrai questo problema.

Per risolvere questo problema, emettere il update-package [package name]comando nella console di Nuget Package Manager per portare tutto su un piano di parità, a quel punto il problema scompare.

È necessario gestire i pacchetti NuGet a livello di soluzione anziché a livello di progetto, a meno che non vi siano motivi validi per non farlo. La gestione dei pacchetti a livello di soluzione evita il potenziale di più versioni di dipendenze. Quando si utilizza l'interfaccia utente di gestione, se la scheda Consolidato mostra 1 o più pacchetti hanno più versioni, considerare di consolidarli in uno.

Quando ho riscontrato questo problema, l'ho risolto disattivando "Abilita impostazioni di sicurezza ClickOnce".

Menu: Progetto | Proprietà "Nome progetto" ... | Scheda Sicurezza | Casella di controllo "Abilita impostazioni di sicurezza ClickOnce".

Vedere questo risposta .

Vai alla pagina di pubblicazione e fai clic su "File dell'applicazione". Da lì dovresti vedere un elenco delle tue DLL. Assicurati che quelli che ti danno problemi abbiano il loro stato di pubblicazione contrassegnato come "Includi" anziché "Prerequisito".

Ho avuto questo problema. È successo perché avevo molti progetti che puntavano allo stesso assemblaggio ma da versioni diverse. Lo risolvo selezionando la stessa versione per tutti i progetti nella mia soluzione.

Se è stata modificata la versione dell'assembly o è stata copiata una versione diversa della libreria gestita indicata nell'errore, è possibile che siano stati compilati in precedenza file che fanno riferimento alla versione errata. Un 'Ricostruisci tutto' (o eliminando le cartelle 'bin e' obj 'come menzionato in un commento precedente) dovrebbe risolvere questo caso.

devi firmare l'assemblea con una chiave. Vai nelle proprietà del progetto sotto la scheda firma:

Aggiungere la mia soluzione a questo problema per chiunque potrebbe essere d'aiuto.

Ho avuto una soluzione ClickOnce che lanciava questo errore. L'app faceva riferimento a una cartella "Libs" comune e conteneva un riferimento al progetto a Foo.dll. Mentre nessuno dei progetti nella soluzione Foo.dllfaceva riferimento alla copia statica della cartella "Libs", alcuni dei riferimenti in quella cartella lo facevano (cioè: la mia soluzione aveva riferimenti a Libs\Bar.dllcui faceva riferimento Foo.dll.) Poiché l'app di CO estraeva tutte le dipendenze da Libscosì come le loro dipendenze, entrambe le copie stavano andando nel progetto. Questo stava generando l'errore sopra.

Ho risolto il problema spostando la mia Libs\Foo.dllversione statica in una sottocartella, Libs\Fix\Foo.dll. Questa modifica ha fatto sì che l'app ClickOnce usasse solo la versione del progetto della DLL e l'errore è scomparso.

L'eliminazione della DLL (dove si è verificato l'errore) e la ricostruzione della soluzione hanno risolto il mio problema. Grazie

Se hai provato tutte le altre risposte a questa domanda e tu:

• Avere più progetti nella tua soluzione
• Avere un progetto (Progetto A) che fa riferimento a un altro progetto (Progetto B), il cui progetto fa riferimento a un pacchetto NuGet.
• Nel progetto A, è stato utilizzato Intellisense / ReSharper per inserire il riferimento al pacchetto NuGet a cui si fa riferimento nel progetto B (ciò può accadere quando un metodo nel progetto B restituisce un tipo fornito dal pacchetto NuGet e tale metodo viene utilizzato nel progetto A)
• aggiornato il pacchetto NuGet tramite NuGet Package Manager (o CLI).

... potresti avere versioni separate della DLL dei pacchetti NuGet nei riferimenti dei tuoi progetti, poiché il riferimento creato da Intellisense / ReSharper sarà un riferimento "normale" e non un riferimento NuGet come previsto, quindi il processo di aggiornamento di NuGet ha vinto " non trovarlo o aggiornarlo!

Per risolvere questo problema, rimuovere il riferimento nel Progetto A, quindi utilizzare NuGet per installarlo e assicurarsi che i pacchetti NuGet in tutti i progetti abbiano la stessa versione. (come spiegato in questa risposta )

Consiglio Life Pro:

Questo problema può presentarsi ogni volta che ReSharper / Intellisense suggerisce di aggiungere un riferimento al progetto. Può essere molto più contorto rispetto all'esempio sopra, con molteplici progetti e dipendenze che si intrecciano rendendo difficile rintracciare. Se il riferimento suggerito da ReSharper / Intellisense proviene effettivamente da un pacchetto NuGet, utilizzare NuGet per installarlo.

Quando questo è successo a me con WindowsAPICodePack dopo averlo aggiornato, ho appena ricostruito la soluzione.

Crea -> Ricostruisci soluzione

C'erano troppi progetti nella mia soluzione per passare e aggiornare individualmente, quindi ho risolto questo problema con:

• Fare clic con il tasto destro del mouse sulla mia soluzione e selezionare "Gestisci pacchetti NuGet per soluzione ..."
• Vai alla scheda Aggiornamenti
• Trovare il pacchetto interessato e selezionare Aggiorna
• Fare clic su OK e questo ha aggiornato tutte le istanze del pacchetto

Scaricare e ricaricare il progetto problema risolto per me.

Sono andato a pubblicare , i file dell'applicazione, ho trovato che la DLL che lanciava l'errore lo ha cambiato in 'Includi' da 'Includi (Auto)'. Ora posso pubblicare.

Ho riscontrato questo problema dopo la migrazione di un componente aggiuntivo di Excel da packages.config a PackageReference. Sembra essere correlato a questo problema .

Quanto segue funziona come soluzione approssimativa se non si utilizza ClickOnce (ometterà tutte le informazioni sulla dipendenza dal .manifestfile):

1. Scarica il progetto, modifica .csproj

2. Trova la sezione simile a questa:

   <!-- Include additional build rules for an Office application add-in. -->
   <Import Project="$(VSToolsPath)\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets" Condition="'$(VSToolsPath)' != ''" />

3. Modifica una copia rinominata del .targetsfile di riferimento (nel mio caso, il file si è risolto C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targetse ho fatto una copia Microsoft.VisualStudio.Tools.Office_FIX.targetsnella stessa cartella - non ho verificato se funziona da una cartella diversa).

4. Trova l' GenerateApplicationManifestelemento e cambiare il suo attributo Dependencies="@(DependenciesForGam)"a Dependencies="".

5. Cambia invece la sezione trovata in 2. per fare riferimento al tuo .targetsfile modificato .

Questo dovrà essere ripetuto ogni volta che la versione del .targetsfile spedita con VS viene aggiornata (o non otterrai gli aggiornamenti), ma spero che verrà risolto presto ...

L'assemblea è firmata correttamente?

Per verificare ciò, premi Alt + Invio sul progetto (o fai clic con il pulsante destro, quindi Proprietà). Vai a "Firma". Verificare che la casella di controllo "Firma l'assembly" sia selezionata e che sia selezionato il file della chiave con nome sicuro e che "Ritardare solo il segno" sia deselezionato .

Ora Ecco un approccio diverso al problema:

• Fare clic con il tasto destro del mouse sul progetto e selezionare l'opzione "Scarica progetto". Noterai che il tuo progetto non sarà disponibile.

• Fare clic con il tasto destro del mouse sul progetto non disponibile e selezionare l'opzione "Modifica".

• Scorri verso il basso fino al tag '<ItemGroup>' che contiene tutti i tag delle risorse.

• Ora vai al riferimento che è stato visualizzato nell'elenco degli errori, noterai che utilizza un singolo tag (cioè < Reference Include="assemble_name_here, Version=0.0.0.0, Culture=neutral" / >).

• Cambia quello per apparire come segue:

.

<Reference Include="assemble_name_here, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL" >
    < Private > True < / Private >
    < HintPath > path_here\assemble_name_here.dll < / HintPath >
< / Reference >

• Salva le modifiche, fai nuovamente clic con il pulsante destro del mouse sul progetto non disponibile e fai clic sull'opzione "Ricarica progetto", quindi crea.

Ciò è causato quando si modifica la versione della DLL a cui viene fatto riferimento. È necessario eliminare tutti gli elementi o il DLL nella cartella di build di destinazione.

Ho avuto l'errore del compilatore simile. Una volta aggiunto il progetto dipendente del file dll alla soluzione, il problema è stato risolto.

Se il tuo progetto principale utilizza alcuni progetti di libreria e fa riferimento ad essi, puoi causare questo problema se il tuo progetto fa riferimento a un file dll di assembly anziché a progetto di libreria quando cambi qualcosa nel progetto di libreria (es: rinomina una classe).

Puoi controllare tutti i riferimenti al tuo progetto principale visualizzando nella finestra Browser oggetti (menu Visualizza-> Browser oggetti). Un riferimento a un file dll ha sempre un numero di versione. Esempio: TestLib [1.0.0.0]

Soluzione: eliminare il riferimento corrente del progetto principale al progetto della biblioteca e aggiungere nuovamente il riferimento a quel progetto della biblioteca.

Dopo aver provato la maggior parte delle soluzioni qui, ho appena aggiunto un riferimento al progetto dal progetto click once, questo lo ha cambiato in Include (Auto) da Include e alla fine ha funzionato.

Ciò che mi ha aiutato è stato andare alla soluzione Package Manager e ho esaminato il pacchetto installato che stava causando il problema. Ho visto che diversi progetti facevano riferimento allo stesso pacchetto ma a versioni diverse. Li ho allineati in base alle mie esigenze e ha funzionato.

Ho avuto questo in una soluzione con 6 progetti. Uno dei miei progetti si riferiva all'assembly nominato come riferimento a un file. Gli altri puntavano tutti al riferimento del progetto.

Di solito ricevo un errore diverso in questi casi.

La mia soluzione era quella di eliminare l'assembly nominato ovunque fosse referenziato e aggiungerlo nuovamente. Una volta elaborato il progetto, il problema è scomparso. Prima di farlo, ho provato a pulire la soluzione e ad assicurarmi che nessuno dei progetti fosse firmato.

spero che aiuti qualcuno ...

Se si tratta di una mancata corrispondenza delle dipendenze delle dipendenze, andare al gestore dei pacchetti NuGet a livello di soluzione e controllare le schede Aggiorna e Consolida, armonizzare tutto.

Di recente ho riscontrato questo problema. Nel mio caso, ho pacchetti NuGet su diversi assembly. Ciò che avevo erano versioni diverse degli stessi pacchetti NuGet associati ai miei assiemi.
La mia soluzione era quella di utilizzare il gestore di pacchetti NuGet sulla Soluzione, al contrario dei singoli progetti. Ciò consente un'opzione di "consolidamento", in cui è possibile aggiornare i pacchetti NuGet su tutti i progetti desiderati, in modo che facciano tutti riferimento alla stessa versione dell'assembly. Quando ho eseguito i consolidamenti, l'errore di compilazione è scomparso.

Mi imbatto anche in un tipo di problema, tutto quello che dovevo fare è eliminare il .dll (che si trova nel riferimento) che causa l'errore e aggiungerlo di nuovo .

Funziona come un fascino.

Prova con update-package -reinstall -ignoredependencies

Basta andare su Pubblica -> File dell'applicazione -> E cambia lo stato di pubblicazione della dll effettuata dal prerequisito da includere! Questo ha funzionato per me!