Powershell: Référencement de System.Management.Automation dans .NET Core / VS Code
Quelle est la bonne façon de référencer System.Management.Automation ? Par exemple, cet extrait de project.json :
"dependencies": {
"Microsoft.NETCore.App": {
"version": "1.0.0",
"type": "platform"
},
"Microsoft.AspNetCore.Diagnostics": "1.0.0",
"Microsoft.AspNetCore.Server.IISIntegration": "1.0.0",
"Microsoft.AspNetCore.Server.Kestrel": "1.0.0",
"Microsoft.Extensions.Logging.Console": "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.Configuration.CommandLine": "1.0.0",
"Microsoft.AspNetCore.Routing": "1.0.0",
"System.Security.Cryptography.Algorithms": "4.2.0",
"System.Management.Automation": "6.1.7601.17514"
},
Fonctionne lorsque vous exécutez la restauration dotnet en ce sens qu'elle trouve et prétend installer la dépendance System.Management.Automation (en notant que .17515 n'est pas compatible avec .NET Core). Mais vous ne pouvez pas simplement ajouter un using dans le code, ou cela dit :
The type or namespace name 'Management' does not exist in the namespace 'System'
L'intention ici est d'instancier PowerShell par programmation dans le code, mais .NET Core est un peu restrictif dans la façon dont il veut que les références soient gérées...
concentrateddon
Tous les 3 commentaires
Il s'agit d'un problème connu pour NuGet que nous essayons de résoudre. Il existe un certain nombre de packages System.Management.Automation malveillants que des personnes externes ont publiés. Ces packages sont tous des assemblys « FullCLR » et ne sont pas compatibles avec PowerShell Core.
La façon actuelle de consommer la version PowerShell Core de System.Management.Automation consiste à copier la technique utilisée par ce projet. Notre fichier nuget.config pointe vers la version correcte publiée sur MyGet. powershell-win-core\project.json montre comment le consommer dans votre project.json.
mirichmo
le 16 sept. 2016
Salut Don.
Il y a peu de choses sur dotnet cli qui peuvent vous aider à régler le problème.
- Si vous ne spécifiez pas explicitement les flux nuget avec
nuget.configil utilisera https://www.nuget.org
L'équipe PowerShell n'y a pas publié SMA, mais quelqu'un l'a fait il y a longtemps (comme l' a dit https://www.nuget.org/packages?q=System.Management.Automation - Votre configuration actuelle consomme ce package de nuget. Vous pouvez le faire consommer votre copie SMA locale de GAC, si vous construisez pour FullCLR, mais vous devrez inclure une référence sous
frameworks / net451 / frameworkAssemblies, comme ici https://github.com/PowerShell/PowerShell/blob/dd2394b1e6088f6c82054f5cae5520e532010fd4 /src/System.Management.Automation/project.json#L188 - Il existe différentes sections
dependenciesdansproject.json: globales et spécifiques au framework. Vous devez les utiliser de manière appropriée. - La version CoreCLR de SMA nécessitera un massage supplémentaire lors de l'initialisation pour enregistrer l'ALC (AssemblyLoadContext). Par exemple, consultez notre programme d'exécution de test c# : https://github.com/PowerShell/PowerShell/blob/master/test/csharp/fixture_AssemblyLoadContext.cs
vors
le 16 sept. 2016
Parfait.
concentrateddon
le 16 sept. 2016
Questions connexes
andschwa
·
3Commentaires
Michal-Ziemba
·
3Commentaires
pcgeek86
·
3Commentaires
pcgeek86
·
3Commentaires
abock
·
3Commentaires