web-dev-qa-db-fra.com

Comment créer une bibliothèque de classes .NET Core et la référencer à partir d'un projet .NET 4.6?

Je veux:

  • Créez une bibliothèque de classes qui définit certaines interfaces et classes d'assistance génériques simples. Il s'appuiera sur des collections génériques et IQueryable<T> Mais pas de dépendances tierces (enfin, JetBrains.Annotations).
  • Être capable de référencer cette bibliothèque de classes de partout (en particulier UWP, net46 et ASP.Net Core RC2)
  • Idéalement, utilisez le système project.json tout au long, même si je suis prêt à le sacrifier si besoin est.
  • Publiez la bibliothèque terminée dans un flux NuGet et à partir de là, utilisez-la dans d'autres applications

Lors de la création de mon projet de bibliothèque de classes dans Visual Studio 2015.2, j'ai trouvé le modèle Class Library (.NET Core), qui indique

Un modèle de projet pour créer une bibliothèque de classes en tant que package NuGet pouvant cibler n'importe quelle plate-forme

N'importe quelle plateforme! Brillant ... Mais je ne peux pas le faire fonctionner. Après beaucoup de violon, j'ai actuellement le project.json Suivant (je l'ai probablement complètement cassé maintenant):

{
"title": "My Really Useful Class Library",
"copyright": "Copyright © 2015-16 Tigra Astronomy, all rights reserved",
"description": "Really neat stuff",
"language": "en-GB",
"version": "1.0.0-*",
"dependencies": {
    "JetBrains.Annotations": "10.1.4",
    },
"frameworks": {
    "netstandard1.5": {
        "imports": "dnxcore50",
        "dependencies": {
            "NETStandard.Library": "1.5.0-rc2-24027",
            "System.Linq.Expressions": "4.0.11-rc2-24027"
            }
        }
    "net46": {
        "frameworkAssemblies": {
            "System.Collections": "4.0.*"
            },
        "dependencies": {}
        }
    },
    "buildOptions": {
        "xmlDoc": true
        }
}

La prochaine chose que j'ai faite a été de créer mon projet .NET Framework 4.6 dans la même solution et d'essayer de référencer la bibliothèque de classes. Cela me permet d'ajouter la référence mais j'obtiens des erreurs de construction, des symboles non résolus, R # n'est pas satisfait, etc.

Je suppose que je ne le fais pas correctement (pas de surprise, vraiment, car je tâtonne dans le noir).

J'ai lu quelques documents sur les TFM, les frameworks et les bibliothèques mais rien de tout cela n'a vraiment de sens.

De quoi ai-je vraiment besoin pour mettre dans ma bibliothèque de classes project.json, Afin de pouvoir le référencer à partir de mon application .net framework 4.6, ainsi que des applications UWP et ASP.NET Core RC2? Est-ce vraiment la bonne approche ou ai-je commencé du mauvais pied?

asp.net-corecompatibility.net-coreproject.json
20
Tim Long

À l'heure actuelle, il existe deux façons de créer des projets C #: xproj et csproj. En supposant que nous utilisons project.json pour les deux, cela fonctionne toujours différemment pour les types de projets - pour xproj, le project.json contient tout le nécessaire pour construire le projet; pour csproj, il ne contient que les dépendances de nuget.

Cela dit, certains types de projets, comme UWP, ne peuvent pas être créés avec xproj car ils nécessitent un pipeline de génération plus compliqué que ce que xproj/project.json prend en charge. (BTW, c'était une des principales raisons de revenir à msbuild.)

Il existe également deux façons de créer une bibliothèque de classes basée sur .NET Standard: vous pouvez utiliser xproj avec project.json, comme vous l'avez fait, ou vous pouvez créer une csproj normale Projet "Portable Class Library". Avec VS 2015 Update 3 RC, vous pouvez modifier le PCL pour cibler une version .NET Standard (netstandard1.x au lieu d'un profil PCL, 259, etc.).

Si vous utilisez une bibliothèque de classes basée sur csproj pour cibler netstandard1.x, les choses devraient fonctionner pour vous lorsque vous ajoutez des références de projet. Notez que UWP prend actuellement en charge jusqu'à netstandard1.4 sur la base de map platform . Le défi consiste à utiliser un projet basé sur xproj/project.json à la place. L'une des principales raisons d'utiliser aujourd'hui xproj est d'activer la compilation croisée entre plusieurs cadres cibles. Autrement dit, créez plusieurs sorties à partir de votre projet. C'est différent de la création d'une sortie unique qui peut être référencée à partir de n'importe quel projet compatible. Les deux ont leur utilité, cela dépend de vos besoins.

Si vous décidez de créer une bibliothèque de classes basée sur xproj, il existe une solution de contournement que vous pouvez utiliser pour la référencer à partir d'un projet UWP ou de tout autre type de projet compatible si la boîte de dialogue "Ajouter des références" ne fonctionne pas (ce qu'elle n'est pas comme csproj -> xproj est à peu près cassé). Au lieu d'utiliser la boîte de dialogue, modifiez votre UWP csproj pour pointer vers la sortie du xproj comme ceci:

<Reference Include="System.Reactive.Interfaces">
  <HintPath>..\System.Reactive.Interfaces\bin\$(Configuration)\netstandard1.0\System.Reactive.Interfaces.dll</HintPath>
</Reference>

L'extrait ci-dessus est tiré du lanceur de test Rx.NET UWP ici

Si vous faites cela, vous devrez également ajouter la dépendance de génération de votre projet UWP à votre xproj car MSBuild/Visual Studio ne le saura pas et construira les choses dans le mauvais ordre. Pour ce faire, cliquez avec le bouton droit sur votre projet UWP dans l'Explorateur de solutions, puis sélectionnez "Créer des dépendances -> Dépendances du projet". Dans cette boîte de dialogue, cochez la case correspondant à votre xproj pour vous assurer que VS/MSbuild sait d'abord le créer.

Vous pouvez voir la solution Rx.NET complète ici, qui comprend les références xproj->xproj et les références UWP -> xproj que je mentionne ci-dessus.

33
Oren Novotny

Les nouveaux modèles de projet/.xproj fonctionnent un peu différemment. Les nouvelles bibliothèques de classes (et modèles d'application) produisent des packages nuget, plutôt que des assemblages simples.

Dans ce paquet nuget, toutes les cibles y sont regroupées. Cela étant dit, vous ajoutez le nouveau projet de la même manière que vous ajoutez n'importe quel autre package de nuget: vous placez le nuget dans un flux de nuget, référencez-le dans Visual Studio, puis récupérez-le à partir de là.

Si vous n'avez pas de serveur nuget en cours d'exécution (package Visual Studio Team Services + NuGet, myget, auto-hébergé), vous pouvez également placer les packages dans un dossier (partage local ou réseau) et ajouter ce dossier en tant que source de nuget.

Si c'est "trop" de travail, vous pouvez également créer deux projets dans un dossier: A * .csproj et a * .xproj. Le * .csproj cible le .NET 4.6 Framework et le * .xproj reste comme vous l'avez indiqué ci-dessus et a plusieurs cibles. Avec cette configuration, vous pouvez normalement référencer le projet comme vous l'avez utilisé auparavant (s'ils sont dans la même solution), en ajoutant simplement une référence.

3
Tseng