Explication de la section des projets dans Global.json dans ASP.NET 5
J'ai remarqué que lors de la création d'un nouveau projet ASP.NET 5, il existe un répertoire src qui me semble parfaitement logique car j'ai toujours mis tout le code de ma solution dans un répertoire appelé source.
J'ai remarqué qu'il existe un fichier appelé global.json qui contient par défaut le contenu suivant:
{
"projects": [ "src", "test" ],
"sdk": {
"version": "1.0.0-rc1-update1"
}
}
J'ai trouvé les éléments suivants dans la documentation ASP.NET 5: La propriété projects désigne les dossiers contenant le code source de la solution. Par défaut, la structure du projet place les fichiers source dans un dossier src, ce qui permet de placer les artefacts de construction dans un dossier frère, ce qui facilite l’exclusion de ces éléments du contrôle de code source.
Cependant, voici la structure du projet que j'ai en tête (Il s'agira essentiellement de 2 grands projets que je veux sous la même solution):
MySolution
MySolutionProject1Src
client
p1.WebAPI
business
p1.Business
p1.Model
data
p1.Repository
test
p1.BusinessTests
p1.WebAPITests
MySolutionProject2Src
client
p2.Web
business
p2.Business
p2.Model
data
p2.Repository
test
p2.BusinessTests
Alors est-ce que je mettrais à jour global.json pour être le suivant? (un pour chaque répertoire parent):
{
"projects": [ "MySolutionProject1Src", "MySolutionProject2Src" ],
"sdk": {
"version": "1.0.0-rc1-update1"
}
}
ou devrait-il être quelque chose de plus comme ceci (un pour chaque sous-répertoire):
{
"projects": [ "MySolutionProject1Src/client", "MySolutionProject1Src/business", "MySolutionProject1Src/data" "MySolutionProject1Src/test", "MySolutionProject2Src/client", "MySolutionProject2Src/business", "MySolutionProject2Src/data" "MySolutionProject2Src/test" ],
"sdk": {
"version": "1.0.0-rc1-update1"
}
}
Ou devrais-je simplement le laisser comme "src" et mettre tout sous-dossiers sous src ..
Je suppose que je peux créer la structure de solution que je veux, mais ma préoccupation est les règles à suivre lors de la mise à jour de la section des projets global.json pour y correspondre. Sur la base de la documentation, il est indiqué qu'un dossier d'artefacts sera créé pour chaque chemin spécifié dans global.json. Je me demande donc si je veux un dossier d'artefacts pour chaque projet de la solution ou juste un gros à l'extérieur.
Tout d'abord, je vous ferais parvenir à la partie de la documentation , qui décrit global.json.
{
"projects": [ "src", "test" ],
"sdk": {
"version": "1.0.0-beta5",
"runtime": "clr",
"architecture": "x86"
}
}
version (et éventuellement runtime et architecture) sont importants car votre ordinateur possède plusieurs versions de dnx.exe. Vous pouvez examiner le répertoire %USERPROFILE%\.dnx\runtimes Pour voir tous les runtimes installés. La partie "sdk" De global.json Définit la version de dnx.exe À partir d'un des runtimes que vous avez installés.
Il est important de comprendre à propos de "projects" Une partie de global.json Qu'il sera analysé tous les dossiers frères à n'importe quel niveau sous chaque à partir du répertoire. Chaque project.json, Qui sera trouvé, sera interprété comme le projet de la solution.
Vous pouvez par exemple télécharger une partie d'ASP.NET et la placer dans le nouveau sous-dossier de votre hiérarchie de solutions. Par exemple, vous pouvez télécharger RC1 source d'Entity Framework 7 ( le fichier ) tout extraire le fichier Zip dans le nouveau dossier ef à l'intérieur de src dossier de votre projet. Vous verrez que, peu de temps après la réouverture de la solution, la liste de votre projet sera de plus en plus longue et tous les composants Entity Framework 7 seront inclus dans votre solution. De la même manière, vous pouvez extraire les sources téléchargées dans un répertoire séparé C:\aspnet\EF7 Et utiliser
{
"projects": [ "src", "c:/aspnet/EF7" ],
"sdk": {
"version": "1.0.0-rc1-update1"
}
}
Vous aurez les mêmes effets. Si vous décidez ultérieurement de supprimer le débogage des sources d'Entity Framework 7, vous devez simplement exclure "c:/aspnet/EF7" De global.json, Puis supprimer dans Visual Studio les projets ajoutés précédemment en les sélectionnant dans la vue Solution et en cliquant sur Del clé.
Je pense que cela devrait effacer les possibilités que vous avez dans les structures de dossiers.
Un autre fichier optionnel très important, qui pourrait exister dans la hiérarchie des solutions, est le fichier NuGet.config. Il définit le flux NuGet, où les packages seront chargés. Le problème est qu'il existe beaucoup référentiels NuGet (voir la réponse ), qui ont différentes versions préliminaires d'ASP.NET 5 Composants. Si vous utilisez les dépendances exactes comme
"EntityFramework.MicrosoftSqlServer": "7.0.0-rc1-final"
alors il suffit d'avoir la version explicite dans le référentiel NuGet. Le problème est que parfois on utilise la dépendance comme
"EntityFramework.MicrosoftSqlServer": "7.0.0-*"
pour charger la dernière version du package. Si vous utilisez un mauvais flux NuGet, vous pouvez obtenir les premières versions de RC2, qui sont incompatibles avec d'autres packages RC1 (au moins en raison du changement de nom de nombreux composants entre les versions bêta). Pour être sûr que votre solution (tous vos projets) utilise RC1, vous pouvez placer le NuGet.config Suivant dans votre dossier de solution (au-dessus de tous les projets), par exemple le contenu suivant
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageRestore>
<clear /> <!-- ensure only the sources defined below are used -->
<add key="automatic" value="False" />
</packageRestore>
<packageSources>
<add key="AspNetVNext" value="https://www.myget.org/F/aspnetmaster/api/v3/index.json" />
<add key="NuGet" value="https://api.nuget.org/v3/index.json" />
</packageSources>
<activePackageSource>
<add key="AspNetVNext" value="true" />
<add key="NuGet" value="true" />
</activePackageSource>
</configuration>
Voir la documentation . Je vous recommande d'ouvrir la ligne de commande dans un dossier de projet et d'exécuter
dnu feeds list
commander. Cela montrera que tous les NuGet.config Des dossiers courant et parent et le fichier global %appdata%\NuGet\NuGet.Config Seront combinés . NuGet recherchera les packages dans tous les référentiels actifs. Ce sera https://api.nuget.org/v3/index.json et https://www.myget.org/F/aspnetmaster/api/v3/index. json dans le cas ci-dessus.
Des conflits peuvent se produire si plusieurs NuGet.config Existent, pointent différents flux NuGet ou activent/désactivent certains flux. La commande dnu feeds list Aide ici. Vous devez toujours rechercher tous les fichiers NuGet.config Dans la hiérarchie de votre projet pour éviter/résoudre les conflits. La résolution de nombreux conflits consiste principalement à utiliser des flux corrects ou à utiliser des versions explicites pour la résolution des packages.
Je vous recommande de lire l'article , qui décrit l'héritage de configuration NuGet .
J'espère que vous pourrez décider quelle structure serait la meilleure pour votre environnement existant. Je recommanderais de tenir la structure standard
solution
src
project
folderWithProjects
et pour placer global.json et NuGet.config dans le répertoire de la solution. L'endroit par défaut pour les projets de test: séparé des projets principaux:
solution
src
project
folderWithProjects
test
testproject1
testproject2
(vous pouvez examiner la structure d'Entity Framework 7 sur GitHub ou MVC6 ici ). Vous pouvez suivre la structure ou choisir un autre emplacement et modifier la partie "projects" Du global.json.
MISE À JOUR: Microsoft a fait beaucoup de changements entre RC1 et RC2. Dnx.exe Ne sera plus utilisé dans ASP.NET Core. On devrait plutôt utiliser dotnet.exe. La description des global.json Et project.json Nouveaux/modifiés n'est pas encore entièrement documentée. Vous pouvez voir la version préliminaire de la documentation ici . Les liens sur l'ancienne documentation (sous https://docs.asp.net/en/latest/dnx) Sont maintenant rompus.