Référencez une bibliothèque .NET Core dans un projet .NET 4.6

J’ai peut-être mal compris la signification de “.NET Core Library”, mais lorsque j’essaie d’append une bibliothèque .NET Core dans un assemblage .NET 4.6 à l’aide de Visual Studio 2015, le message d’erreur suivant s’affiche:

Une référence à “…” n’a pas pu être ajoutée.

Ai-je compris quelque chose qui cloche?

C’est ce que j’ai configuré dans project.json de l’assemblage .NET Core.

"frameworks": { "net451": { }, "dotnet5.4": { "dependencies": { "Microsoft.CSharp": "4.0.1-beta-23516", "System.Collections": "4.0.11-beta-23516", "System.Linq": "4.0.1-beta-23516", "System.Runtime": "4.0.21-beta-23516", "System.Threading": "4.0.11-beta-23516" } } 

Cela peut maintenant être fait avec .Net Core RC2. Voici comment:

  1. Assurez-vous que le projet.json de vos projets .Net RC2 est configuré pour inclure le framework .net approprié. Par exemple, cette section fait référence à .Net 4.51 qui peut être référencé par n’importe quel framework égal ou supérieur à cette version:

Exemple:

 "frameworks": { "net451": { }, "netstandard1.5": { "dependencies": { "NETStandard.Library": "1.5.0-rc2-24027" }, "imports": [ "portable-net45+wp80+win8+wpa81+dnxcore50", "portable-net451+win8" ] } }, 
  1. Créez un package pour votre application RC2 en tant que package Nuget. Je n’ai pas encore vu comment faire cela depuis Visual Studio, mais vous pouvez le faire depuis la ligne de commande avec:

    dotnet pack -oe:\packages

Si vous souhaitez le mettre à jour à chaque construction, vous pouvez append ce qui suit au fichier project.json qui met automatiquement le paquet à jour dans un répertoire parent.

 "scripts": { "postcomstack": [ "dotnet pack --no-build --configuration Debug -o ..//..//..//packages" ]} 
  1. Ajoutez le package Nuget à votre application .net 4.6. Cela peut être fait de plusieurs manières. Un moyen simple consiste à append l’emplacement dans lequel vous avez enregistré le package en tant que référence source Packaage.

  2. Incrémentez le numéro de version dans le fichier project.json à chaque génération pour vous assurer que vos autres applications voient la mise à jour.

La réponse est montrée dans une présentation

Seulement avec ASP.NET Core RC 2 qui n’est pas encore publié, un support pour le référencement de xproj dans csproj sera ajouté.

Changez votre bibliothèque de classe (et toutes les personnes à votre charge) pour la construire également en 4.6.

Changer la bibliothèque de classes pour construire

Cela va maintenant construire les deux versions de la bibliothèque de classes pour vous.

Dossier de débogage avec les deux versions

Dans votre projet .NET 4.6 (App), ajoutez ensuite une référence directe à la DLL de la bibliothèque de classes trouvée dans le dossier de débogage.

Ajouter une référence directe

Vous pouvez maintenant importer cet espace de noms et construire à partir de celui-ci. Bien que ReSharper (2016.3 EAP 2) semble être confus et marque ces lignes en rouge – c’est un espace vide pour les versions ultérieures .NET.

Si vous ouvrez le fichier de projet d’application (.csproj), vous verrez la référence ajoutée par framework.

entrez la description de l'image ici

NB: Le code de construction dnx462 ne semble pas fonctionner, se plaint de l’absence d’installation du framework .NET, même si le projet dispose d’une application 4.6.2 WPF.

J’ai trouvé une solution très simple qui fonctionne bien, si cela ne vous dérange pas de coder en dur une référence à Debug ou Release. Vous venez d’append manuellement une référence à votre xproj dans le fichier csproj. Voici comment vous le faites:

  1. Assurez-vous que votre csproj utilise au moins un package de nuget. La plupart des projets le font, donc ce n’est pas un problème
  2. Dans Visual Studio, déchargez votre projet csproj.
  3. Dans Visual Studio, cliquez avec le bouton droit sur le fichier csproj et choisissez “Modifier”.
  4. Recherchez la pièce dans le fichier de projet csproj où vous faites référence à un paquet de nugets. Ah … en voici un:

       ..\packages\Microsoft.CodeAnalysis.Common.1.3.0\lib\net45\Microsoft.CodeAnalysis.dll True  
  5. Copiez-le et modifiez-le pour faire référence à la DLL produite par votre projet xproj, comme suit:

       ..\HighFive.Server.Web\bin\Debug\net461\HighFive.Server.Web.dll True  
  6. Enregistrez et fermez le fichier csproj
  7. Recharger le projet
  8. Tout reconstruire
  9. Presto!

Concernant le codage en dur d’une référence de débogage ou de publication: Pour les projets de test unitaire, cela n’est pas un problème car vous exécutez généralement des tests unitaires en mode débogage. Je suis sûr que cela pourrait être encore plus intelligent en utilisant les parameters MSBuild pour éviter le codage en dur, mais je n’avais pas besoin de le faire pour le moment.

Je me suis également heurté à ce problème, mais j’ai trouvé une meilleure solution que celle du paquet encombrant. J’ai trouvé cela sur Stackify. Cet article décrit uniquement la possibilité de disposer d’une solution distincte, mais il est assez facile de n’utiliser qu’une seule solution.

Solution distincte pour les projets .NET

Cette option implique d’avoir deux fichiers de solution avec deux fichiers de projet pour chaque projet utilisant .NET Core et .NET 4.xx. Créez d’abord une nouvelle solution vierge. Créez ensuite une nouvelle “bibliothèque de classes” Windows (ce que vous nommez importe peu à ce stade). Supprimez-le de la solution pour pouvoir modifier le fichier .csproj. Ouvrez le fichier .csproj et remplacez l’élément XML AssemblyName par le nom d’assembly du projet principal .NET. Vous devez maintenant apporter toute autre modification liée au nom. Fermez le fichier .csproj et renommez-le de la même manière que votre fichier .xproj. Copiez-le dans le même dossier que le fichier .xproj.

Maintenant que votre nouveau fichier .csproj est prêt, voici où la magie opère. Créez un fichier appelé ProjectName.project.json et ajoutez-y ce texte (modifiez le cadre .net si nécessaire)

{ "runtimes": { "win": {} }, "frameworks": { "net461": {} }}

Dans la solution .NET 4.xx, rechargez ce fichier .csproj modifié pour pouvoir append vos fichiers source. J’ai trouvé le moyen le plus simple de le faire est d’appuyer sur “Afficher tous les fichiers” et de cliquer sur “Inclure dans le projet” dans le menu contextuel par clic droit pour chaque fichier / dossier. Maintenant, essayez de construire le .csproj et il devrait bien se construire. Si cela ne se construit pas correctement, essayez de recharger le projet ou de redémarrer Visual Studio.

Même solution, mais deux projets

C’est la même chose que la précédente, à quelques différences près. Le nom du fichier .csproj DOIT être différent du nom du fichier .xproj (je viens d’append un suffixe, comme MyProjectName.win.csproj et MyProjectName.win.project.json ). Ceux-ci peuvent être ajoutés à la même solution sans conflit de nom. Vous pouvez même avoir l’élément AssemblyName du fichier .csproj identique au nom de l’assemblage principal .NET, car le dossier de sortie change en fonction de la version .NET.

Dernières pensées

J’ai trouvé cette solution tellement meilleure que l’option de package nu-get. La seule chose mineure à laquelle il faut penser est que toutes les modifications de références, de paquets nu-get ou de nouveaux fichiers doivent être ajoutées aux deux projets; C’est un petit prix à payer pour éviter la terrible option nu-get package, cependant. Permettez-nous de croiser les doigts et d’espérer que l’équipe de SV pourra obtenir les références .xproj dans les fichiers .cspoj au plus vite.

Je sais que je ne devrais pas poster de liens, mais je voudrais donner du crédit là où il est dû. http://stackify.com/using-both-xproj-and-csproj-with-net-core/