2010-05-25 3 views
13

Ho un progetto nella mia soluzione che è iniziato come progetto di libreria C#. Non ha nulla di interessante in termini di codice, è semplicemente usato come dipendenza dagli altri progetti nella mia soluzione per garantire che sia stato costruito per primo. Uno degli effetti collaterali della creazione di questo progetto è che viene creato un AssemblyInfo.cs condiviso che contiene il numero di versione utilizzato dagli altri progetti.Come impedire che i file MSBuild esterni vengano memorizzati nella cache (da Visual Studio) durante la creazione di un progetto?

ho fatto questo aggiungendo quanto segue al file Csproj:

<ItemGroup> 
    <None Include="Properties\AssemblyInfo.Shared.cs.in" /> 
    <Compile Include="Properties\AssemblyInfo.Shared.cs" /> 
    <None Include="VersionInfo.targets" /> 
</ItemGroup> 
<Import Project="$(ProjectDir)VersionInfo.targets" /> 
<Target Name="BeforeBuild" DependsOnTargets="UpdateSharedAssemblyInfo" /> 

Il file indicato, VersionInfo.targets, contiene quanto segue:

<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> 
    <PropertyGroup> 
    <!-- 
     Some properties defining tool locations and the name of the 
     AssemblyInfo.Shared.cs.in file etc. 
    --> 
    </PropertyGroup> 
    <Target Name="UpdateSharedAssemblyInfo"> 
    <!-- 
     Uses the Exec task to run one of the tools to generate 
     AssemblyInfo.Shared.cs based on the location of AssemblyInfo.Shared.cs.in 
     and some of the other properties. 
    --> 
    </Target> 
</Project> 

Il contenuto del VersionInfo. il file target potrebbe semplicemente essere incorporato nel file .csproj ma è esterno perché sto cercando di trasformare tutto questo in un modello di progetto. Voglio che gli utenti del modello siano in grado di aggiungere il nuovo progetto alla soluzione, modificare il file VersionInfo.targets ed eseguire la build.

Il problema è che la modifica e il salvataggio del file VersionInfo.targets e la ricostruzione della soluzione non hanno alcun effetto: il file di progetto utilizza i valori del file .targets così come erano quando il progetto è stato aperto. Anche lo scarico e il ricaricamento del progetto non hanno alcun effetto. Per ottenere i nuovi valori, ho bisogno di chiudere Visual Studio e riaprirlo (o ricaricare la soluzione).

Come posso configurarlo in modo che la configurazione sia esterna al file .csproj e non memorizzata nella cache tra le build?

+0

possibile duplicato di [Come disattivare la memorizzazione nella cache delle definizioni di build in Visual Studio] (http://stackoverflow.com/questions/4919204/how-to-turn-off-caching-of-build-definitions-in- visual-studio) – yoyo

+0

un altro possibile duplicato: http://stackoverflow.com/questions/2012742/how-to-stop-visual-studio-caching-imported-msbuild-scripts –

risposta

3

Per quanto ne so, non è possibile. Visual Studio non usa "reale" MSBuild, utilizza un motore di compilazione interno che si comporta in modo molto simile a MSBuild.exe, ma presenta comunque alcune sottili differenze. Questo motore di compilazione memorizza nella cache gli obiettivi, quindi è necessario riavviare VS una volta cambiato qualcosa. Credo che sia persino documentato da qualche parte, e non c'è alcuna soluzione nota (l'ho cercata circa un anno fa e non ho trovato nulla).

È possibile forzare il VS a ricaricare gli obiettivi tramite VS API, quindi sarà necessario creare (o trovare) un componente aggiuntivo personalizzato per farlo.

Un'altra opzione è utilizzare qualcosa di diverso dal file .targets per memorizzare la configurazione. Ad esempio, è possibile utilizzare un file di testo normale e analizzarlo con MSBuild (non così elegante, ma dovrebbe funzionare).

Aggiornamento.

Questo è quello che ho fatto qualche tempo fa. MSBuild chiama uno strumento esterno tramite Exec con WorkingDirectory = "$ (SolutionDir)", lo strumento "conosce" tutte le convenzioni su nomi di file, posizioni ecc., Quindi una directory di lavoro è sufficiente per portare a termine il lavoro. I dati di configurazione vari sono memorizzati nella configurazione dello strumento esterno, quindi nessun problema con la memorizzazione nella cache.

Inoltre, dare un'occhiata a this question sulla lettura di elementi da un file. Suppongo che migliori le tue esigenze.

+0

Grazie, @VladV. L'opzione di configurazione esterna sembra una possibilità. Sono un principiante MSBuild completo, potresti consigliare del materiale di riferimento per leggere le proprietà da file esterni? –

+0

Riferimento MSBuild a MSDN: http://msdn.microsoft.com/en-us/library/0k6kkbsd.aspx. Attività della community di MSBuild (alcune estensioni utili per MSBuild): http://msbuildtasks.tigris.org/. – VladV

+0

Ho implementato un tipo di resolver di risoluzione per MSBuild e ha usato qualche configurazione esterna, ma non ho il codice in mano al momento. Cercherò di trovare alcuni esempi per te in poche ore. – VladV

2

Ho avuto un successo intermittente modificando il file di progetto incluso il file msbuild personalizzato e rendendolo invalido, quindi ricaricando il progetto, lasciandolo scaricato, quindi correggendo il file di progetto e ricaricandolo.

A volte funziona, a volte no, ma è meglio che riavviare Visual Studio.

+0

Il seguente trucco sembra funzionare: rimuovere il progetto dalla soluzione (progetto con il tasto destro del mouse, "Rimuovi"). Quindi aggiungilo di nuovo (soluzione con il tasto destro del mouse, "Aggiungi" - "Progetto esistente ...", vai al file csproj). –

1

Se è necessario un modo rapido e sporco per risolverlo, è sufficiente ricaricare la soluzione (tramite https://stackoverflow.com/a/6877056/182371).

È possibile farlo chiudendo-aprendo il file della soluzione o premendo Salva in un editor esterno (quindi quando si ritorna a VS, verrà visualizzato se si desidera ricaricare).

+0

La cache può sopravvivere alla ricarica (dopo che il file '.sln' è stato aggiornato sul disco), quindi anche dopo la ricarica, il problema persiste. –