2010-02-23 8 views
8

Ho un progetto Sitecore/ASP.NET che sto sviluppando. Oggi ad un certo punto ho inavvertitamente premuto l'opzione "Pulisci" nel menu contestuale della soluzione. Mi ci è voluto un po 'per capire perché il mio sito era irrimediabilmente rotto. Si scopre che Visual Studio è andato avanti e ha eliminato diversi assembly richiesti dalla directory \ bin che non fanno parte del mio progetto.Come impedire al comando "Pulisci" di Visual Studio 2005 di rimuovere i file binari di terze parti?

Come posso evitare che ciò accada di nuovo?

La cosa strana è che NON ha eliminato tutto ... solo una piccola manciata. Ne sono rimasti molti che non sono referenziati direttamente dal mio progetto. Questo mi fa chiedere esattamente che cosa dovrebbe fare questa funzione? C'è una sorta di flag di file che posso impostare? Nessuno dei file è impostato in sola lettura. Se siete interessati ai dettagli, di seguito ha ottenuto cancellato:

Sitecore.Analytics.dll
Sitecore.Client.XML
Stimulsoft.Base.dll
Stimulsoft.Report.dll
Stimulsoft.Report.Web .dll
Stimulsoft.Report.WebDesign.dll
Telerik.Web.UI.dll

AGGIORNAMENTO: sai cosa ... Credo che quello che sono veramente più interessato a qui è WH Y Visual Studio lascia la maggior parte dei file e cancella solo quelli specifici.

+0

Non sta eliminando tutto nella cartella bin? –

+0

Non lo è assolutamente. La maggior parte dei binari Sitecore (posizionati dall'installatore) rimangono intatti. – Bryan

+0

Dei file eliminati, sono tutti o output di progetti o referenziati come dipendenza del progetto? –

risposta

8

La risposta corretta al problema dipenderà dal modo in cui si fa riferimento agli assembly e da come li si include nell'output del progetto.

Le cartelle bin e obj generate da un progetto vengono considerate come cartelle di "output"; queste cartelle dovrebbero contenere solo file prodotti dalla build del progetto.

Quando si esegue una pulizia o una ricostruzione di un progetto, tutti i file intermedi e compilati vengono eliminati da queste cartelle.

Si dovrebbe essere a proprio agio questo sta accadendo.

Si dovrebbe essere in grado di ripristinare queste cartelle eseguendo il processo di compilazione in qualsiasi momento. Se hai aggiunto direttamente dei file a queste cartelle, questo rompe lo scopo di queste cartelle e significa che dovresti ripensare a come stai aggiungendo quei file.

Il modo migliore per fare riferimento agli assembly compilati è aggiungerli da qualche parte all'interno delle cartelle di origine. Da lì, possono essere aggiunti a un sistema di controllo del codice sorgente facilmente come qualsiasi altro file e possono essere referenziati/copiati da progetti che dipendono da essi. Nel mio lavoro, abbiamo una cartella "Librerie" che contiene numerosi gruppi di terze parti a cui fanno riferimento più progetti nella nostra gerarchia di soluzioni.

provare a utilizzare un albero di origine come questo e vedere se funziona per voi:

  • /Progetti/La mia soluzione/
  • /Progetti/La mia soluzione/biblioteche/
  • /Progetti/La mia soluzione/progetto a/
  • /Progetti/la mia soluzione/progetto B/
+0

Eroe ... la tua risposta ha un senso in superficie ... almeno, forse è come si comporta Visual Studio *. Ma chiaramente non lo è, dato che clean/rebuild lascia molte altre DLL nella directory bin che non sono costruite o referenziate dal mio progetto. Il mio progetto è impostato come consigliato da Sitecore. – Bryan

+0

Se elimini manualmente la directory 'bin' ed esegui una ricostruzione, qual è il risultato? –

+0

Disastro. Sitecore raccomanda che la radice del progetto sia la radice del sito Web ... dove ha installato molte DLL nella directory \ bin. L'eliminazione della directory bin rimuoverebbe tutte queste e distruggerebbe la tua app web. – Bryan

1

Credo che se si inseriscono questi file in una sottodirectory diversa da bin, Visual Studio non li rimuoverà. È ancora possibile creare la nuova subdirectory parte della distribuzione.

5

Inserire le DLL in una directory diversa. Probabilmente non li vorresti come parte del progetto. Fai riferimento alle DLL dalla nuova directory. Quando si compila, le dll verranno copiate nella directory bin.

Io lavoro con un sacco di progetti e mantenere una directory bin alla radice dei miei progetti per memorizzare DLL di terze parti esattamente per questo motivo.

Esempio struttura di directory:

 
MyProjects 
- bin 
    - 3rdParty.dll 
- Project1 
- Project2 
- ProjectN 

Ciò consente a tutti i progetti di avere una posizione di riferimento ben noto per la 3a DLL parti senza dover copiare la DLL in ogni progetto.

Se lavori su una squadra, dovresti essere d'accordo su una struttura di directory standard per il tuo codice. Questo ti farà risparmiare molti mal di testa oltre questo.

+0

Sì, funzionerebbe benissimo se queste DLL fossero effettivamente referenziate dal mio progetto e non stavo lavorando su un'applicazione ASP.NET. – Bryan

4

In caso di Sitecore, assicurati di impostare la proprietà del riferimento (Sitecore.Kernel, Sitecore.Client, ecc.): 'Copia locale' = falso.

+0

Questo buon signore è la vostra risposta, i documenti Sitecore e la formazione lo chiamano. – techphoria414

5

aggiungiamo sempre un evento AfterBuild al file di progetto contenente Sitecore.

<Target Name="AfterBuild"> 
    <CreateItem Include="$(SolutionDir)\Third Party\Sitecore\*.*"> 
     <Output TaskParameter="Include" ItemName="FilesToArchive" /> 
    </CreateItem> 
    <Copy SourceFiles="@(FilesToArchive)" DestinationFolder="$(TargetDir)\%(FilesToArchive.RecursiveDir)" /> 
    </Target> 

Dove CreateItem Include è il percorso in cui sono stati posizionati i file binari di Sitecore.

+0

+1 Per l'uso prudente di msbuild. Potresti voler aggiungere qualche dettaglio su dove mettere questo pezzo di configurazione però :) –

0

Bene, ho intenzione di andare avanti e rispondere alla mia stessa domanda, poiché sembra la risposta più semplice finora. Ho contrassegnato gli assembly in questione come di sola lettura. Ora non vengono puliti.

Ancora chiedersi perché la maggior parte degli altri non viene eliminata.