Impostare “copia locale” per false per impostazione predefinita?

Question

È possibile impostare il default-possibilità di "copia locale" in Visual Studio su False? Nella maggior parte delle volte, quando aggiungo una DLL come la dipendenza di un progetto, voglio che la proprietà insieme Copia localmente su False. Per impostazione predefinita, è vero. C'è un modo per cambiare il comportamento predefinito di Visual Studio? (2008)

Answer 1

No -. Visual Studio utilizza un set di regole interne per determinare quali impostare copia locale per

MSDN :

  

  
1. Se il riferimento è un altro progetto, chiamato un riferimento di progetto a progetto, allora il valore è true .
  
2. Se il gruppo si trova nella cache di assembly globale, il valore è false .
  
3. Come caso particolare, il valore di riferimento per la mscorlib.dll è false .
  
4. Se il gruppo si trova nella cartella Framework SDK, il valore è false .
  
5. In caso contrario, il valore è true .
  

Answer 2

In realtà, è possibile. Avete bisogno di un paio di cose:

1. Crea file di .targets che rende CopyLocal (tag <Private>, per essere precisi) false per impostazione predefinita .
2. Importa il bersaglio in file .csproj. È possibile aggiungere in all'ultima riga, prima di chiudere tag </Project>, sembrerà come <Import Project="..\Build\yourtarget.targets" />.

Ora ogni progetto con questo obiettivo ha CopyLocal disabilitato per impostazione predefinita.

Lo svantaggio è che è necessario modificare il file ogni csproj, compresi quelli nuovi. È possibile aggirare il problema nuovo progetto di modificando il modello di progetto VS . Invece di Class.cs descritto in questo articolo del blog, è necessario modificare Class.vstemplate (nello stesso file zip).

Con questo approccio, c'è un altro problema - il percorso stesso. Se si utilizza hardcoded percorso relativo nel file csproj appena generati, possono essere sbagliato (a meno che non si dispone di struttura di progetto piatta).

È possibile:

• Fai VS generare corretto percorso relativo. Non so come fare e se questo è ancora possibile.
• ignorarlo e modificare il percorso manualmente per ogni nuovo csproj (a seconda del numero di nuovi progetti avete, mentre non è l'ideale, che può essere tollerabile).
• Utilizzare la variabile d'ambiente, invece di percorso relativo. In questo caso ogni sviluppatore avrà bisogno lo stesso set variabile.

Non ci deve essere migliore soluzione per questo, ma non ho trovato ancora.

Answer 3

Non utilizzare un file .targets (come suggerito nella risposta da ya23), quindi dobbiamo solo modificare il file di progetto .csproj manualmente in un editor di testo e aggiungere l'elemento <Private> al riferimento, in questo modo:

<Reference Include="[...]">
  <Private>False</Private>
  [...]
</Reference>

Il valore dell'elemento <Private> corrisponde al valore del "Copia locale" di proprietà. Per esempio, se <Private> è impostato su False, poi "copia locale" è anche falso ..

Answer 4

Urtando questo perché sembra che ci sia ora un pacchetto NuGet consente esattamente questo ...

https://nuget.org/packages/CopyLocalFalse

non hanno ancora provato, sperando solo aiuta.

Answer 5

A partire dalla msbuild v 15 è possibile copiare un singolo file denominato Directory.Build.props nella cartella principale che contiene la vostra fonte:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemDefinitionGroup>
  <Reference>
    <Private>False</Private>
  </Reference>
  <ProjectReference>
     <Private>False</Private>
  </ProjectReference>
</ItemDefinitionGroup>
</Project>

Non c'è altro da fare! Questo metodo funziona bene con Visual Studio 2017 e anche Build vNext. Che tu possa avere a chiudere Visual Studio e di aprire la soluzione ancora una volta a prendere l'effetto di file.

https: // docs .microsoft.com / en-us / VisualStudio / msbuild / customize-your-build # directorybuildprops-e-directorybuildtargets

Answer 6

Per quanto riguarda la soluzione postato da @herzbube, se si desidera disattivare "Copia locale" per tutti (o quasi) dei riferimenti nel file Csproj , non è necessario impostare <Private>False</Private> singolarmente su ogni Reference, si può semplicemente mettere il seguente direttamente nel csproj :

<ItemDefinitionGroup>
  <Reference>
    <Private>False</Private>
  </Reference>
</ItemDefinitionGroup>

Questo non influisce progetti di riferimento con <ProjectReference>, ma si può fare la stessa cosa - sia invece o, come pure - per coloro che:

<ItemDefinitionGroup>
  <ProjectReference>
    <Private>False</Private>
  </ProjectReference>
</ItemDefinitionGroup>

Se si desidera entrambe queste, è possibile unirli in un unico gruppo:

<ItemDefinitionGroup>
  <Reference>
    <Private>False</Private>
  </Reference>
  <ProjectReference>
    <Private>False</Private>
  </ProjectReference>
</ItemDefinitionGroup>

Assicurati di mettere degli scostamenti prima del primo <Reference ...> reale o <ProjectReference ...> che si desidera modificare, perché questi blocchi si applicheranno solo a quei riferimenti che appaiono sotto di loro. Poi, se ci sono alcuni che si do in realtà vuole essere copiati localmente, si può semplicemente ignorare quelli Indietro singolarmente (cioè entro il tag individuo stesso), questa volta usando True.

Per i casi più avanzati è possibile passare il sovrascrivendo schiena valore e indietro tra true e false più volte nello stesso file Csproj. Un'altra tecnica avanzata sarebbe per posizionare strategicamente alcuni dei vostri riferimenti sotto questi blocchi, e altri al di sopra, quindi quest'ultimo non saranno interessati.

Tutto questo dovrebbe rendere l'XML nel Csproj molto più pulito e più facile da leggere. Ma c'è ancora di più una buona notizia, quindi continuate a leggere ...

---

Per quanto riguarda la selezione cui i progetti dovrebbero essere essere contrassegnati <Private>False</Private> questo di solito dipendono dalla situazione specifica, ma c'è qualcosa di fondamentale tutti possono e dovrebbe do per cominciare. E 'un passo in modo semplice, semplice ed efficace e che offre così grande MSBuild i miglioramenti di affidabilità ¹ e l'accumulo di tempo aumento di velocità -. E con poco svantaggio - che ogni soluzione di grandi dimensioni che utilizza il (ovvero locale per ogni singolo progetto) C # di default posizioni di uscita devono quasi sempre eseguire questa regolazione:

  

In ogni e qualsiasi soluzione di Visual Studio che costruisce multipla C # librerie class con qualsiasi numero non banale di <ProjectReference> interdipendenze, e che culmina nella costruzione di un altro Applicazioni (cioè eseguibili):

     

  

1. Nella parte superiore della .csproj per ogni libreria di classi , inserire il blocco <ProjectReference> figura.
     MOTIVO: Non v'è alcuna necessità di dll per raccogliere qualsiasi delle librerie a cui fa riferimento in una sotto-directory del proprio, dal momento che nessun eseguibile viene sempre eseguito da quella posizione. Tali copie dilagante è inutile busywork e può essere inutilmente rallentare la build, possibilmente abbastanza drammaticamente.

  

2. D'altra parte, fare non modificare il .csproj per uno qualsiasi dei applicazioni del Soluzione .
     MOTIVO: eseguibili bisogno di avere tutte le librerie private costruite di cui hanno bisogno nei loro rispettivi sotto-directory, ma la build per ogni app da solo dovrebbe essere responsabile della raccolta singolarmente ogni dipendenza, direttamente dal suo rispettivo sub-directory, nella sub- dell'app directory.

  

Questo funziona perfettamente perché il csproj per una libreria di classi può fare riferimento a più altre librerie di classi, ma la Csproj per un eseguibile di solito non fa riferimento a un altro file eseguibile. Così, per ogni biblioteca localmente-costruita, l'unica dll nella sua cartella bin sarà se stessa, mentre tutte le applicazioni localmente-costruita conterrà il set completo di librerie a livello locale-costruiti fa riferimento.

Per comodità, nulla cambia per le librerie di riferimento che non sono costruite dalla soluzione, dal momento che questi di solito uso <Reference> insteannuncio di <ProjectReference>, e noi non ha modificato l'ex tag a tutti. Ma fare notare il presupposto appena accennato; se viene violata da alcuni dei vostri progetti, potrebbe essere necessario apportare alcune modifiche.

_{[1]. Miglioramento dell'affidabilità potrebbero essere riportate collisioni di file che possono verificarsi quando raccogliendo la stessa libreria da percorsi multipli disgiunti in un grafico di dipendenza, specialmente in concomitanza costruisce.}