web-dev-qa-db-fra.com

Que signifie la victoire / tout runtime dans .NET Core

Je crée une application principale C # .NET et elle cible le net452 cadre. Lorsque je publie, je peux spécifier un runtime (--runtime), si je ne spécifie aucun runtime qu'il utilise win7-x64 (Je suppose que c'est parce que c'est ce que ma machine exécute). Cependant, je peux également spécifier manuellement le runtime et il semble accepter toute chaîne que je lui donne. Cependant, le catalogue RID semble suggérer que win ainsi que any sont valides.

MISE À JOUR: Je n'ai pas de bonnes réponses, donc je vais clarifier mes questions et ajouter une prime. J'ai également demandé sur les forums principaux ASP.NET, mais je n'ai reçu aucune réponse.

  1. Si je spécifie un RID de win7-x32 mon code fonctionnera-t-il également sur un système d'exploitation Windows 64 bits?

  2. Si je spécifie un RID de win7, que construit-il, construira-t-il la version 32 bits ou la version 64 bits?

  3. Si je spécifie un RID de win7, mon programme fonctionnera-t-il sous Windows 8, 8.1 ou 10?

  4. Que fait le any RID? Je comprends comment le déploiement portable peut être utilisé sur plusieurs plates-formes, mais comment le déploiement autonome (construit avec un RID de any) peut-il fonctionner sur Linux ainsi que Windows? Suis-je en train de mal comprendre ce RID?

  5. Si je spécifie un RID de blah je m'attendais à une erreur. Au lieu de cela, mon application a été créée dans le bin/Release/blah répertoire. Est-ce simplement par défaut sur un autre runtime?

c#.net.net-coreruntime-identifier
32
Pace

Les RID sont utilisés avec .NET Core pour résoudre les dépendances sur les packages. La racine de ce processus de résolution des dépendances est votre projet, que vous marquez explicitement avec un ou plusieurs RID. Lors de la construction du projet, vous indiquez pour quel RID vous construisez.

Les RID sont définis dans une forêt d'arbres de compatibilité, où n'importe quel nœud dans une arborescence représente un environnement d'exécution qui peut prendre en charge tous ses enfants. Chaque RID est la racine d'un tel arbre.

Voici un exemple d'arbre de compatibilité RID:

win10-x64
|- win10
|  `- win81
|     `- win8
|        `- win7
|           `- win
|              `- any
|                 `- base
`- win81-x64
   |- win81 (already included above)
   `- win8-x64
      |- win8 (already included above)
      `- win7-x64
         |- win7 (already included above)
         `- win-x64
            `- win (already included above)

Le graphique complet des arbres de compatibilité RID est défini ici:

https://github.com/dotnet/corefx/blob/master/pkg/Microsoft.NETCore.Platforms/runtime.json

Un package peut fournir une implémentation différente pour chaque RID si nécessaire. Lors de la construction, si j'ai une dépendance sur ce package, le processus de génération sélectionnera l'implémentation la plus proche de la racine de l'arborescence. Si l'arborescence ne contient aucun RID fourni par le package, la génération échouera.

Il existe un type spécial de package appelé "package d'exécution". Les packages d'exécution contiennent des fichiers binaires natifs qui sont directement chargés et exécutés par le système d'exploitation hôte. En tant que tels, ces packages fournissent uniquement des implémentations pour des versions de système d'exploitation concrètes: "win7-x64", par exemple, mais pas "win7" ou "win-x64", et, par exemple, "ubuntu.16.04-x64", mais pas "ubuntu .16.04 "," ubuntu-x64 "ou" linux ".

[ Mise à jour: à partir de .NET Core 2.0, vous pouvez construire pour Linux-x64 pour cibler "toutes" les versions x64 de Linux avec une seule construction. Voir https://blogs.msdn.Microsoft.com/dotnet/2017/08/14/announcing-net-core-2-0/ ]

Les packages d'exécution entrent en jeu lors du regroupement de projets autonomes. Avec un projet autonome, tout ce qui est nécessaire pour exécuter le projet doit être inclus dans la sortie de génération. Cela signifie que la sortie de génération doit inclure un binaire natif comme point d'entrée pour l'application. Ce binaire natif est fourni par le package d'exécution.

Donc, pour répondre à vos questions:

  1. Si je spécifie un RID de win7-x32, mon code fonctionnera-t-il également sur un système d'exploitation Windows 64 bits?

Oui, mais il s'exécutera dans un processus 32 bits. J'ai vérifié cela avec une application construite et publiée à partir d'un développeur Ubuntu VM et exécutée par la suite sur Windows 10 64 bits; si l'application est publiée sur win7-x32, puis IntPtr.Size est 4 et s'il est publié contre win7-x64, puis IntPtr.Size est 8. Il fonctionne dans les deux sens.

Le win7-x32 le package d'exécution comprend un fichier EXE 32 bits qui héberge le runtime .NET Core, puis charge et exécute votre projet, qui est regroupé à côté dans un fichier DLL du même nom).

  1. Si je spécifie un RID de win7, que construit-il, construira-t-il la version 32 bits ou la version 64 bits?

Si vous spécifiez un RID de win7, il essaiera de trouver des versions binaires natives étiquetées avec ce RID, ou un RID compatible, mais il n'en trouvera pas. La génération échouera, car il n'existe pas de version "win7" du fichier EXE principal d'entrée. Vous devez spécifier 32 bits ou 64 bits (et il semble que toutes les autres plates-formes sont uniquement en 64 bits).

J'ai testé ce détail spécifique et j'ai constaté que:

  • Le dotnet restore l'étape n'échoue pas, mais n'installe pas non plus un runtime pour win7 (ou win10).

  • Le dotnet build l'étape réussit à compiler l'application de test, mais émet ensuite cette erreur:

    Impossible de rendre le projet exécutable suivant: helloworld (.NETCoreApp, Version = v1.1) raison: bibliothèque de coreclr attendue introuvable dans le graphique du package. Veuillez réessayer la restauration dotnet.

  1. Si je spécifie un RID de win7, mon programme fonctionnera-t-il sous Windows 8, 8.1 ou 10?

En supposant que vous spécifiez soit win7-x86 ou win7-x64, alors oui. Le win7-x86 ou win7-x64 le package d'exécution fournira un point d'entrée EXE qui est un EXE 32 bits ou 64 bits, respectivement, et ces EXE sont des binaires natifs qui s'exécuteront sur n'importe quelle version de Windows à partir de Windows 7.

Notez qu'il n'existe actuellement aucun package d'exécution pour Windows 8, Windows 8.1 ou Windows 10 spécifiquement. Les graphiques de compatibilité pour les nouvelles versions de Windows incluent win7-x86 ou win7-x64, selon le cas, et afin qu'un package d'exécution particulier finisse par être utilisé dans la génération, même si vous ciblez un RID plus récent tel que win10-x64.

  1. Que fait le any RID? Je comprends comment le déploiement portable peut être utilisé sur plusieurs plates-formes, mais comment le déploiement autonome (construit avec un RID) peut-il fonctionner sur Linux ainsi que Windows? Suis-je en train de mal comprendre ce RID?

Le RID any permet à un package de fournir une implémentation pour tout RID plus haut dans la chaîne, car tous les autres RID incluent finalement any (et base) dans leur arbre de compatibilité. Cependant, les packages d'exécution ne fournissent aucune implémentation pour any, et donc any ne peut pas être utilisé pour créer des packages autonomes.

  1. Si je spécifie un RID de blah, je m'attendais à une erreur. Au lieu de cela, mon application a été construite dans le répertoire bin/Release/blah. Est-ce simplement par défaut sur un autre runtime?

Votre projet doit être configuré avec "type": "platform" dans la dépendance de Microsoft.NETCore.App. En tant que tel, aucun package autonome n'a été construit et la résolution des bibliothèques de prise en charge est laissée à l'exécution, auquel cas le RID est fourni par le temps d'exécution réel que vous utilisez pour exécuter votre application, plutôt que par la configuration de construction de votre application.

Si votre projet est une bibliothèque, lorsque vous essayez de le référencer à partir d'un autre projet, vous pouvez rencontrer des problèmes car votre bibliothèque ne fournit qu'une implémentation pour la plate-forme "blah", qui ne sera pas dans l'arborescence de compatibilité du RID le un autre projet se construit contre. Si votre projet est une application, blah est ignoré.

Si vous reconfigurez votre projet pour produire un package autonome (en supprimant ou en commentant le "type": "platform" faire la queue project.json), vous constaterez qu'il ne se compile plus, car il a maintenant une dépendance sur les packages d'exécution, et il n'y a pas de package pour RID blah.

30
Jonathan Gilbert

Je crois que le documentation officielle lié à l'OP a fourni toutes les informations nécessaires.

Tout d'abord

Que sont les RID?

RID est l'abréviation de Runtime IDentifier. Les RID sont utilisés pour identifier les systèmes d'exploitation cibles sur lesquels une application ou un actif (c'est-à-dire un assembly) s'exécutera.

Il est important de noter que les RID sont des chaînes vraiment opaques. Cela signifie qu'ils doivent correspondre exactement aux opérations qui les utilisent pour fonctionner.

Cela a également été cité par GitHub

Un RID est une chaîne opaque qui identifie une plate-forme. Les RID ont des relations avec d'autres RID en "important" l'autre RID. De cette façon, un RID est un graphe orienté de RID compatibles.

Meilleur RID Considérons le graphique RID partiel:

"any": {},

"win": {
    "#import": [ "any" ]
},
"win-x86": {
    "#import": [ "win" ]
},
"win-x64": {
    "#import": [ "win" ]
},
"win7": {
    "#import": [ "win" ]
},
"win7-x86": {
    "#import": [ "win7", "win-x86" ]
},
"win7-x64": {
    "#import": [ "win7", "win-x64" ]
}

Cela peut être visualisé sous forme de graphique dirigé, comme suit:

win7-x64    win7-x86
   |   \   /    |
   |   win7     |
   |     |      |
win-x64  |  win-x86
      \  |  /
        win
         |
        any

En tant que tel, le meilleur RID lors de l'évaluation de win7-x64 serait: win7-x64, win7, win-x64, win, any De même, lors de l'évaluation de win-x64: win-x64, win, any Notez que win7 vient avant win-x64 en raison de l'importation pour win7 apparaissant avant l'importation pour win-x64 dans l'ordre des documents.

Cela dit, et en référençant runtime.json sur le dépôt CoreFX.

Si vous utilisez ce fichier, vous remarquerez que certains des RID contiennent une instruction "#import". Ces déclarations sont des déclarations de compatibilité. Cela signifie qu'un RID qui contient un RID importé peut être une cible pour la restauration de packages pour ce RID.

Extraire uniquement les parties pertinentes,

1) Si je spécifie un RID de win7-x32 mon code fonctionnera-t-il également sur un système d'exploitation Windows 64 bits?

"base": {
},

"any": {
    "#import": [ "base" ]
},
...
"win": {
    "#import": [ "any" ]
},
...
"win7": {
        "#import": [ "win" ]
    },
"win7-x86": {
    "#import": [ "win7", "win-x86" ]
},
"win7-x64": {
    "#import": [ "win7", "win-x64" ]
},
...

2) Si je spécifie un RID de win7, que construit-il, construira-t-il la version 32 bits ou la version 64 bits?

Il créera une version commune qui peut fonctionner sur les deux plates-formes. Reportez-vous à la visualisation ci-dessus.

3) Si je spécifie un RID de win7, mon programme fonctionnera-t-il sous Windows 8, 8.1 ou 10?

Oui. Basé sur les importations des versions référencées.

"win8": {
    "#import": [ "win7" ]
},
"win8-x86": {
    "#import": [ "win8", "win7-x86" ]
},
"win8-x64": {
    "#import": [ "win8", "win7-x64" ]
},
"win8-arm": {
    "#import": [ "win8" ]
},

"win81": {
    "#import": [ "win8" ]
},
"win81-x86": {
    "#import": [ "win81", "win8-x86" ]
},
"win81-x64": {
    "#import": [ "win81", "win8-x64" ]
},
"win81-arm": {
    "#import": [ "win81", "win8-arm" ]
},

"win10": {
    "#import": [ "win81" ]
},
"win10-x86": {
    "#import": [ "win10", "win81-x86" ]
},
"win10-x64": {
    "#import": [ "win10", "win81-x64" ]
},

4) Que fait le any RID?

Cela signifie que la version est compatible avec any des plates-formes prises en charge et peut être une cible pour la restauration de packages pour n'importe quel RID.

5) Si je spécifie un RID de blah je m'attendais à une erreur. Au lieu de cela, mon application a été créée dans le bin/Release/blah directory. Est-ce simplement par défaut sur un autre runtime?

Documentation du formulaire de soumission:

Tous les RID finissent par correspondre à la racine any RID.

Et enfin, encore une fois à partir de la documentation, prenez note

Bien qu'ils semblent assez faciles à utiliser, il y a certaines choses spéciales sur les RID que vous devez garder à l'esprit lorsque vous travaillez avec eux:

  • Ce sont des cordes opaques et doivent être traitées comme des boîtes noires
    • Vous ne devez pas construire de RID par programmation
  • Vous devez utiliser les RID déjà définis pour la plate-forme et ce document montre que
  • Les RID doivent être spécifiques, ne supposez donc rien de la valeur RID réelle; veuillez consulter ce document pour déterminer le ou les RID dont vous avez besoin pour une plate-forme donnée
16
Nkosi

Sous .NET Core 2.0 , il suffit de construire pour les cibles suivantes:

  • linux-x64, bras linux
  • win-x64, win-x86
  • osx-x64

Voir https://blogs.msdn.Microsoft.com/dotnet/2017/08/14/announcing-net-core-2-0/

4
John Rusk - MSFT