2009-07-22 6 views
17

La mia soluzione di Visual Studio include un'applicazione Web e un'applicazione di test di unità. La mia applicazione web utilizza log4net. Voglio essere in grado di usare msbuild dalla riga di comando per costruire la mia soluzione. Tuttavia, ogni volta che costruisco la soluzione dalla riga di comando, ottengo errori di compilazione perché non è in grado di copiare log4net.xml nella directory bin del progetto di test.Come impedire a Visual Studio di bloccare i file di documentazione xml nella directory bin?

Il messaggio di errore è:.

"Impossibile copiare il file '\ bin \ log4net.xml' a 'bin \ Debug \ log4net.xml' Accesso al percorso '\ bin \ log4net.xml ' è negato."

Sembra che Visual Studio stia bloccando questo file, ma non riesco a capire perché dovrebbe essere necessario. C'è un modo per impedire a VS di bloccare i file di documentazione XML in un progetto che ha caricato?

risposta

1

Ho avuto questo problema con Visual Studio, anche. Usiamo NAnt invece di MSBuild, ma il problema è lo stesso. Sono stato in grado di aggirarlo modificando il file di build per ignorare i fallimenti durante la copia della documentazione xml.

Si noti che questo in realtà non risolve il problema originale poiché i file xml sono ancora bloccati, ma questa soluzione è stata abbastanza buona per noi dal momento che il contenuto effettivo della nostra documentazione xml non cambia molto spesso.

0

Fondamentalmente non controllare i file nella cartella bin, è una cattiva idea.

È possibile rilasciare questo file in un'altra directory e farvi riferimento da lì o inserire il codice che lo utilizza in una libreria e fare in modo che l'evento di post build venga copiato nella sua directory bin e quindi fare riferimento.

MSBuild sarà quindi copiare che nella directory bin webprojects per voi :)

abbiamo questo problema esatto con la gente il check-in roba alla directory bin, a meno che non dovete assolutamente directory bin dovrebbe o non essere controllato in del tutto o semplicemente avere file .refresh lì per evitare questo tipo di problemi di blocco.

Bit ritardo sulla risposta, mi spiace :)

+0

La domanda iniziale non ha indicato che qualsiasi i file sono stati controllati nella directory bin, solo che sono stati copiati lì durante la compilazione. Detto questo, sono d'accordo sul fatto che, in generale, i file non dovrebbero essere controllati nella directory bin di un progetto. –

+0

Ahh mi dispiace per quello, l'ho riletto e hai ragione :) Ho comunque trovato molto scomodo che non si riesca a utilizzare eventi post e pre compilazione su questi tipi di progetti, alla fine ho finito per risolvere il problema avendo una directory delle dipendenze e msbuild copia sempre l'assembly correttamente. –

1

Krystan ha scritto:

potrebbe cadere questo file in un'altra directory e fare riferimento da lì o il codice posto che lo utilizza in una libreria e avere il post evento costruire su quel copiarlo sua directory bin e quindi riferimento.

Il nostro problema di blocco del file xml non è presente nella directory bin dei progetti, piuttosto è una directory di riferimento esterna. L'abbiamo colpito durante l'esecuzione di TortoiseSVN-> Update in cui è disponibile una nuova versione. Supponendo che VS stia usando il file per intellisense.

Per coloro che hanno riscontrato questo problema di blocco a causa di TortoiseSVN-> Aggiornamento, sto attualmente sperimentando un hook pre-aggiornamento che elimina i file offensivi prima dell'aggiornamento (verranno ripristinati se non è necessario alcun aggiornamento) , finora sembra funzionare (il che è strano) ma non l'ho testato abbastanza a fondo da poterlo dire con certezza. Aggiornerà questa risposta se si dimostra affidabile.

Ecco sperando che MS lo risolva in VS 2010.

+0

Sto affrontando lo stesso problema. Il tuo workaround funziona bene ma è strano che TSVN acn cancelli il file, ma non lo sovrascriva!? –

8

ho trovato la seguente soluzione: In VS evento postbuild o nello script NAnt/MSBuild eseguire lo script cmd

handle.exe -p devenv [Path to the folder with locked files] > handles.txt 

FOR /F "skip=5 tokens=3,4 delims=: " %%i IN (handles.txt) DO handle -p %%i -c %%j -y 

handle.exe è disponibile qui http://technet.microsoft.com/en-us/sysinternals/bb896655.aspx

prima riga dello script dump to handles.txt tutte le maniglie per i file bloccati da VS letture di seconda riga gestiscono gli ID dal file e uccide i punti di manipolazione

Dopo che lo script è stato eseguito i file possono essere rem oved/sostituito/spostato ecc.

+0

risposta eccellente. funziona come un incantesimo, e mi permette di scrivere i miei script di compilazione come se si stesse comportando con Visual Studio invece di scrivere i miei script di compilazione su un VS scorretto. – Adam

+1

Sto usando l'handle 3.46 e ho dovuto cambiare 'token = 3,4' a' token = 3,6'. Dopo di ciò ha funzionato perfettamente grazie. – OlduwanSteve

2

Se stai bene omettendo i file xml & pdb dall'output, puoi passare /p:AllowedReferenceRelatedFileExtensions=none a msbuild sulla riga di comando.

(Grazie alla risposta relativa https://stackoverflow.com/a/8757941/251011)

EDIT: Se si hanno anche problemi con i file dll avere questo errore, ho recentemente scoperto una soluzione variabile d'ambiente: https://stackoverflow.com/a/23069603/251011

+1

Inoltre: è un po 'divertente che dopo quasi cinque anni VS continui a serrare come questo e ancora non sappiamo * perché *. –