Référencement d'un projet de bibliothèque de classes .NET Framework 4.5 à partir de l'application CoCoa

Y a-t-il des risques à référencer un projet de bibliothèque de classes .NET Framework 4.5 à partir d'une application Mac OSX CoCoa?Référencement d'un projet de bibliothèque de classes .NET Framework 4.5 à partir de l'application CoCoa

J'ai entendu dire qu'il est recommandé d'utiliser .NET Standard pour le code de bibliothèque partagée. Cependant, il semble y avoir beaucoup plus d'API disponibles dans .NET Framework 4.5 qui ne sont pas disponibles dans .NET Standard 1.1 (c'est-à-dire System.IO.Directory.Create). Je suis en train d'écrire une version OSx d'une application Windows WPF. J'aimerais idéalement partager le code de logique métier dans une bibliothèque partagée opposée à la duplication.

Le projet Windows doit rester sur .NET 4.5, donc si aller vers .NET Standard route - il devrait être à 1.1, cependant beaucoup de bibliothèques sont incompatibles.

Voir: https://docs.microsoft.com/en-us/dotnet/standard/net-standard

me semble être en mesure d'ajouter une référence à un .NET Framework 4.5 Bibliothèque de classes et consomment la plupart des bibliothèques, et je me demandais quels sont les risques ici (le cas échéant).

Source

2017-10-09 user3689167

Est-ce un projet Xamarin.Mac? N'utilisez pas un terme que personne d'autre n'utilise. –

Y at-il un inconvénient à référencer un projet de bibliothèque de classes .NET Framework 4.5 à partir d'une application Mac OSX CoCoa?

Étant donné que .NET Framework 4.5 ne fonctionnera pas sous Mac OSX, je dirais que oui, il y a un problème. Le projet Windows doit rester sur .NET 4.5, donc si aller vers .NET Standard route - il devrait être à 1.1, mais beaucoup de bibliothèques sont incompatibles. Si ces «bibliothèques incompatibles» sont des projets Open Source de tierce partie, la meilleure chose à faire est de les aider à progresser en proposant de contribuer à la mise à niveau vers .NET Standard. Notez qu'il manque plusieurs API à .NET Standard 1.1 et que de nombreuses bibliothèques doivent ajouter d'autres packages NuGet pour ajouter les API manquantes (voir https://apisof.net/) ou cibler une version supérieure à 1.1 afin d'être compatible avec .NET Standard . Dans ce dernier cas, vous pouvez cibler plusieurs fois la bibliothèque sur .NET Framework 4.5 et également la version minimale de .NET Standard que vous pouvez utiliser. Si vous placez les deux bibliothèques dans le même paquet NuGet, c'est presque transparent.

Source

2017-10-09 22:16:04 NightOwl888

Intéressant - donc je devrais certainement utiliser. NET standard comme ma bibliothèque partagée .... La chose étrange est que le référencement .NET Framework 4.5 semblait réellement fonctionner (au moins sur mon mac) - était même capable de créer un répertoire en utilisant le système .IO.Directory.Create, j'imagine que la plupart de ces API sont instables alors? – user3689167

Je ne suis pas sûr de la configuration de votre configuration, mais .NET Framework n'est pas conçu pour fonctionner sur [n'importe quelle plate-forme sauf Windows] (https://docs.microsoft.com/en-us/dotnet/framework/get-started/system-requirements # supported-server-operating-systems) (et Linux si vous utilisez [Mono] (http://www.mono-project.com/docs/about-mono/compatibility/)). .NET Standard ajoute [true cross-platform support] (https://github.com/dotnet/core/blob/master/release-notes/1.0/1.0-supported-os.md). Je considérerais votre cas spécifique comme un coup de chance et supposerais que cela ne marchera pas sur n'importe quelle vieille boîte OSX à moins que vous n'utilisiez .NET Standard. – NightOwl888

Référencement d'un projet de bibliothèque de classes .NET Framework 4.5 à partir de l'application CoCoa

Répondre

Questions connexes