Comment convertir un CSproj non principal au format VS2017
J'ai deux projets dans VS2015
- Un .NET Core (project.json, xproj)
- Un csproj .NET régulier
Lorsque j'ouvre le projet 1 avec VS2017, il migre bien vers le nouveau format csproj.
Le projet 2 fonctionne dans VS2017, mais j'aime convertir/migrer/mettre à jour ce csproj au nouveau format de fichier de projet pour bénéficier des nouvelles fonctionnalités de csproj (cible multiple, pas de grande liste de fichiers, csproj lisible, informations NuSpec dans csproj, etc.)
Comment pourrais-je faire ça? Je ne trouve pas d'option dans VS2017 pour cela.
Utilisation: VS2017 RTM
Il n'y a pas d'option intégrée dans VS car le nettoyeur csproj est principalement destiné aux projets .NET Core. Il ne fonctionne pas entièrement avec tous les autres types de projets sans effort et sans autres personnalisations dans le fichier de projet. Par exemple, le câblage de choses comme les générateurs de code ou l'imbrication dans les applications Winforms ou WPF peut ne pas fonctionner par défaut pour un nouveau style SDK (nouveau style) .csproj. Ceux-ci peuvent généralement être contournés en mettant à jour les métadonnées selon les besoins:
<ItemGroup>
<Compile Update="Properties\Resources.Designer.cs">
<AutoGen>True</AutoGen>
<DependentUpon>Resources.resx</DependentUpon>
</Compile>
</ItemGroup>
Notez que l'attribut Update est la clé ici - vous ne voulez pas inclure le fichier une deuxième fois dans le ItemGroup, vous voulez juste mettre à jour ses métadonnées existantes (ou manquantes).
Il existe également des mises en garde pour certains types de projets où les cibles ne sont pas importées comme prévu dans un csproj vs SDK et un ancien. Cela dépend de la façon dont vos cibles sont créées, mais un exemple de cela est la construction de projets VSIX (extensions VS) en utilisant le VSSDK est vraiment difficile à obtenir correctement dans un projet basé sur SDK.
Si vous voulez essayer la conversion, le blog de Nate McMaster est une excellente ressource. Il couvre à la fois le démarrage à partir de zéro et la conversion du fichier in situ. J'ai constaté que la plupart du temps, cela se passe assez bien pour commencer avec un nouveau .csproj propre et ajouter toute solution de contournement nécessaire.
Il convient également de souligner qu'une grande partie de la merde dans votre fichier csproj normal est simplement du contenu généré, et une petite modification manuelle peut grandement contribuer à le nettoyer. L'utilisation de modèles de globalisation, par exemple, peut enregistrer des centaines de lignes dans un fichier de projet volumineux. Cela fait partie de la façon dont les projets basés sur le SDK fonctionnent de toute façon - ils ne font que les globes dans le SDK, donc cela n'apparaît pas dans le .csproj, mais cela fonctionne presque de la même manière. Par exemple, si vous souhaitez inclure tous les fichiers C # dans un dossier (récursivement), vous pouvez faire quelque chose comme ceci:
<ItemGroup>
<!-- Include all C# files under the SampleFolder and any child folders -->
<Compile Include="SampleFolder\**\*.cs" />
<!-- Include all C# files under this project's root: -->
<Compile Include="**\*.cs" />
<ItemGroup>
Le ** correspond à n'importe quel chemin de dossier récursif.
Il existe quelques différences dans le comportement de Visual Studio, car le nouveau système de projet pour les projets basés sur SDK fonctionne très différemment de l'ancien système de projet .csproj. Par exemple, les projets SDK détectent automatiquement les changements de fichiers sur le disque et les ajoutent/suppriment dans les projets; old-csproj ne les mettra pas à jour dans VS tant que le projet ne sera pas rechargé.
Si vous utilisez la globalisation partout, vous rencontrerez un problème similaire à celui de csproj basé sur SDK, où certains fichiers ne sont pas connectés à leurs générateurs de code ou imbriqués correctement. Comme ci-dessus, vous pouvez utiliser le Update= attribut pour corriger des fichiers spécifiques (ou même des globes plus spécifiques) afin de récupérer les métadonnées.
Cela vaut peut-être la peine de les examiner. Il semble que cela ne puisse pas être fait pour des types de projets plus complexes, mais la console et les bibliothèques semblent être évolutives http://www.natemcmaster.com/blog/2017/03/09/vs2015-to-vs2017- mise à niveau /
https://github.com/NickCraver/PerfBenchmarks/commit/53c3013b1774056363dcab867bceb1b89ce9592c
Et en ce qui concerne l'ajout des types de sdk plus complexes, vous pouvez regarder ce problème de github.