Autofixture: Prise en charge de CoreCLR

Pas encore, du moins. Qu'est-ce que DNX ?

Haha.. c'est le nouveau framework asp.net multiplateforme. https://github.com/aspnet/DNX

le runtime est "dnx451" au lieu de "net451", etc.

Que signifie « soutenir » dans ce contexte ? Êtes-vous en train de dire qu'il est impossible de tester ASP.NET 5 à partir d'une bibliothèque de test avec une dépendance sur une bibliothèque .NET 4 ?

ASPNET 5 s'exécute sur plusieurs plates-formes. Nous n'écrivons que ASPNET 5 sur la plate-forme dnx pour le moment, il s'agit donc d'un ensemble différent de bibliothèques d'exécution. Notre code n'est actuellement pas compilé pour "net451", donc les bibliothèques ciblent efficacement les plates-formes incompatibles

Mes tests fonctionnent très bien avec ce project.json :

{
"dépendances": {

     "xunit.runner.dnx": "2.1.0-*",
     "xunit":"2.1.0-*",
    "AutoFixture.Xunit2":"3.30-*",
    "NSubstitute": "1.8.0",
    "ManagementWeb": "",
    "Microsoft.AspNet.Mvc": "6.0.0-beta4",
    "AutoFixture": "3.30.4-*",
    "AutoFixture.AutoNSubstitute": "3.30.4-*",
    "Microsoft.Azure.Documents.Client": "0.9.2-preview",
    "WindowsAzure.Storage": "4.4.1-*",
    "DeepEqual": "1.1-*"
},
 "frameworks": {
    "dnx451": { }
},
"commands": {
    "test": "xunit.runner.dnx"
}

}

intéressant. Je vais devoir embêter le gars qui travaille là-dessus pour voir quelle est la différence.
Avez-vous fait quelque chose de spécial pour que cela fonctionne?

Non, pas vraiment. IIRC Autofixture a toujours fonctionné avec aspnet 5 mais dans le passé, j'ai eu des problèmes avec l'extension xUnit. Maintenant que la prise en charge de xUnit 2 pour AF est sortie et que DNX et xUnit fonctionnent bien ensemble, cela fonctionne.

Il semble que l'idée ici soit vraiment "la prise en charge de CoreCLR", pas de DNX. Tout ce qui fonctionne pour le .NET Framework 4.5 fonctionnera pour 4.5 sur DNX. CoreCLR nécessitera probablement un certain effort pour être pris en charge, mais je n'ai aucune idée de combien. La meilleure façon de le savoir est d'essayer de le construire pour CoreCLR et de voir ce qui ne fonctionne pas.

Oui, j'aurais dû être clair. Je voulais dire CoreCLR, pas seulement DNX.

En regardant simplement dans le référentiel coreclr , il m'est difficile de glaner l'état du projet. C'est en avant-première ? Bêta? Publié?

Sans l'avoir essayé du tout, si CoreCLR ressemble à des bibliothèques de classes portables en ce sens que les fonctionnalités prises en charge sont une intersection de fonctionnalités disponibles sur diverses plates-formes, il est peu probable qu'il soit possible de moderniser AutoFixture pour qu'il s'exécute sur CoreCLR sans casser les modifications.

Récemment, @moodmosaic a eu la gentillesse de faire l' analyse pour AtomEventStore (un projet beaucoup plus petit qu'AutoFixture), et ici le résultat était qu'une version PCL était infaisable .

Sans avoir du tout regardé les sources d'AutoFixture, je suis d'accord avec votre évaluation : des changements de rupture sont probables. #if DNX_* directives

CoreCLR est, plus ou moins, en marche depuis Windows Phone 8.

ASP.NET 5 sera RC en novembre, CoreCLR pour Linux et Mac sera également RC en novembre 2015. Aux côtés de CoreFX. Version 1.0 pour tout ce qui est prévu pour le 1T2016.

Cela me surprendrait énormément s'il était possible d'ajouter la prise en charge de CoreCLR sans introduire de changements de rupture, j'ai donc ajouté le jalon _4.0_ à ce problème.

Par curiosité, j'ai exécuté l' API Portability Analyzer sur l'assembly Ploeh.AutoFixture et j'ai obtenu des résultats intéressants :

Attendez avant d'ouvrir le Champagne. Ces 3% approximatifs de symboles non pris en charge, malheureusement, expliquent certains symboles plutôt fondamentaux :

| Type de cible | Membre cible |
| --- | --- |
| System.Console | M:System.Console.get_Out |
| System.Threading.Thread | M:System.Threading.Thread.get_ManagedThreadId |
| System.Threading.Thread | M:System.Threading.Thread.get_CurrentThread |
| System.Reflection.ICustomAttributeProvider | M:System.Reflection.ICustomAttributeProvider.GetCustomAttributes(System.Type,System.Boolean) |
| System.Net.Mail.MailAddress | M:System.Net.Mail.MailAddress.#ctor(System.String) |
| System.SerializableAttribute | M:System.SerializableAttribute.#ctor |
| System.Runtime.Serialization.SerializationInfo | T:System.Runtime.Serialization.SerializationInfo |
| System.Reflection.ParameterInfo | M:System.Reflection.ParameterInfo.IsDefined(System.Type,System.Boolean) |
| System.Type | M:System.Type.get_IsGenericTypeDefinition |
| System.Type | M:System.Type.get_IsEnum |
| System.Type | M:System.Type.get_BaseType |
| System.Type | M:System.Type.get_IsPrimitive |
| System.Type | M:System.Type.get_Assembly |
| System.Type | M:System.Type.get_IsGenericType |
| System.Type | M:System.Type.GetTypeCode(System.Type) |
| System.Type | M:System.Type.get_IsClass |
| System.Type | M:System.Type.get_IsValueType |
| System.Type | M:System.Type.get_IsAbstract |
| System.Reflection.MemberInfo | M:System.Reflection.MemberInfo.get_ReflectedType |
| System.Reflection.PropertyInfo | M:System.Reflection.PropertyInfo.GetSetMethod |
| System.Exception | M:System.Exception.#ctor(System.Runtime.Serialization.SerializationInfo,System.Runtime.Serialization.StreamingContext) |
| System.Reflection.MethodBase | M:System.Reflection.MethodBase.GetCurrentMethod |

Cependant, il existe quelques solutions :

• Remplacez toutes les références aux propriétés dans System.Type par celles correspondantes dans System.TypeInfo , disponibles via la méthode d'extension GetTypeInfo(Type) .
• Supprimez toutes les références à System.SerializableAttribute .
• Supprimez toutes les références à System.Runtime.Serialization.SerializationInfo (probablement uniquement utilisées dans les _constructeurs d'exception_).
• Supprimez toutes les références à System.Net.Mail.MailAddress .
• Supprimez toutes les références à la propriété System.Reflection.MemberInfo.ReflectedType et utilisez l'objet reflété pour obtenir son type.
• Remplacez toutes les références à la propriété System.Reflection.PropertyInfo.GetSetMethod propriété System.Reflection.PropertyInfo.SetMethod .

Ce n'est qu'un premier passage et les choses pourraient changer car CoreCLR est toujours en cours de développement. Au moins, nous avons une idée générale de ce qu'il faudrait pour rendre AutoFixture compatible avec lui.

Wow, merci @ecampidoglio d' avoir effectué cette analyse :+1:

Certains des types incompatibles (par exemple MailAddress ) peuvent être déplacés vers une bibliothèque complémentaire qui ne fonctionne que sur le framework complet. J'avais déjà en tête de retirer certaines fonctionnalités de la bibliothèque _Ploeh.AutoFixture_ pour la version 4 .

L'idée de remplacer PropertyInfo.GetSetMethod par PropertyInfo.SetMethod est bonne. AFAICT, cela ne fonctionnera que sur .NET 4.5+, mais ce n'est pas grave, car la branche _v4_ est déjà sur .NET 4.5.

Je ne sais pas si l'étiquette « Jump In » est appropriée pour ce problème. Habituellement, il est utilisé pour indiquer de petits problèmes isolés de la taille d'une bouchée qui sont assez faciles et conviviaux pour les nouveaux contributeurs. Il semble que ce problème nécessiterait une assez bonne compréhension d'une grande partie de la base de code et de son histoire.

@chaitanyagurrapu , tu as peut-être raison.

La raison pour laquelle j'ai ajouté l'étiquette _jump in_ était que je considère ce travail quelque peu sans rapport avec les détails d'AutoFixture. Oui : des décisions devront être prises sur la manière de traiter diverses incompatibilités, mais il y a aussi beaucoup de travail pour simplement comprendre comment fonctionne l'ensemble de l'infrastructure de code/construction liée à CorCLR, et cette partie n'a aucun rapport avec AutoFixture.

Pour le moment, je n'ai pas ces compétences, donc j'aimerais obtenir de l'aide pour cela. Les décisions qui doivent être prises concernant les problèmes de compatibilité, nous pouvons en discuter ici, ou dans des problèmes Github dédiés.

J'ai commencé à travailler là-dessus. Questions à venir :)

ça me parait bien :+1:

@lbargaoanu Ça a l' gardez-le petit .

J'aimerais déplacer MailAddressGenerator vers un projet différent qui cible le framework complet dans la branche v4, afin que je puisse créer AutoFixture pour .NET Core. Je pourrais également déclarer un type d'espace réservé pour .NET Core, mais j'ai évité la compilation conditionnelle jusqu'à présent. Et il y aura toujours des choses prises en charge uniquement dans le cadre complet.

C'est en travaux . Mais en attendant...

Pour référence future
https://blogs.msdn.microsoft.com/dotnet/2016/02/10/porting-to-net-core/

Belle publication! Couvre-t-il également les bibliothèques ? (J'ai cherché _library_ mais je n'ai pas trouvé grand chose...)

:) C'est tout à propos des bibliothèques, mais cet article et ses liens devraient suffire.

J'aimerais voir AutoFixture travailler également sur CoreCLR et prêt à aider si nécessaire. En regardant les derniers PR de Lucian Bargaoanu (n° 511 et n° 513), il semble que ce problème soit devenu obsolète suite à certaines discussions non résolues.

J'aimerais lancer le bal, mais je ne sais pas quel était le plan global pour cela, et comment traiter certains des détails qui bloquaient les discussions. Il pourrait donc être utile d'en arriver à quelque chose comme ça, avant d'entrer dans tous les détails.

Quelques questions que j'ai vues flotter, ou que j'ai moi-même :

• AutoFixture doit-il être converti en PCL ou utiliser quelque chose comme des projets partagés ?
• quelles plates-formes sont absolument nécessaires ou souhaitées à long terme ? (.NET, CoreCLR, UWP ?)
• les compilations conditionnelles sont-elles indésirables pour un projet comme celui-ci ?

@ploeh Je peux imaginer que vous ne pouvez pas répondre à toutes ces questions, mais peut-être que les principaux contributeurs ont leur mot à dire à ce sujet. @lbargaoanu Avez-vous peut-être des commentaires à ce sujet ? Merci!

Je vois que j'ai oublié de répondre à ce fil; veuillez accepter mes excuses :flushed:

Tout travail que nous pouvons faire afin de préparer la base de code AutoFixture pour .NET Core est le bienvenu, tant qu'il ne dégrade pas la base de code ou n'introduit pas de modifications importantes.

Des changements de rupture sont toujours possibles, mais ils devraient aller dans la branche _v4_.

Dans tous les cas, cependant, j'aurai besoin d'une bonne justification pour tout changement qui semble injustifié tel quel. Bien que je ne puisse pas dire que je suis de près la situation de .NET Core, il semble qu'il y ait encore beaucoup de thrashing, et je ne souhaite pas introduire de changements spéculatifs tant que la cible est toujours en mouvement.

Je ne serais pas surpris si la compilation conditionnelle devenait nécessaire, et je ne suis pas contre tant que nous pouvons la garder saine. Si je peux toujours exécuter le script de génération afin de générer tout ce qui doit être publié, tout ira probablement bien. Je dois admettre, cependant, que je n'ai pas beaucoup d'expérience dans ce domaine.

Je ne sais pas non plus quelles plateformes sont recherchées. Essentiellement, si un membre de la communauté nous envoie des demandes d'extraction qui semblent être maintenables et qui étendent la portée d'AutoFixture, nous envisagerons de les accepter.

AFAICT, nous aurions besoin de cibler netstandard1.X qui est l'ensemble d'API qui s'exécuteraient sur n'importe quelle plate-forme qui les implémente (y compris netcore cross platform et net framework sur Windows uniquement).

Voir https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md

En général, les nombres les plus élevés ont plus d'API, mais moins de plates-formes prises en charge. Nous devrions probablement commencer (continuer) cette discussion en comprenant quel X nous devrions cibler dans netstandard1.X .

Le premier paragraphe de ce document me fait un peu peur :

Nous partageons les premiers plans pour l'avenir de la création de bibliothèques de classes .NET.
-- https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md

@moodmosaic cela me fait peur aussi, mais le fait est que le concept général de choix des API que nous ciblerions serait essentiellement nécessaire de toute façon. netstandard leur donne juste un nom bien connu et des sous-ensembles convenus, et un moyen plus simple de les décrire. Cela suppose que nous voulions être portables en premier lieu.

Par exemple, si nous avons besoin d'API de réflexion pour AutoFixture, la liste des cibles que nous pourrions éventuellement avoir est réduite. Si nous avons besoin de collectes simultanées, la même chose est vraie. Ces plates-formes existent déjà (net framework complet, Windows phone, etc.), donc je pense que ce n'est pas quelque chose qui peut changer si nous discutons des API dont nous avons besoin.

Je pourrais [re] lancer la conversation... (avertissement : j'apprends encore ce genre de choses aussi)

Je commence par le plus bas ( netstandard1.0 ) qui est déjà implémenté sur le plus grand nombre de plates-formes, et je cherche les raisons pour lesquelles nous ne pouvons pas (ou ne voulons pas) nous engager sur cette plate-forme.

D'après ce que j'ai compris, l'ensemble d'API netstandard1.0 est assez ancien et restrictif. Il n'a pas des choses comme :

• System.Linq.Parallel (à partir de netstandard1.1 )
• System.Console (à partir de netstandard1.3 )
• System.Collections.Concurrent (à partir de netstandard1.1 )
• System.ComponentModel.Annotations (à partir de netstandard1.1 )
• System.Collections.Specialized (à partir de netstandard1.3 )

Cela m'amène à penser qu'il n'est pas pratique pour AutoFixture de cibler netstandard1.0 .

Je me demande si attendre l'analyseur mentionné par @ecampidoglio ici est une meilleure stratégie.

Edit : voici le référentiel d'outils d'analyse de http://dotnetstatus.azurewebsites.net

Désolé pour trop de spam de commentaires, j'arrête maintenant :)

Pour info, j'ai exécuté le dernier analyseur de portabilité sur un Ploeh.AutoFixture.dll construit localement à partir de la v4 4a7d415 et le résumé est le suivant :

Voici quelques changements qu'il recommande actuellement :

La sortie complète est ici .

@ploeh De nombreux composants largement utilisés d'Asp.Net Core nécessitent au minimum netstandard1.3 . Les exemples incluent EntityFrameworkCore (utilise 1.3) et Mvc (utilise 1.6).

Si Autofixture utilisait l'un ou l'autre comme base de référence, je pense que ce serait un bon endroit.

Des délais pour savoir quand le support .Net Core pourrait être disponible ?

J'ai réussi à créer un build sur .NET Core basé sur la branche v4. Je n'ai pas essayé de construire des projets de test cependant. Consultez cette branche si vous souhaitez créer un package.

FWIW, voici la comparaison entre AutoFixture/AutoFixture v4 et uhaciogullari/AutoFixture net-core . Ça s'annonce bien

Eh bien, ce n'est pas si simple vraiment. L'existence de project.json provoque une erreur lors de la création de projets csproj réguliers en ce moment. Nous pourrions migrer tous les projets au format project.json mais je ne sais pas si c'est une bonne idée pour les autres projets. Je ne les ai pas vérifiés en détail, mais je soupçonne qu'il s'agit de plugins pour d'autres frameworks de test. Aucune idée s'ils prennent également en charge .NET Core.

Une autre chose est que Microsoft a annoncé qu'ils abandonneraient bientôt project.json et qu'ils retourneraient à csproj. Ils promettent une migration facile mais voulez-vous prendre votre temps pour utiliser ce format temporaire ? Cela ne tient qu'à toi. Je pourrais pousser un paquet depuis ma branche actuelle, mais la v4 semble être un travail en cours.

Il existe un moyen de construire sans les erreurs : #712

J'ai en fait essayé de construire à partir de votre branche mais cela ne génère pas de dll. Il manque probablement une certaine configuration mais la création d'un dossier supplémentaire dans chaque projet ne m'a pas plu d'un point de vue esthétique.

Y a-t-il une mise à jour à ce sujet ?

Je pense qu'il était prudent d'attendre que l'outillage de base .net atteigne le statut RTM. L'outillage csproj mis à jour ne sera pas porté sur VS2015 et ne sera donc disponible que dans VS2017. Voir https://twitter.com/TheCodeJunkie/status/822048014172880900

https://blogs.msdn.microsoft.com/dotnet/2017/03/07/announcing-net-core-tools-1-0/

@hoetz, vous pouvez toujours installer l'édition communautaire vs2017.

Y a-t-il un plan pour examiner cette question ?

Cela fait vraiment mal d'écrire des tests pour les assemblages standard .NET sans AitoFixture...

Salut à tous, cela nécessite que quelqu'un de la communauté intervienne et contribue. C'est évidemment difficile en ce moment car les problèmes de modèle de gouvernance n'ont pas encore été résolus (#703). Quelqu'un doit également intervenir sur ce front.

Je joue avec le problème. Pour le moment, je me concentre uniquement sur Src\AutoFixture.sln.

Ma stratégie consiste à convertir Src\AutoFixture\AutoFixture.csproj au nouveau format de projet (VS 2017) afin qu'il puisse prendre en charge à la fois .NET Framework et .NET Standard.

J'ai exécuté le test de portabilité .NET et la meilleure cible devrait être .NET Standard 1.5 (voir fichier joint).

Pour commencer, je ne convertirai pas les projets de test, même si je suppose que nous pourrions vouloir exécuter le test également dans le runtime .NET Core à l'avenir.

AutoFixtureNetPortabilityTest.zip

Hé @Kralizek - Juste pour netstandard1.3 plus dans #712

@Kralizek mon erreur, on dirait que j'ai commencé à planifier pour netstandard1.3 mais que j'ai en fait fini avec netstandard1.5 👍

Presque là. Les tests sont tous verts dans .NET Framework. La construction est toute rouge dans .NET Standard. :RÉ

Je n'ai rencontré que ces catégories de problèmes :

Générateur pas nécessaire
Un seul cas, MailAddressGenerator , car System.Net.Mail.MailAddress n'est pas disponible dans .NET Standard. Solution : le fichier entier a été "supprimé" par #if NET40 ... #endif

Sérialisation
SerializableAttribute, SerializationInfo et StreamingContext n'existent pas dans .NET Standard. De plus, Exception n'a pas le constructeur qui prend ces deux types. En utilisant la directive du compilateur, j'ai supprimé l'attribut et ce constructeur de toutes les exceptions. Surtout supprimer l'attribut n'est pas vraiment joli.

Utilisation de Reflection pour obtenir des informations sur un type
Dans .NET Standard, Type est beaucoup plus pauvre. Tout est délégué à un objet TypeInfo qui contient toutes les propriétés utilisées. Le problème est que .NET Framework utilise toujours l'ancienne classe Type.
Solution:
J'ai créé une méthode d'extension qui transmet le même objet Type public static Type GetTypeInfo(this Type type) => type; et rendu cette méthode d'extension disponible uniquement dans .NET Framework via la directive du compilateur. Cette astuce a résolu de nombreuses incompatibilités en laissant les fichiers intacts. Remarque : la méthode d'extension est marquée comme internal .

Utilisation de la réflexion pour obtenir l'assemblage actuel
Ok, celui-ci a été difficile car je ne connais pas parfaitement la mise en page du projet. J'ai utilisé ReSharper pour vérifier rapidement la hiérarchie des classes, mais vous devriez vérifier.
Le fichier est TerminatingWithPathSpecimenBuilder et la ligne est var thisAssembly = MethodBase.GetCurrentMethod().DeclaringType.Assembly; . Il semble que vous recherchiez l'assembly dans lequel nous nous trouvons. Étant donné que cette classe n'a pas d'héritiers, il est prudent de supposer que typeof(TerminatingWithPathSpecimenBuilder).DeclaringType[.GetTypeInfo()].Assembly renvoie le même résultat , mais encore une fois, je peux me tromper. (J'ai mis la fausse méthode d'extension entre parenthèses). Si mon hypothèse est correcte, je suggérerais de marquer cette classe comme sealed pour éviter le risque qu'elle soit héritée et cassée.

Quoi qu'il en soit, permettez-moi de vous présenter le nouveau fichier de projet.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFrameworks>net40;netstandard1.5</TargetFrameworks>
    <GenerateAssemblyConfigurationAttribute>false</GenerateAssemblyConfigurationAttribute>
    <GenerateAssemblyCompanyAttribute>false</GenerateAssemblyCompanyAttribute>
    <GenerateAssemblyProductAttribute>false</GenerateAssemblyProductAttribute>
    <GenerateAssemblyVersionAttribute>false</GenerateAssemblyVersionAttribute>
    <GenerateAssemblyFileVersionAttribute>false</GenerateAssemblyFileVersionAttribute>
    <GenerateAssemblyTitleAttribute>false</GenerateAssemblyTitleAttribute>
    <GenerateAssemblyDescriptionAttribute>false</GenerateAssemblyDescriptionAttribute>
  </PropertyGroup>
  <ItemGroup Condition=" '$(TargetFramework)' == 'net40' ">
    <Reference Include="System" />
    <Reference Include="System.Core" />
    <Reference Include="Microsoft.CSharp" />
    <Reference Include="System.ComponentModel.DataAnnotations" />
  </ItemGroup>
  <ItemGroup Condition=" '$(TargetFramework)' == 'netstandard1.5' ">
    <PackageReference Include="System.ComponentModel.Annotations" Version="4.1.0" />
  </ItemGroup>
</Project>

oui, c'est tout le fichier du projet.

@Kralizek avez-vous remarqué que nous avons l'intention de cibler >= net45 dans la branche v4 ?

@adamchester nope ... Cela ne devrait pas avoir beaucoup d'importance mais je vais changer le framework cible. Merci pour l'information! ??

Au fait, j'ai découvert que System.Threading.Thread est disponible sous forme de package .

Cela a débloqué un tout nouveau niveau d'erreurs de compilation... sympa :P

.NET Standard 2.0 Devrait ajouter beaucoup d'API, cela vaut peut-être la peine d'attendre ?

Non ce n'est pas. .NET Standard 2.0 est attendu pour le troisième trimestre 2017. Nous sommes à un engagement de prendre en charge .NET Standard 1.5, pourquoi devrions-nous attendre 2.0 ? Car générer des messages électroniques sur un runtime ne le supportera jamais ?

De plus, 2.0 sera principalement une cale du framework 4.6 avec de nombreuses NotSupportedException lancées tout autour.

@Kralizek Assez bien. J'aimerais bien sûr que l'autofixer soit publié plus rapidement, c'était donc une question plus générale.

FWIW, je suis le contributeur qui a ajouté la prise en charge du générateur d'adresses e-mail, et même si c'est bien qu'AutoFixture ait une prise en charge prête à l'emploi, ce n'est en aucun cas un aspect vital d'AutoFixture et cela en vaut la peine. attends-le.

Avoir AutoFixture sur la norme .NET la plus basse possible devrait avoir la priorité, à mon humble avis. Continuez votre bon travail, et si vous cherchez de l'aide ou du soutien pour le tester, alors je peux certainement intervenir.

@Kralizek, les éléments TypeInfo sont également présents dans .NET 4.5, donc cela aiderait.

A été mordu par l'erreur "Package AutoFixture 3.50.5 n'est pas compatible avec netcoreapp1.1 (.NETCoreApp,Version=v1.1)" aujourd'hui lorsque j'ai commencé à ajouter des tests à un certain nombre de projets .NET Core.

Je demande un type de réponse "état de l'autofixation pour .net core" qui indique quand ce package nuget extrêmement utile sera disponible pour cette plate-forme (et .net core 2.0 est déjà rtm et en attente de publication ..) .

Qu'est-ce qui le retient ? (Merci d'avance)

Nous y travaillons actuellement et vous pouvez suivre les progrès dans #773. Remarquez que ce PR concerne le projet AutoFixture lui-même. Nous avons 9 autres projets qui devraient être migrés, mais cela ne devrait être fait qu'une fois que nous aurons fini de travailler sur celui-ci.

La prise en charge de .NET Core sera publiée en tant que v4, vous pouvez trouver toute la portée ici . Je m'attendrais à quelques mois avant que tout soit prêt.

En attendant, nous travaillons également sur le flux Dev NuGet (#762), vous pourrez donc participer aux premiers tests de produits 😉

@zvirja merci pour la mise à jour détaillée. Je suis sûr que cela sera également utile pour d'autres développeurs. Je serais heureux de participer aux premiers tests de produits.

@zvirja donc juste pour clarifier - l'approche actuelle (temporaire) pour écrire des tests unitaires sur des applications/bibliothèques .NET Core utilise AutoFixture dans, par exemple, des projets de test .NET 4.7 et migre le(s) projet(s) de test vers .NET Core ultérieurement ?

Est-ce la solution de contournement suggérée pour le moment? (tant que l'application que j'écris est autorisée à être entièrement .NET Core, ce n'est en fait pas un gros problème d'écrire les tests dans un environnement .NET 4.7 normal).

@andersborum Je n'ai jamais pensé à la solution de contournement temporaire. Je ne suis pas sûr que toutes les API que nous utilisons dans la v3 (packages, publiés sur NuGet) soient conformes à .Net Standard 2.0 (pour utiliser une nouvelle fonctionnalité de .NET Standard).

Faites-nous savoir si vous avez trouvé un moyen de combiner à la fois v3 et .Net Core, afin que nous puissions le conseiller à d'autres personnes 😉

Juste pour informer tout le monde - Le support .Net Standard pour AutoFixture PR (#773) a été fusionné dans la branche v4 . Vous pouvez consommer le forfait de notre flux privé .

Remarquez que seule la bibliothèque AutoFixture a été migrée. D'autres bibliothèques de colle suivront plus tard.

Est-il possible de déplacer la v4 vers nuget.org, même la version alpha ? Jusqu'à présent, je n'ai rien trouvé de comparable à la fixation automatique qui prend en charge .netstandard.
La date de sortie de la v4 est-elle déjà décidée ?

@RomanKernSW Pas pour le moment - nous n'avons pas encore migré la moitié des projets (comme le support xUnit, NUnit, NSubstitute), il est donc trop tôt. Nous avons également un plan pour changer l'espace de noms , donc je préférerais le faire _avant_ de publier quelque chose en public car ce serait une rupture majeure entre les versions. D'un autre côté, je veux changer l'espace de noms le plus tard possible, car nous fusionnons constamment master en v4 et ce sera un enfer de le faire après le changement.

Avez-vous des problèmes avec le flux privé ? Vous pouvez ajouter le flux via NuGet.config si cela est absolument nécessaire.

hm, je dois vérifier s'il est possible d'utiliser nuget.config pour la restauration de nuget (.Net Core 2 - aperçu de la tâche dans VSO). À l'heure actuelle, nous avons un flux privé (VSO) avec nuget.org sans aucun fichier nuget.config. Besoin de temps pour tester ça...

.Net Standard 2.0 a un mode de compatibilité pour .Net Framework NuGets.
J'ai écrit des tests .Net Core avec AutoFixture 3.50.x et aucun problème donc
loin.

@roarwrecker Génial, merci pour le partage ! Cela signifie que nous avons un plus grand tampon de temps jusqu'à ce que nous déployions le support officiel de NuGet :wink:

@roarwrecker merci... ce n'était pas le problème sur .netstandard 1.6. Je pourrais installer le nuget, mais il ne compile jamais sans erreur

Hé les gars, je ne sais pas où en est le travail .NetCore, mais est-il possible d'obtenir une version alpha sur NuGet ?

@selmendorfFrontline Copier la réponse d'ici :

La publication de la version préliminaire sur NuGet est une question un peu douloureuse pour moi. Alors que nous avons commencé à prendre en charge .NET Core pour la plupart des projets , nous prévoyons de modifier l'espace de noms par défaut . Ce serait un énorme changement pour nos clients et tout le code client s'arrêterait de se compiler. C'est à ce moment que la confusion apparaît :

• si nous publions alpha avec l'espace de noms existant et modifions l'espace de noms entre alpha et RTM, cela confondra nos clients car ils ont déjà vu la v4 avec l'espace de noms existant. Je veux que nos clients sentent que la v4 a toujours été publiée avec un nouvel espace de noms lorsque le modèle de gouvernance a été modifié.
• si nous publions alpha avec un espace de noms modifié, nous ne pourrons plus fusionner master en branche v4 sans douleur. Actuellement, nous nous engageons sur les deux branches, c'est pourquoi j'aimerais reporter le changement d'espace de noms à la fin. Un autre point est que notre documentation n'est pas encore prête, donc les gens pourraient simplement ne pas comprendre pourquoi toutes les importations d'espaces de noms ne sont pas valides et qu'ils doivent simplement exécuter un remplacement de texte. Cela les rendra effrayants et l'expérience ne sera pas aussi fluide que je le souhaite.

La meilleure façon de résoudre cette situation serait de ne pas publier alpha et de ne publier que le RTM. Malheureusement, je ne peux pas vous fournir d'ETA précis car cela dépend de mes capacités (je travaille sur ce projet pendant mon temps libre) et de la disponibilité des autres contributeurs (mes PR doivent être revus 😉). Dans ma tête j'imagine la sortie dans un mois ou deux et j'espère que ça arrivera dans cette fourchette. Ce projet était mort pendant environ 9 mois en raison d'un changement de modèle de gouvernance - c'est la principale raison d'un tel retard dans l'assistance.

Veuillez utiliser le package du flux de prévisualisation en attendant. Vous pouvez régler votre Nuget.config comme cela a été mentionné ci-dessus, cela devrait donc poser problème.

Je vais clore ce problème après la fusion du #857. Notre dernier tableau de compatibilité .NET serait le suivant :

| Produit | .NET Framework | Norme .NET |
| ------------------ | ------------------------ | ------------------------ |
| Fixation automatique | :heavy_check_mark: 4.5.2 | :heavy_check_mark: 1.5 |
| AutoFixture.xUnit | :heavy_check_mark: 4.5.2 | :heavy_minus_sign: |
| Fixation automatique.xUnit2 | :heavy_check_mark: 4.5.2 | :heavy_check_mark: 1.5 |
| Fixation automatique.NUnit2 | :heavy_check_mark: 4.5.2 | :heavy_minus_sign: |
| Fixation automatique.NUnit3 | :heavy_check_mark: 4.5.2 | :heavy_check_mark: 1.5 |
| AutoFakeItEasy | :heavy_check_mark: 4.5.2 | :heavy_check_mark: 1.6 |
| AutoFoq | :heavy_check_mark: 4.5.2 | :heavy_minus_sign: |
| AutoMoq | :heavy_check_mark: 4.5.2 | :heavy_check_mark: 1.5 |
| Substitut automatique | :heavy_check_mark: 4.5.2 | :heavy_check_mark: 1.5 |
| AutoRhinoMock | :heavy_check_mark: 4.5.2 | :heavy_minus_sign: |
| Expressions idiomatiques | :heavy_check_mark: 4.5.2 | :heavy_check_mark: 2.0 |
| Idiomes.FsCheck | :heavy_check_mark: 4.5.2 | :heavy_minus_sign: |
| Comparaison sémantique | :heavy_check_mark: 4.5.2 | :heavy_check_mark: 1.5 |

Toutes les bibliothèques non prises en charge, à l'exception de Idioms.FsCheck ne peuvent pas être mises à jour car leurs dépendances ne prennent pas en charge .Net Standard et il est peu probable qu'elles le fassent (la plupart d'entre elles sont obsolètes). J'ai essayé de porter Idioms.FsCheck pour prendre en charge à la fois .NET 452 et .NET Standard 2.0 (comme c'est techniquement possible), mais je n'ai pas réussi à le faire fonctionner. Il semble que le SDK F# soit encore assez difficile et que nous devions attendre les nouvelles versions. La compilation et le chargement du projet échouent simplement après avoir défini le nœud TargetFrameworks .

À moins que quelqu'un n'ait une autre vision, je vais suivre ce plan 😃Je sens aussi à quel point nous sommes proches de la sortie et à quel point il y a du retard 😊

Allez! Allez! Allez!

J'ai essayé de porter Idioms.FsCheck pour prendre en charge à la fois .NET 452 et .NET Standard 2.0

Avez-vous essayé de passer à une version plus récente de F# sur celle-ci ? IIRC, c'est sur F# 3.1 et cela pourrait être le cas.

Excellent travail @zvirja. Pensez-vous que nous pouvons sortir la v4 ? Plus nous nous rapprochons, plus je me sens excité :)

J'aimerais pouvoir t'offrir une bière :)

Avez-vous essayé de passer à une version plus récente de F# sur celle-ci ? IIRC, c'est sur F# 3.1 et cela pourrait être le cas.

@moodmosaic Oui. Si vous vérifiez FsCheck 2.9.0 vous constaterez que cela dépend de FSharp.Core (>= 4.1.17) , donc je n'avais pas d'autre choix 😅 Le problème vient plutôt du SDK. Si je commence à cibler les deux frameworks simultanément, je ne parviens pas à charger la solution dans VS
Projet:

<PropertyGroup>
  <TargetFrameworks>net452;netstandard2.0</TargetFrameworks>
  .....
</PropertyGroup>

<ItemGroup>
  <PackageReference Include="FsCheck" Version="[0.9.2,3.0.0)" Condition=" '$(TargetFramework)'=='net452' " />
  <PackageReference Include="FSharp.Core" Version="3.1.2" Condition=" '$(TargetFramework)'=='net452' " />

  <PackageReference Include="FsCheck" Version="[2.9.0,3.0.0)" Condition=" '$(TargetFramework)'=='netstandard2.0' " />
  <PackageReference Include="FSharp.Core" Version="4.1.17" Condition=" '$(TargetFramework)'=='netstandard2.0' " />

  <PackageReference Include="FSharp.NET.Sdk" Version="1.0.*" PrivateAssets="All" />
</ItemGroup>

Essayer d'ouvrir dans VS :

Tout va bien avec le projet - le problème se situe quelque part dans le SDK F#. C'est pourquoi j'aimerais reporter la prise en charge de .NET Core par FsCheck jusqu'à des temps meilleurs.

@Kralizek S'il quelques réponses ci-dessus .

Je viens de vérifier dans VS 2017.4 et je ne peux toujours pas cibler plusieurs frameworks pour le projet F#. Par conséquent, je ferme ce problème pour le moment car nous prenons en charge .NET Core pour tous les autres projets.

JFYI : J'ai publié la v4 rc1 sur NuGet, vous pouvez donc consommer et tester sans avoir besoin de jouer avec un flux personnalisé.