2012-03-06 11 views
5

Sto installando un progetto di installazione di una soluzione C# e ho incontrato un problema di dipendenza:VS 2010 Progetto di installazione non portando assembly referenziati condivisi per tutte le uscite

Nella mia soluzione, ho 4 uscite di progetto indipendenti - uno finestre servizio e tre file eseguibili, che condividono tutti tra loro alcuni riferimenti.

Ho bisogno del programma di installazione per installarli tutti e quattro in modo che la soluzione funzioni.

Ho impostato una cartella di installazione per ciascun output di progetto in "Cartella dell'applicazione" nella finestra di dialogo "File system sulla macchina di destinazione", aggiunto correttamente l'output del progetto del servizio Windows nella sua cartella. Ma quando continuo a provare ad aggiungere gli output dei progetti degli eseguibili nelle loro cartelle, gli assembly già trasportati nella cartella del servizio Windows non vengono portati nella cartella eseguibile e, dopo l'installazione, gli eseguibili non verranno eseguiti in quanto mancano delle dipendenze.

Posso aggiungere manualmente gli assembly mancanti alle cartelle degli eseguibili, ma sembra che questo non è come dovrebbe essere fatto e c'è qualcosa che mi manca.

Qualche idea?

risposta

1

Bene, dovresti creare un nuovo progetto nella soluzione e impostare il "programma di installazione" come output della tua applicazione principale (o delle applicazioni principali) che dovrebbe risolvere le dipendenze stesse.

+0

Mi dispiace, ma non ho capito nulla di quanto sopra. Quale nuovo progetto dovrei creare nella soluzione e per quale scopo? cosa intendi impostando l'installer come output delle applicazioni principali? per favore prova ad elaborare. Grazie. – Eliaz

+0

Sì, l'installazione dovrebbe avere l'output impostato su qualsiasi applicazione che si desidera distribuire. I riferimenti dovrebbero essere risolti da soli e nelle proprietà, dovresti essere in grado di definire in che modo vengono distribuiti gli assembly. Ma non sono davvero sicuro se stiamo parlando della stessa cosa. – squelos

1

Avevo quello che penso sia il problema originariamente descritto. Ho un'applicazione Winform e un'applicazione console come due progetti separati, ma un singolo progetto di installazione gestisce entrambi.

Sia l'app Winform che l'app della console utilizzano gli stessi due assembly esterni: uno non fa parte della soluzione (riferimento a un file in una cartella) e l'altro da un progetto di classe C# (riferimento al progetto).

Quello che ho trovato è che l'installatore presume che l'output del progetto sia tutto combinato in una singola cartella sulla macchina di installazione. Pertanto, tutti gli assembly comuni avranno anche la coincidenza con gli eseguibili che ne hanno bisogno. Quindi se si aggiunge l'output del progetto dal primo eseguibile nella cartella, è per questo che vengono visualizzate tutte le sue dipendenze, quindi quando viene aggiunto il secondo output del progetto, verranno visualizzati solo gli assembly non ancora aggiunti.

Non importa se si creano sottocartelle nella cartella Applicazione, Visual Studio sembra trattare la cartella dell'applicazione come un'unità intera ... per quanto riguarda l'output del progetto (exe, dll e res).

Ci sono due modi per risolvere questo. Il primo è creare un progetto di installazione separato per ogni eseguibile. In un grande progetto, questo potrebbe essere un sacco di progetti di installazione.

Se si vuole tenere tutto in una singola installazione, una soluzione migliore è quella di utilizzare il GAC per le assemblee condivisi, che è descritto in un altro articolo Stack Overflow qui: Use Visual Studio Setup Project to automatically register and GAC a COM Interop DLL

MSI può ottenere il lavoro fatto. Fare clic con il tasto destro del mouse su "File System su Target Machine", Aggiungi, GAC. Fare clic con il tasto destro su quella cartella aggiunta, Aggiungi, Uscita progetto. Che assicura che l'assembly sia gac-ed.

Il GAC è la soluzione migliore nella mia mente, perché gli assembly sono gestiti dal livello .NET se in seguito apportate modifiche e miglioramenti. Uno dei vantaggi diNET è quello di eliminare i vecchi problemi "DLL inferno" che erano in Win 98 e versioni precedenti di Windows. Consiglio vivamente di usarlo per il codice comune.

Problemi correlati