Ensemble “Copie Locale” à False par défaut?

Puis-je définir la valeur par défaut de l'option de "Copie Locale" dans Visual Studio pour de Faux? Dans la plupart des fois, quand j'ajoute une dll en tant que dépendance d'un projet, je veux la Copie Locale de propriété est définie sur False. Par défaut, il est Vrai. Est-il un moyen de changer le comportement par défaut de Visual Studio? (2008)

Pour une solution facile de commencer avec msbuild v 15 voir ma réponse ci-dessous stackoverflow.com/a/50755479/1196586

InformationsquelleAutor dr pain | 2010-06-23

copy-local visual-studio

37

Pas - Visual Studio utilise un règlement interne pour déterminer l'ensemble de la Copie Locale d'.

De MSDN:
1. Si la référence est un autre projet, un projet à projet de référence, la valeur est vrai.
2. Si l'assemblée est trouvé dans le cache d'assembly global, la valeur est faux.
3. Comme un cas particulier, la valeur de la mscorlib.dll de référence est faux.
4. Si l'assemblée est trouvé dans le Cadre de dossier SDK, alors la valeur est faux.
5. Sinon, la valeur est vrai.
- Le contenu dans la MSDN lien a été mis à la retraite
InformationsquelleAutor Leom Burke
27

En fait, vous le pouvez. Vous avez besoin d'un couple de choses:
1. Créer .targets fichier de copylocal (<Private> tag, pour être précis) false par défaut.
2. De l'importation de la cible dans .csproj fichiers. Vous pouvez l'ajouter dans la dernière ligne, avant la clôture de </Project> tag, ça va ressembler à <Import Project="..\Build\yourtarget.targets" />.
Maintenant chaque projet avec cet objectif a copylocal désactivé par défaut.

L'inconvénient est que vous devez modifier chaque fichier csproj, y compris de nouveaux. Vous pouvez contourner le nouveau projet d'émission par la modification de la VS modèle de projet. Au lieu de Class.cs décrit dans l'article du blog, vous avez besoin de modifier Class.vstemplate (dans le même fichier zip).

Avec cette approche, il y a un problème - le chemin lui-même. Si vous utilisez codé en dur chemin d'accès relatif nouvellement généré csproj fichiers, ils peuvent être faux (sauf si vous avez à plat de la structure de projet).

Vous pouvez:
- Faire VS générer corriger chemin d'accès relatif. Vous ne savez pas comment faire et si c'est encore possible.
- Les ignorer et de les modifier manuellement le chemin d'accès pour chaque nouveau csproj (selon le nombre de nouveau projet vous avez, tout n'est pas idéal, qui peut être tolérable).
- Utiliser la variable d'environnement plutôt que de chemin d'accès relatif. Dans ce cas, chaque développeur devra le même ensemble de variables.
Il doit y avoir une meilleure solution, mais je n'ai pas encore trouvé.
- Cela semble être la bonne réponse, j'ai suivi les conseils et les liens et ça marche!!!
- avez-vous trouvé un moyen astucieux de mettre à l'importation dans un nouvellement créé csproj fichiers?
- Nous jouons avec une commune .csproj fichier importé dans chaque nouveau projet à l'aide d'un modèle. Le système de template n'est pas très propre et nous ne savons pas si nous l'aimons encore.
- Vous pouvez dresser la liste de tous les fichier de projet sous une racine avec dir /s /b *csproj > project-files.txt puis les ouvrir avec dire notepad++ for /f %i in (project-files.txt) ne notepad++ "%i". Comme notepad++ vous permet de remplacer dans tous les fichiers ouverts, vous pourriez demander à remplacer (à l'aide d'expressions régulières) ^</Projet> par <Projet d'Importation="$$SolutionDir$customTarget.cibles /></Projet>. Il suffit ensuite de créer un des objectifs de fichier customTarget.cible à côté de votre .la sln fichier. J'ai voulu essayer, mais la barrière à l'entrée semblait énorme (la modification de tous les csproj!) mais alors, ce qui m'a frappé ...
InformationsquelleAutor ya23
7

Nous n'utilisons pas un .objectifs de fichiers (comme suggéré dans la réponse ya23), afin que nous venons de modifier la .csproj projet de fichier manuellement dans un éditeur de texte et ajoutez le <Private> élément de la référence, comme ceci:
```
<Reference Include="[...]">
  <Private>False</Private>
  [...]
</Reference>
```
La valeur de la <Private> élément correspond à la valeur de la "Copie locale" de la propriété. Par exemple, si <Private> est définie sur False, "Copie locale" est aussi faux..

InformationsquelleAutor herzbube
4

Cogner ce parce qu'il semble qu'il y ait maintenant un package nuget permettant exactement ce...

https://nuget.org/packages/CopyLocalFalse

N'ai pas encore essayé, en espérant que ça aide.
- Avec ce package nuget il n'y a aucune garantie. Il a quelques modes de filtrage dans le script d'installation qui va sauter certaines des références. Aussi il rus seulement au moment de l'installation du package nuget. Le package nuget est peut-être déjà installé et une nouvelle référence ajoutée entre-temps. Aussi de ce que si le package nuget est restauré avant d'autres paquets sont restaurés, les autres paquets peuvent réinitialiser copie locale de leur assemblys référencés? Pas recommandé approche. Mieux utiliser une cible pour remplacer la copie locale et avoir votre propre filtrage.
InformationsquelleAutor mabian69
4

De départ avec msbuild v 15, vous pouvez copier un fichier unique appelé Répertoire.Construire.accessoires dans le dossier racine qui contient votre source:
```
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemDefinitionGroup>
  <Reference>
    <Private>False</Private>
  </Reference>
  <ProjectReference>
     <Private>False</Private>
  </ProjectReference>
</ItemDefinitionGroup>
</Project>
```
Plus rien à faire! Cela fonctionne bien avec Visual Studio 2017 et aussi la vNext Construire. Puissiez-vous avoir à fermer Visual Studio et que d'ouvrir votre solution de nouveau à prendre le fichier d'effet.

https://docs.microsoft.com/en-us/visualstudio/msbuild/customize-your-build#directorybuildprops-and-directorybuildtargets
- Est-ce une méthode qui peut être utilisée uniquement pour .net de base des projets? Ou vous pouvez aussi le faire pour les anciens .net de projets par exemple .net 452?
- Je l'ai juste essayé la réponse est oui.
- À la lecture de Glen Slayden réponse, ne serait-il pas mieux d'inclure <ProjectReference> <Privé>False</Privé> </ProjectReference> ainsi?
- Barnett Vous avez raison, si ce travail pour ProjectReferences trop. Avez-vous essayé? Vous pouvez ajouter la balise dans ma réponse, si vous le souhaitez. Je n'utilise pas les Références de Projet dans mon Projet. J'ai vérifié la solution avec dll-Références on.Net 4.7.1 et vNext Construire sur TFS 2018 et Visual Studio Enterprise 2017
- Oui je l'ai essayé sur un .net 4.5.2 projet. Celui-ci utilisait des références de projet et de toute évidence ne fonctionne pas jusqu'à ce que j'ai réalisé que j'avais besoin d'utiliser la référence du projet de la balise, puis il a fait un travail. Vraiment une très bonne solution, car il n'est pas nécessaire de modifier les fichiers existants. J'ai ajouté la balise et de l'attente de l'examen par les pairs.
InformationsquelleAutor gReX
1

Concernant la solution posté par @herzbube, si vous souhaitez désactiver la "Copie Locale" pour tous (ou la plupart) des références dans votre .csproj fichier, vous n'avez pas besoin de <Private>False</Private> individuellement sur chaque Reference, vous pouvez simplement mettre directement dans la .csproj:
```
<ItemDefinitionGroup>
  <Reference>
    <Private>False</Private>
  </Reference>
</ItemDefinitionGroup>
```
Cela n'affecte pas les projets référencés avec <ProjectReference>, mais vous pouvez faire la même chose, à la place ou en plus-pour ceux:
```
<ItemDefinitionGroup>
  <ProjectReference>
    <Private>False</Private>
  </ProjectReference>
</ItemDefinitionGroup>
```
Si vous souhaitez à la fois de ces, vous pouvez les fusionner en un seul groupe:
```
<ItemDefinitionGroup>
  <Reference>
    <Private>False</Private>
  </Reference>
  <ProjectReference>
    <Private>False</Private>
  </ProjectReference>
</ItemDefinitionGroup>
```
Assurez-vous que vous mettez ces remplacements avant la première <Reference ...> ou <ProjectReference ...> vous souhaitez affecter parce que ces blocs ne s'appliquera qu'aux références qui apparaissent au-dessous d'eux. Ensuite, si il ya un peu que vous ne voulez vraiment être localement copié, vous pouvez simplement remplacer ceux retour individuellement (c'est à dire, à l'intérieur de l'étiquette elle-même), cette fois en utilisant True.

Pour les cas les plus avancés, vous pouvez changer la valeur de remplacement des aller-retour entre Vrai et Faux plusieurs fois dans le même .fichier csproj. Une autre technique de pointe serait de placer stratégiquement certaines de vos références en dessous de ces blocs, et d'autres ci-dessus, de sorte que le dernier ne sera pas affectée.

Tout cela devrait faire le XML dans votre .csproj beaucoup plus propre et plus facile à lire. Mais il y a encore plus de bonnes nouvelles, alors lisez la suite...

Pour sélectionner les projets qui devraient être marqués <Private>False</Private> cela dépend généralement de la situation spécifique, mais il y a quelque chose de fondamental tout le monde peut et devrait ne pour les débutants. C'est une étape de base, simple et efficace, il offre un tel énorme MSBuild l'amélioration de la fiabilité^1. et au moment de la construction de l'accélération, et avec peu d'inconvénients--chaque grande solution qui utilise la valeur par défaut (à l'échelle locale par projet) C# des emplacements de sortie doit presque toujours faire ce réglage:
En tout et chaque solution Visual Studio qui s'appuie plusieurs C# bibliothèques de classe avec n'importe quel nombre non négligeable de <ProjectReference> inter-dépendances, et qui culmine dans la construction d'un plus applications (c'est à dire les exécutables):
1. Près du haut du .csproj pour chaque bibliothèque de classe, insérez le <ProjectReference> bloc indiqué ci-dessus.
  
  RAISON: Il n'est pas nécessaire pour tout .dll de collecter toutes les bibliothèques de références dans un sous-répertoire de son propre, car aucun exécutable est jamais exécuté à partir de cet emplacement. Ces galopante, la copie est inutile travail et peut-être inutilement ralentir votre construire, éventuellement de façon assez spectaculaire.
2. D'autre part, ne pas modifier la .csproj pour toute de votre solution applications.
  
  La RAISON: les Exécutables besoin d'avoir tous le privé construit des bibliothèques dont ils ont besoin dans leurs sous-répertoires, mais la construction pour chaque application devrait être seul responsable individuellement de collecte de chaque dépendance, directement à partir de son sous-répertoire, dans l'application du sous-répertoire.
Cela fonctionne parfaitement puisque l' .csproj pour une bibliothèque de classe peut faire référence à plusieurs autres bibliothèques de classes, mais le .csproj pour un exécutable généralement jamais fait référence à un autre fichier exécutable. Ainsi, pour chaque construit localement de la bibliothèque, la seule .dll dans son bin dossier sera lui-même, alors que tous les construit localement candidature contiendra l'ensemble des construit localement les bibliothèques de références.

Idéalement, rien ne change pour le référencés bibliothèques qui ne sont pas construits par votre solution, car il s'agit généralement de l'utilisation <Reference> au lieu de <ProjectReference>, et nous n'avons pas modifier l'ancienne balise. Mais notez l'hypothèse vient d'être mentionné; si elle est malmenée par certains de vos projets, vous devrez peut-être faire quelques ajustements.

_{[1.] L'amélioration de la fiabilité pourrait être lié à la collision de fichiers qui peuvent se produire lors de la collecte de la même bibliothèque à partir de plusieurs disjoints de chemins dans un graphe de dépendance, en particulier dans simultanées construit.}

InformationsquelleAutor Glenn Slayden

Vous devez vous connecter pour publier un commentaire.