2015-08-12 10 views
27

Queste DLL non vengono aggiunte al mio progetto nelle versioni precedenti di Visual Studio. La mia ipotesi è che uno dei miei riferimenti abbia una dipendenza da queste DLL. Da quello che ho letto, lo Microsoft.Office.Interop.Excel evidenziato potrebbe essere quello. Qualcuno può confermarlo? Dovrei anche notare che VS 2015 pubblica sempre queste DLL anche se le escludo dal progetto. Se li cancello, VS 2015 li rifarà.Perché Visual Studio 2015 aggiunge stdole.dll e Microsoft.AnalysisServices.AdomdClient.dll al mio progetto?

Modifica: Ho confermato che i riferimenti Excel e Office sono ciò che sta causando l'inclusione di stdole.dll. Visualizza la risposta selezionata per rimuovere stdole.dll.

Ho barrato i riferimenti personalizzati. Fammi sapere se sono necessarie ulteriori informazioni. Ecco i miei riferimenti attuali:

enter image description here

enter image description here

+5

Che ne dici? Il mio primo downvote. Un downvote senza feedback è altamente improduttivo. –

+1

Sono interessato a questa domanda, perché stdole.dll viene visualizzato su tutte le app che faccio. Pubblico con click-once e sta causando problemi con Visual Studio 2015. Potrebbe non essere correlato a questa domanda, ma altre persone potrebbero trovare questa domanda alla ricerca di quella DLL. Questo altro ragazzo lo ha sostituito con una copia firmata nel suo: https://iznum.wordpress.com/2013/04/22/strong-name-signature-not-valid-for-this-assembly-stdole-dll/ – 249076

+1

Un altro ragazzo ha postato un bug su questo: https://connect.microsoft.com/VisualStudio/feedback/details/1658072/could-not-load-assembly-file-stdole-dll-that-were-not-actually-using – 249076

risposta

12

Se si ha la possibilità, utilizzare i tipi di incorporare interoperabilità e lasciare stdole.dll fuori di esso tutti insieme o si andrà in contro il problema ogni volta che si sposta l'applicazione (nuovi server o macchine di sviluppo) in cui stdole.dll non è firmato.

Problema: C'è un riferimento che richiede stdole.dll e stdole.dll viene ora automaticamente spostato nella cartella bin.

Soluzione:

  • Trovare il che richiede stdole.dll di riferimento (più su come fare questo qui sotto)
  • Vai alla sua proprietà (click destro-> proprietà)
  • Change "Incorpora Tipi di interoperabilità "da falso a vero.

Come trovare il riferimento: Quando si fa clic sulle proprietà dei vostri riferimenti, controllare per vedere se "Tipi Embed di interoperabilità" è impostato su false. Per scavare ancora, lo Nick's answer ha delle ottime informazioni.

riferimenti che ho confermato finora che utilizzano stdole.dll (probabilmente più programmi di Office pure)

  • ufficio

  • Excel

  • core

  • Crystal Reports (Grazie al litio. Come sottolinea Nick, non si può e il vantaggio di impostazione Embed Interop Types=true)

Se si trova più, aggiungerli a questa lista o notare nei commenti e lo farò.

Hans Passantsconsiglia vivamente impostazione Embed Interop Types=false qui: What's the difference setting Embed Interop Types true and false in Visual Studio?

Scott Hanselman parla anche di ciò che i "Tipi Embed di interoperabilità" non qui: http://www.hanselman.com/blog/CLRAndDLRAndBCLOhMyWhirlwindTourAroundNET4AndVisualStudio2010Beta1.aspx

+2

Ciao, grazie per la risposta. È possibile aggiungere dll di Crystal Reports all'elenco di riferimenti che utilizzano stdole.dll – Lithium

2

Nella mia situazione ho scoperto che si attiva la proprietà Copia localmente su l'assembly che dipende da stdole.dll, salvando il progetto e quindi riportando la proprietà al suo valore originale e, infine, il salvataggio del progetto ha risolto il problema. Questa proprietà potrebbe anche essere correlata alla proprietà Tipi di interpazio incorporati per altre persone con questo problema.

Ciò che fa è salvare esplicitamente la proprietà Copia locale nel file .xxproj. In caso contrario, lo stato di questa proprietà non è nel file di progetto e viene assunto un valore predefinito. Non ho alcuna spiegazione del motivo per cui questo funziona in quanto la presenza della proprietà nel file di progetto non modifica il valore visualizzato in Visual Studio né provoca una modifica dell'assembly effettivamente pubblicato o meno. Inoltre, non ho causato alcun cambiamento in queste proprietà rispetto ai valori visualizzati originariamente dopo averli alternati avanti e indietro.

Io noto che anche prima di aver trovato la cura ho visto che la pulizia del progetto e la sua ricostruzione non causavano la copia di stdole.dll in bin. È stato solo dopo la pubblicazione che è apparso stdole.dll.

+0

Buone informazioni. Ora mi chiedi se ho rimosso un riferimento che era impostato su "Copia locale" e il riferimento che ho aggiunto non lo era. –

+0

Il tuo istinto era corretto in "Incorpora tipi di interoperabilità". Ho trovato il problema e aggiornato la mia risposta. –

8

Ho avuto a che fare con questo problema da anni.

Ogni volta che installo qualcosa dalla piattaforma web o qualsiasi aggiornamento lo stdole.dll viene sostituito con una versione non firmata. Ho segnalato il bug a Microsoft qualche tempo fa ma sono caduto nel vuoto.

Vado a C: \ Programmi (x86) \ Microsoft.NET \ Primary Interop Assembly e copia la versione firmata (22kb) da qui e sostituisce la versione in C: \ Programmi (x86) \ Microsoft Visual Studio 14.0 \ Visual Studio Tools per Office \ PIA \ Common (16kb) e questo risolve il problema.

Scott

+0

Scott, ho trovato un modo per farlo senza più fare lo stdole.dll. Ho appena aggiornato la mia risposta. Ti ho ancora votato perché mi hai dato un'altra soluzione. –

18

Come altri hanno indicato, stdole.dll è un assembly di interoperabilità primario per un gruppo di componenti di interoperabilità COM di Office. Puoi determinare il motivo per cui viene incluso nel tuo progetto facendo quanto segue.

In Visual Studio, passare a Tools > Options > Projects and Solutions > Build and Run. Modifica l'impostazione "Produttività output del progetto MSBuild" su Detailed. Ora pulisci e ricostruisci il tuo progetto.

Aprire la finestra di output e cercare stdole. Si dovrebbe trovare una sezione come questa:

25> Dependency "stdole, Version=7.0.3300.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a". 
25>  Resolved file path is "D:\Program Files (x86)\Microsoft Visual Studio 12.0\Visual Studio Tools for Office\PIA\Common\stdole.dll". 
25>  Reference found at search path location "{Registry:Software\Microsoft\.NETFramework,v4.0,AssemblyFoldersEx}". 
25>   For SearchPath "D:\Git\FoobarServices\Dependencies\Dependencies". 
25>   Considered "D:\Git\FoobarServices\Dependencies\stdole.winmd", but it didn't exist. 
25>   Considered "D:\Git\FoobarServices\Dependencies\stdole.dll", but it didn't exist. 
25>   Considered "D:\Git\FoobarServices\Dependencies\stdole.exe", but it didn't exist. 
25>   For SearchPath "{CandidateAssemblyFiles}". 
25>   Considered "Dependencies\CrystalDecisions.CrystalReports.Engine.dll", but its name "CrystalDecisions.CrystalReports.Engine" didn't match. 
25>   Considered "Dependencies\CrystalDecisions.Enterprise.Framework.dll", but its name "CrystalDecisions.Enterprise.Framework" didn't match. 
25>   Considered "Dependencies\CrystalDecisions.Enterprise.InfoStore.dll", but its name "CrystalDecisions.Enterprise.InfoStore" didn't match. 
25>   Considered "Dependencies\CrystalDecisions.ReportSource.dll", but its name "CrystalDecisions.ReportSource" didn't match. 
25>   Considered "Dependencies\CrystalDecisions.Shared.dll", but its name "CrystalDecisions.Shared" didn't match. 
25>   Considered "Dependencies\CrystalDecisions.Web.dll", but its name "CrystalDecisions.Web" didn't match. 
25>   For SearchPath "{TargetFrameworkDirectory}". 
25>   Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\stdole.winmd", but it didn't exist. 
25>   Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\stdole.dll", but it didn't exist. 
25>   Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\stdole.exe", but it didn't exist. 
25>   For SearchPath "{Registry:Software\Microsoft\.NETFramework,v4.0,AssemblyFoldersEx}". 
25>   Considered AssemblyFoldersEx locations. 
25>  Required by "CrystalDecisions.Web, Version=11.5.3700.0, Culture=neutral, PublicKeyToken=692fbea5521e1304, processorArchitecture=MSIL". 
25>  Required by "CrystalDecisions.ReportSource, Version=11.5.3700.0, Culture=neutral, PublicKeyToken=692fbea5521e1304, processorArchitecture=MSIL". 
25>  Required by "CrystalDecisions.CrystalReports.Engine, Version=11.5.3700.0, Culture=neutral, PublicKeyToken=692fbea5521e1304, processorArchitecture=MSIL". 
25>  Required by "CrystalDecisions.Enterprise.InfoStore, Version=11.5.3300.0, Culture=neutral, PublicKeyToken=692fbea5521e1304". 
25>  The ImageRuntimeVersion for this reference is "v1.0.3705". 

Potete vedere dove Visual Studio cercato per l'assemblaggio e ciò richiede in fondo. Nel mio caso si tratta di un gruppo di vecchi assembly Crystal Reports.

A volte è possibile incorporare i tipi di interoperabilità tramite le dipendenze come suggerisce Tony, ma non sempre. Per me, gli assembly Crystal Reports non supportano questo.

Ho risolto questo problema (e l'insidioso uno scottsanpedro menzionato) copiando lo stdole.dll (32 KB, firmato digitalmente) da C:\Program Files (x86)\Microsoft.NET\Primary Interop Assemblies\ in una cartella "Dipendenze" all'interno del mio progetto. Ho aggiunto il file al mio progetto e aggiunto un riferimento esplicito ad esso (Aggiungi riferimento> Sfoglia).Finalmente ho aperto le nuove proprietà del riferimento e impostato Embed Interop Types a True.

Questa sembra essere una situazione migliore. Non dovrei aver bisogno di preoccuparmi di ottenere una versione senza firma dell'assembly.

+0

Buone informazioni, Nick. Riferirò alla tua risposta nella mia risposta su come individuare le classi che si riferiscono alla dll. –

+0

Se si imposta 'Incorpora tipi di interoperabilità' su' Vero', è ancora necessario stdole.dll? La mia app non ne ha più bisogno. –

Problemi correlati