Je suis en train de mettre en place un projet ASP.NET Core sur TeamCity. Les fichiers binaires qu'il crée se bloquent au démarrage sur d'autres ordinateurs. Le message d'erreur indique qu'il recherche des dll dans des chemins qui n'existent que sur le serveur de génération. DotPeek montre qu’il existe dans le fichier .exe un fichier de ressources incorporé appelé myproject.deps.json
. Dans la section des cibles, il y a des références aux dll utilisant des chemins absolus. Cela signifie que les fichiers binaires ASP.NET Core ne seront exécutés que sur la machine sur laquelle ils ont été créés.
Comment puis-je résoudre ce problème? Qu'est-ce que ce fichier et comment lui faire utiliser des chemins relatifs? Après quelques recherches, il semble que les chemins viennent de project.fragment.lock.json
, qui est un fichier généré. Si je modifie cela pour utiliser des chemins relatifs, le fichier est simplement écrasé à nouveau. Qu'est-ce qui génère cela et comment peut-il être corrigé ou arrêté?
Pour ceux qui ont demandé, project.json
ressemble à:
{
"dependencies": {
"CommandLineParser": "1.9.71",
"Microsoft.AspNetCore.Mvc": "1.0.0",
"Microsoft.AspNetCore.Server.IISIntegration": "1.0.0",
"Microsoft.AspNetCore.Server.Kestrel": "1.0.0",
"Microsoft.Extensions.Configuration.EnvironmentVariables": "1.0.0",
"Microsoft.Extensions.Configuration.FileExtensions": "1.0.0",
"Microsoft.Extensions.Configuration.Json": "1.0.0",
"Microsoft.Extensions.Logging": "1.0.0",
"Microsoft.Extensions.Logging.Console": "1.0.0",
"Microsoft.Extensions.Logging.Debug": "1.0.0",
"Microsoft.Extensions.Options.ConfigurationExtensions": "1.0.0",
"System.Configuration.Abstractions": "1.0.0"
},
"tools": {
"Microsoft.AspNetCore.Server.IISIntegration.Tools": "1.0.0-preview2-final"
},
"frameworks": {
"net461": {
"dependencies": {
"Company.Common": {
"target": "project"
},
"Company.Integration": {
"target": "project"
},
"Company.Functions": {
"target": "project"
},
"Company.Utils": {
"target": "project"
}
}
}
},
"buildOptions": {
"emitEntryPoint": true,
"preserveCompilationContext": true
},
"publishOptions": {
"include": [
"wwwroot",
"Views",
"Areas/**/Views",
"appsettings.json",
"web.config"
]
},
"scripts": {
"postpublish": [ "dotnet publish-iis --publish-folder %publish:OutputPath% --framework %publish:FullTargetFramework%" ]
}
}
La réponse à votre première question, selon le documentation du fichier de configuration d'exécution:
Et la réponse à votre deuxième question est de supprimer remove preserveCompilationContext de votre fichier project.json (et de le recréer).
MyApp.deps.json est une liste de dépendances, ainsi que des données de contexte de compilation et des dépendances de compilation. Non requis techniquement, mais requis pour utiliser les fonctionnalités d'installation du service/cache de package/package partagé.
D'après votre commentaire à Dimitry, je ne saurais dire si un noyau .net est installé sur votre ordinateur cible et donc en déduire le type de déploiement que vous essayez de faire. Mais en supposant qu'il soit installé, vous devriez pouvoir régler votre myproject.runtime.json pour résoudre vos problèmes. Si vous ne le faites pas, je vous recommande vivement de vous renseigner sur les deux types de . NET Core Application Deployment:
Vous pouvez créer deux types de déploiements pour les applications .NET Core:
Déploiement dépendant de la structure . Comme son nom l'indique, le déploiement dépendant de l'infrastructure (FDD) repose sur une version partagée de l'ensemble de systèmes .NET Core pour être présente sur le système cible. Parce que .NET Core est déjà présent, votre application est également portable entre les installations de .NET Core. Votre application contient uniquement son propre code et les dépendances tierces extérieures aux bibliothèques .NET Core. Les FDD contiennent des fichiers .dll qui peuvent être lancés à l'aide de l'utilitaire dotnet à partir de la ligne de commande. Par exemple, dotnet app.dll exécute une application nommée app.
Déploiement autonome . Contrairement à FDD, un déploiement autonome (SCD) ne dépend pas de la présence de composants partagés sur le système cible. Tous les composants, y compris les bibliothèques .NET Core et le runtime .NET Core, sont inclus dans l’application et sont isolés des autres applications .NET Core. Les SCD incluent un exécutable (tel que app.exe sur les plates-formes Windows pour une application nommée app), qui est une version renommée du .NET Core Host spécifique à la plate-forme, et un fichier .dll (tel que app.dll), qui est: l'application réelle.
*.deps.json
provient de preserveCompilationContext
.
La préservation du contexte de compilation est utile pour la compilation à l'exécution (c'est-à-dire la compilation juste à temps) et en particulier pour la compilation des vues. Ce n'est généralement pas utile pour les bibliothèques. Pour résoudre votre problème:
preserveCompilationContext
de chaque Company.*
bibliothèque que votre application référence.preserveCompilationContext
de votre application principale.Il y a une conversation impliquée ici: https://github.com/aspnet/Mvc/issues/5141
Si vous utilisez le nouveau format .csproj
Ajouter <PreserveCompilationContext>false</PreserveCompilationContext>
sous le <TargetFramework>
tag corrigé le problème pour moi.
<PropertyGroup>
<TargetFramework>netcoreapp1.1</TargetFramework>
<PreserveCompilationContext>false</PreserveCompilationContext>
</PropertyGroup>
Après une recherche complète enfin trouvé ma solution, c'était mon cas: - ne se produit que lorsque exécuté
publier dotnet
donc pour résoudre ce problème, éditez votre csproj et assurez-vous d’avoir cette configuration.
Ceci s'applique à webapi netcoreapp 2.0
<PropertyGroup>
<MvcRazorCompileOnPublish>false</MvcRazorCompileOnPublish>
<PreserveCompilationContext>false</PreserveCompilationContext>
</PropertyGroup>
cela permettra également de résoudre les problèmes liés à
"erreur CS0246: le type ou le nom de l'espace de noms 'System' est introuvable"
ref .: https://github.com/aspnet/MvcPrecompilation/issues/162https://github.com/dotnet/dotnet-docker/issues/279