Autofixture: Unterstützung für CoreCLR

Zumindest noch nicht. Was ist DNX?

Haha.. es ist das neue plattformübergreifende asp.net-Framework. https://github.com/aspnet/DNX

die Laufzeit ist "dnx451" statt "net451" usw.

Was bedeutet in diesem Zusammenhang „Unterstützung für“? Wollen Sie damit sagen, dass es unmöglich ist, ASP.NET 5 von einer Testbibliothek mit einer Abhängigkeit von einer .NET 4-Bibliothek zu testen?

ASPNET 5 läuft auf mehreren Plattformen. Wir schreiben derzeit nur ASPNET 5 auf der dnx-Plattform, es handelt sich also um einen anderen Satz von Laufzeitbibliotheken. Unser Code ist derzeit nicht für "net451" kompiliert, sodass die Bibliotheken effektiv auf inkompatible Plattformen abzielen

Meine Tests laufen mit dieser project.json einwandfrei:

{
"Abhängigkeiten": {

     "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"
}

}

interessant. Ich muss den Typen, der daran arbeitet, verwanzen, um zu sehen, was der Unterschied ist.
Hast du etwas Besonderes gemacht, damit es funktioniert?

Nicht wirklich, nein. IIRC Autofixture hat immer mit aspnet 5 funktioniert, aber in der Vergangenheit hatte ich Probleme mit der xUnit-Erweiterung. Nachdem die xUnit 2-Unterstützung für AF jetzt draußen ist und DNX & xUnit gut zusammenspielen, funktioniert es einfach.

Die Idee scheint hier wirklich "Unterstützung für CoreCLR" zu sein, nicht DNX. Alles, was für .NET Framework 4.5 funktioniert, funktioniert auch für 4.5 auf DNX. CoreCLR wird wahrscheinlich einige Anstrengungen erfordern, um zu unterstützen, aber ich habe keine Ahnung, wie viel. Der beste Weg, dies herauszufinden, besteht darin, es für CoreCLR zu erstellen und zu sehen, was kaputt geht.

Ja, ich hätte klar sein sollen. Ich meinte CoreCLR, nicht nur DNX.

Wenn ich nur im

Ohne es überhaupt ausprobiert zu haben, ist es ziemlich unwahrscheinlich, dass es möglich wäre, AutoFixture so nachzurüsten, dass es auf CoreCLR läuft, ohne dass Änderungen vorgenommen werden, wenn CoreCLR insofern wie Portable Class Libraries ist, als die unterstützten Funktionen eine Kreuzung der verfügbaren Funktionen auf verschiedenen Plattformen sind.

Vor kurzem war @moodmosaic so freundlich, die Analyse für AtomEventStore (ein viel kleineres Projekt als AutoFixture) durchzuführen, und hier war das Ergebnis, dass eine PCL-Version nicht durchführbar war .

Ohne mir AutoFixture-Quellen angeschaut zu haben, stimme ich deiner Einschätzung zu: Breaking Changes sind wahrscheinlich. #if DNX_* -Anweisungen sind erforderlich, wenn Unterstützung im Plan vorgesehen ist.

CoreCLR ist mehr oder weniger in Betrieb seit Windows Phone 8.

ASP.NET 5 wird im November RC sein, CoreCLR für Linux und Mac wird auch im November 2015 RC sein. Neben CoreFX. Release 1.0 für alles, was für 1Q2016 geplant ist.

Es würde mich sehr überraschen, wenn es möglich wäre, Unterstützung für CoreCLR hinzuzufügen, ohne Breaking Changes einzuführen, daher habe ich diesem Thema den Meilenstein _4.0_ hinzugefügt.

Aus Neugier habe ich den API Portability Analyzer auf der Ploeh.AutoFixture Assembly ausgeführt und einige interessante Ergebnisse erhalten:

Warten Sie, bevor Sie den Champagner öffnen. Diese groben 3% der nicht unterstützten Symbole erklären leider einige ziemlich grundlegende:

| Zieltyp | Zielmitglied |
| --- | --- |
| System.Konsole | 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.Typ | M:System.Type.get_IsGenericTypeDefinition |
| System.Typ | M:System.Type.get_IsEnum |
| System.Typ | M:System.Type.get_BaseType |
| System.Typ | M:System.Type.get_IsPrimitive |
| System.Typ | M:System.Type.get_Assembly |
| System.Typ | M:System.Type.get_IsGenericType |
| System.Typ | M:System.Type.GetTypeCode(System.Type) |
| System.Typ | M:System.Type.get_IsClass |
| System.Typ | M:System.Type.get_IsValueType |
| System.Typ | M:System.Type.get_IsAbstract |
| System.Reflection.MemberInfo | M:System.Reflection.MemberInfo.get_ReflectedType |
| System.Reflection.PropertyInfo | M:System.Reflection.PropertyInfo.GetSetMethod |
| System.Ausnahme | M:System.Exception.#ctor(System.Runtime.Serialization.SerializationInfo,System.Runtime.Serialization.StreamingContext) |
| System.Reflection.MethodBase | M:System.Reflection.MethodBase.GetCurrentMethod |

Es gibt jedoch einige Lösungen:

• Ersetzen Sie alle Verweise auf die Eigenschaften in System.Type durch die entsprechenden in System.TypeInfo , die über die Erweiterungsmethode GetTypeInfo(Type) verfügbar sind.
• Entfernen Sie alle Verweise auf System.SerializableAttribute .
• Entfernen Sie alle Verweise auf System.Runtime.Serialization.SerializationInfo (wird wahrscheinlich nur in _Ausnahmekonstruktoren_ verwendet).
• Entfernen Sie alle Verweise auf System.Net.Mail.MailAddress .
• Entfernen Sie alle Verweise auf die Eigenschaft System.Reflection.MemberInfo.ReflectedType und verwenden Sie das reflektierte Objekt, um seinen Typ zu ermitteln.
• Ersetzen Sie stattdessen alle Verweise auf die Eigenschaft System.Reflection.PropertyInfo.GetSetMethod Eigenschaft System.Reflection.PropertyInfo.SetMethod .

Dies ist nur ein erster Durchgang und die Dinge können sich ändern, da CoreCLR noch entwickelt wird. Zumindest haben wir eine ungefähre Vorstellung davon, was nötig wäre, um AutoFixture damit kompatibel zu machen.

Wow, danke, @ecampidoglio , für die Durchführung dieser Analyse :+1:

Einige der inkompatiblen Typen (zB MailAddress ) können wir in eine Add-On-Bibliothek verschieben, die nur mit dem vollständigen Framework funktioniert. Ich hatte schon daran gedacht, einige Features aus der _Ploeh.AutoFixture_-Bibliothek für Version 4 zu ziehen .

Die Idee, PropertyInfo.GetSetMethod durch PropertyInfo.SetMethod ersetzen, ist gut. AFAICT, es funktioniert nur unter .NET 4.5+, aber das ist in Ordnung, da der _v4_-Zweig bereits unter .NET 4.5 ist.

Ich bin mir nicht sicher, ob das Label "Jump In" für dieses Problem geeignet ist. Normalerweise wird es verwendet, um kleine, isolierte, mundgerechte Probleme anzuzeigen, die relativ einfach und für neue Mitwirkende freundlich sind. Es scheint, dass dieses Problem ein ziemlich gutes Verständnis eines großen Teils der Codebasis und ihrer Geschichte erfordern würde.

@chaitanyagurrapu , vielleicht hast du recht.

Der Grund, warum ich das Label _jump in_ hinzugefügt habe, war, dass ich der Meinung bin, dass diese Arbeit nichts mit AutoFixture-Details zu tun hat. Ja: Es müssen Entscheidungen getroffen werden, wie verschiedene Inkompatibilitäten behoben werden können, aber es ist auch viel Arbeit erforderlich, einfach herauszufinden, wie die gesamte Code-/Build-Infrastruktur in Bezug auf CorCLR funktioniert, und dieser Teil hat nichts mit AutoFixture zu tun.

Im Moment habe ich diese Fähigkeiten nicht, also würde ich gerne Hilfe dabei bekommen. Die Entscheidungen, die in Bezug auf Kompatibilitätsprobleme getroffen werden müssen, können wir hier oder in speziellen Github-Problemen diskutieren.

Ich habe angefangen, daran zu arbeiten. Fragen kommen noch :)

Klingt gut für mich :+1:

@lbargaoanu Klingt gut :+1: Denken Sie daran, wenn möglich, halten Sie es klein .

Ich möchte MailAddressGenerator in ein anderes Projekt verschieben, das auf das vollständige Framework im v4-Zweig abzielt, damit ich AutoFixture für .NET Core erstellen kann. Ich könnte auch einen Platzhaltertyp für .NET Core deklarieren, aber ich habe die bedingte Kompilierung bisher vermieden. Und es wird immer Dinge geben, die nur im vollen Rahmen unterstützt werden.

Es ist in Arbeit . Aber inzwischen...

Für zukünftige Referenzen
https://blogs.msdn.microsoft.com/dotnet/2016/02/10/porting-to-net-core/

Netter Post! Betrifft es auch Bibliotheken? (Ich habe nach _Bibliothek_ gesucht, aber nicht viel gefunden ...)

:) Das ist alles über Bibliotheken, aber dieser Beitrag und seine Links sollten ausreichen.

Ich würde gerne sehen, dass AutoFixture auch an CoreCLR arbeitet und bereit ist, bei Bedarf zu helfen. Wenn man sich die letzten PRs von Lucian Bargaoanu (#511 und #513) ansieht, sieht es so aus, als ob dieses Problem aufgrund einiger ungelöster Diskussionen veraltet ist.

Ich würde gerne den Ball ins Rollen bringen, weiß aber nicht, was der Gesamtplan dafür war und wie ich mit einigen Details umgehen soll, die die Diskussionen blockierten. Es kann also nützlich sein, zu so etwas zu kommen, bevor Sie auf alle Details eingehen.

Einige Fragen, die ich im Umlauf gesehen habe oder die ich selbst habe:

• sollte AutoFixture in eine PCL konvertiert werden oder so etwas wie gemeinsame Projekte verwenden?
• Welche Plattformen werden unbedingt benötigt oder auf Dauer gewollt? (.NET, CoreCLR, UWP?)
• sind bedingte Kompilierungen für ein Projekt wie dieses unerwünscht?

@ploeh Ich kann mir @lbargaoanu Hast du dazu vielleicht etwas Input? Danke!

Wie ich sehe, habe ich vergessen, auf diesen Thread zu antworten; Bitte nehmt meine Entschuldigung an :errötet:

Jede Arbeit, die wir tun können, um die AutoFixture-Codebasis für .NET Core vorzubereiten, ist willkommen, solange sie die Codebasis nicht beeinträchtigt oder grundlegende Änderungen einführt.

Breaking Changes sind immer noch möglich, aber sie müssten in den _v4_-Zweig gehen.

Auf jeden Fall brauche ich jedoch eine gute Begründung für jede Änderung, die so wie sie ist ungerechtfertigt erscheint. Ich kann zwar nicht sagen, dass ich die .NET Core-Situation genau verfolge, aber es scheint immer noch viel Geprügel zu geben, und ich bin nicht daran interessiert, spekulative Änderungen einzuführen, solange sich das Ziel noch bewegt.

Es würde mich nicht wundern, wenn eine bedingte Kompilierung am Ende notwendig wäre, und ich bin nicht dagegen, solange wir es bei Verstand halten können. Wenn ich das Build-Skript immer noch ausführen kann, um zu erstellen, was veröffentlicht werden muss, ist es wahrscheinlich in Ordnung. Ich muss allerdings zugeben, dass ich damit nicht viel Erfahrung habe.

Ich weiß auch nicht, welche Plattformen gesucht werden. Im Wesentlichen, wenn uns jemand aus der Community Pull-Requests sendet, die wartbar aussehen und die Reichweite von AutoFixture erweitern, werden wir in Betracht ziehen, sie zu übernehmen.

AFAICT, wir müssten netstandard1.X ansprechen, das ist der Satz von APIs, der auf jeder Plattform laufen würde, die sie implementiert (einschließlich Netcore Cross Platform und Net Framework nur unter Windows).

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

Im Allgemeinen haben die höheren Zahlen mehr APIs, aber weniger unterstützte Plattformen. Wir sollten diese Diskussion wahrscheinlich beginnen (fortsetzen), indem wir verstehen, welches X wir in netstandard1.X anvisieren sollten.

Der erste Absatz dieses Dokuments macht mir ein bisschen Angst:

Wir teilen erste Pläne für die Zukunft beim Erstellen von .NET-Klassenbibliotheken.
-- https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md

@moodmosaic es macht mir auch Angst, aber die Sache ist, dass das allgemeine Konzept der Auswahl der APIs, die wir anvisieren würden, im Wesentlichen so oder so notwendig wäre. netstandard gibt ihnen nur einen bekannten Namen und vereinbarte Teilmengen und eine einfachere Möglichkeit, sie zu beschreiben. Das setzt voraus, dass wir in erster Linie tragbar sein wollten.

Wenn wir beispielsweise Reflexions-APIs für AutoFixture benötigen, wird die Liste der möglichen Ziele reduziert. Wenn wir gleichzeitige Sammlungen benötigen, gilt das gleiche. Diese Plattformen existieren bereits (Net Framework voll, Windows Phone usw.), daher denke ich, dass sich daran nichts ändern kann, wenn wir diskutieren, welche APIs wir benötigen.

Ich könnte das Gespräch [erneut] beginnen... (Haftungsausschluss: Ich lerne auch noch dieses Zeug)

Ich beginne mit der niedrigsten ( netstandard1.0 ), die bereits auf den meisten Plattformen implementiert ist, und suche nach Gründen, warum wir uns nicht auf diese Plattform festlegen können (oder wollen).

Nach meinem Verständnis ist der netstandard1.0 Satz von APIs ziemlich alt und restriktiv. Es hat keine Dinge wie:

• System.Linq.Parallel (beginnt bei netstandard1.1 )
• System.Console (ab netstandard1.3 )
• System.Collections.Concurrent (beginnt bei netstandard1.1 )
• System.ComponentModel.Annotations (beginnt bei netstandard1.1 )
• System.Collections.Specialized (ab netstandard1.3 )

Dies führt mich zu der Annahme, dass es für AutoFixture nicht praktikabel ist, auf netstandard1.0 abzuzielen.

Ich frage mich, ob es die bessere Strategie ist, auf den hier von @ecampidoglio erwähnten Analysator zu warten.

Bearbeiten: Hier ist das .NET API Portability Analyzer Tools Repo und hier ist die Website http://dotnetstatus.azurewebsites.net

Sorry für zu viel Kommentar-Spam, ich höre jetzt auf :)

Zu Ihrer Information Ich habe den neuesten Portabilitätsanalysator auf einer lokal erstellten Ploeh.AutoFixture.dll von v4 4a7d415 ausgeführt und die Zusammenfassung ist:

Hier sind einige Änderungen, die derzeit empfohlen werden:

Die volle Ausgabe ist hier .

@ploeh Viele weit verbreitete Komponenten von Asp.Net Core erfordern mindestens netstandard1.3 . Beispiele hierfür sind EntityFrameworkCore (verwendet 1.3) und Mvc (verwendet 1.6).

Wenn Autofixture eines davon als Basis verwenden würde, wäre es meiner Meinung nach an einem guten Ort.

Gibt es Zeitpläne, wann .Net Core-Support verfügbar sein könnte?

Ich habe es geschafft, einen Build auf .NET Core basierend auf dem v4-Zweig zu erstellen. Ich habe jedoch nicht versucht, Testprojekte zu erstellen. Sehen Sie sich diesen Zweig an, wenn Sie ein Paket erstellen möchten.

FWIW, hier ist der Vergleich zwischen AutoFixture/AutoFixture v4 und uhaciogullari/AutoFixture net-core . Es sieht gut aus 👍

Nun, es ist wirklich nicht so einfach. Die Existenz von project.json verursacht derzeit einen Fehler beim Erstellen von regulären csproj-Projekten. Wir könnten alle Projekte in das project.json-Format migrieren, aber ich bin mir nicht sicher, ob dies für die anderen Projekte eine gute Idee ist. Ich habe sie nicht im Detail überprüft, aber ich vermute, dass es sich um Plugins für einige andere Testframeworks handelt. Keine Ahnung, ob sie auch .NET Core unterstützen.

Eine andere Sache ist, dass Microsoft angekündigt hat, sich bald von project.json zu entfernen und zu csproj zurückzukehren. Sie versprechen eine einfache Migration, aber möchten Sie sich Zeit nehmen, um dieses temporäre Format zu verwenden? Es liegt alles bei dir. Ich könnte ein Paket aus meinem aktuellen Zweig pushen, aber v4 scheint in Arbeit zu sein.

Es gibt eine Möglichkeit, ohne die Fehler zu erstellen: #712

Ich habe tatsächlich versucht, aus Ihrem Zweig zu erstellen, aber es wird keine DLL generiert. Es fehlt wahrscheinlich eine Konfiguration, aber das Erstellen eines zusätzlichen Ordners in jedem Projekt hat mir ästhetisch nicht gefallen.

Gibt es dazu ein Update?

Ich denke, es war ratsam zu warten, bis das .net-Core-Tooling den RTM-Status erreicht. Das aktualisierte csproj-Tooling wird nicht auf VS2015 portiert und ist daher nur in VS2017 verfügbar. Siehe https://twitter.com/TheCodeJunkie/status/822048014172880900

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

@hoetz Sie können weiterhin die vs2017 Community Edition installieren.

Gibt es einen Plan, sich mit diesem Thema zu befassen?

Es fühlt sich wirklich schlecht an, Tests für .NET-Standardassemblys ohne AitoFixture zu schreiben...

Hallo zusammen, dies erfordert, dass jemand aus der Community eingreift und einen Beitrag leistet. Im Moment ist es offensichtlich schwierig, weil die Probleme mit dem Governance-Modell noch nicht gelöst sind (#703). Auch an dieser Front muss jemand einspringen.

Ich spiele mit dem Problem herum. Im Moment konzentriere ich mich nur auf Src\AutoFixture.sln.

Meine Strategie besteht darin, Src\AutoFixture\AutoFixture.csproj in das neue Projektformat (VS 2017) zu konvertieren, damit es sowohl .NET Framework als auch .NET Standard unterstützen kann.

Ich habe den .NET-Portabilitätstest durchgeführt und das beste Ziel sollte .NET Standard 1.5 sein (siehe angehängte Datei).

Zunächst werde ich die Testprojekte nicht konvertieren, obwohl ich davon ausgehen möchte, dass wir den Test in Zukunft möglicherweise auch in der .NET Core-Runtime ausführen möchten.

AutoFixtureNetPortabilityTest.zip

Hey @Kralizek - Nur zur netstandard1.3 in #712

@Kralizek mein Fehler, es sieht so aus, als hätte ich mit der Planung für netstandard1.3 , bin aber tatsächlich bei netstandard1.5 gelandet 👍

Fast dort. Die Tests sind in .NET Framework alle grün. Der Build ist in .NET Standard ganz rot. :D

Ich habe nur diese Kategorien von Problemen getroffen:

Generator nicht erforderlich
Nur ein Fall, MailAddressGenerator , da System.Net.Mail.MailAddress in .NET Standard nicht verfügbar ist. Lösung: die gesamte Datei wurde von #if NET40 ... #endif . "entfernt"

Serialisierung
SerializableAttribute, SerializationInfo und StreamingContext sind in .NET Standard nicht vorhanden. Außerdem verfügt Exception nicht über den Konstruktor, der diese beiden Typen akzeptiert. Mit der Compiler-Direktive habe ich das Attribut und diesen Konstruktor aus allen Ausnahmen entfernt. Besonders das Entfernen des Attributs ist nicht wirklich schön.

Verwendung von Reflection, um Informationen über einen Typ zu erhalten
In .NET Standard ist Type viel schlechter. Alles wird an ein TypeInfo-Objekt delegiert, das alle verwendeten Eigenschaften enthält. Das Problem ist, dass .NET Framework noch die alte Type-Klasse verwendet.
Lösung:
Ich habe eine Erweiterungsmethode erstellt, die das gleiche Type-Objekt public static Type GetTypeInfo(this Type type) => type; weiterleitet und diese Erweiterungsmethode nur in .NET Framework über die Compilerdirektive verfügbar gemacht hat. Dieser Trick löste viele Inkompatibilitäten und ließ die Dateien unberührt. Hinweis: Die Erweiterungsmethode ist als internal .

Verwendung von Reflection, um die aktuelle Assembly zu erhalten
Ok, dieses war ein schwieriges, weil ich das Projektlayout nicht perfekt kenne. Ich habe ReSharper verwendet, um die Klassenhierarchie schnell zu überprüfen, aber Sie sollten es noch einmal überprüfen.
Die Datei ist TerminatingWithPathSpecimenBuilder und die Zeile ist var thisAssembly = MethodBase.GetCurrentMethod().DeclaringType.Assembly; . Es sieht so aus, als ob Sie nach der Assembly suchen, in der wir uns befinden. Da diese Klasse keine Vererbung hat, kann man davon ausgehen, dass typeof(TerminatingWithPathSpecimenBuilder).DeclaringType[.GetTypeInfo()].Assembly dasselbe Ergebnis zurückgibt, aber auch hier könnte ich mich irren. (Ich habe die gefälschte Erweiterungsmethode in Klammern gesetzt). Wenn meine Annahme richtig ist, würde ich vorschlagen, diese Klasse als sealed zu markieren, um das Risiko zu vermeiden, dass sie vererbt und beschädigt wird.

Wie auch immer, lassen Sie mich Ihnen die neue Projektdatei vorstellen.

<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>

Ja, das ist die gesamte Projektdatei.

@Kralizek ist Ihnen aufgefallen, dass wir beabsichtigen, >= net45 im Zweig v4 anzusprechen ?

@adamchester nein ... Es sollte nicht so wichtig sein, aber ich werde das Zielframework ändern. Danke für die Warnung! 👍

Übrigens, ich habe herausgefunden, dass System.Threading.Thread als Paket erhältlich ist .

Es hat eine ganz neue Ebene von Compilerfehlern freigeschaltet ... schön :P

.NET Standard 2.0 Sollte eine Menge API hinzufügen, lohnt es sich vielleicht zu warten?

Nein, ist es nicht. .NET Standard 2.0 wird im dritten Quartal 2017 erwartet. Wir sind nur noch einen Commit davon entfernt, .NET Standard 1.5 zu unterstützen, warum sollten wir auf 2.0 warten? Für das Generieren von E-Mail-Nachrichten auf einer Laufzeit wird es nie unterstützt?

Außerdem wird 2.0 größtenteils ein Shim von Framework 4.6 sein, wobei viele NotSupportedExceptions herumgeworfen werden.

@Kralizek Fair genug. Ich würde natürlich lieben, dass Autofixter schneller veröffentlicht wird, war also eine allgemeinere Frage.

FWIW, ich bin der Mitwirkende, der die Unterstützung für den E-Mail-Adressgenerator hinzugefügt hat, und obwohl es schön ist, dass AutoFixture dies sofort unterstützt, ist dies keineswegs ein wichtiger Aspekt von AutoFixture und die Mühe lohnt sich warte darauf.

AutoFixture auf dem niedrigstmöglichen .NET-Standard zu haben, sollte IMHO die höchste Priorität haben. Machen Sie weiter so, und wenn Sie Hilfe oder Unterstützung beim Testen suchen, kann ich auf jeden Fall einspringen.

@Kralizek das TypeInfo-Zeug ist auch in .NET 4.5 vorhanden, also würde es helfen.

Wurde heute von dem Fehler "Paket AutoFixture 3.50.5 ist nicht kompatibel mit netcoreapp1.1 (.NETCoreApp,Version=v1.1)" gebissen, als ich damit begann, Tests zu einer Reihe von .NET Core-Projekten hinzuzufügen.

Ich bitte um eine Art von "State of Autofixture for .net Core", die eine Richtung vorgibt, wann dieses äußerst nützliche Nuget-Paket für diese Plattform verfügbar sein wird (und .net Core 2.0 ist bereits rtm und die Veröffentlichung steht aus ..) .

Was hält es zurück? (Danke im Voraus)

Daran arbeiten wir gerade und Sie können den Fortschritt in #773 verfolgen. Beachten Sie, dass es in dieser PR um das Projekt AutoFixture selbst geht. Wir haben noch 9 weitere Projekte, die migriert werden sollten, aber das sollte erst geschehen, wenn wir die Arbeit an diesem abgeschlossen haben.

Die .NET Core-Unterstützung wird als v4 veröffentlicht, den gesamten Umfang finden Sie hier . Ich würde ein paar Monate erwarten, bis alles fertig ist.

In der Zwischenzeit arbeiten wir auch am Dev NuGet-Feed (#762), damit Sie an frühen Produkttests teilnehmen können 😉

@zvirja danke für das ausführliche Update. Ich bin mir sicher, dass es auch für andere Entwickler nützlich sein wird. Gerne nehme ich an frühen Produkttests teil.

@zvirja Also nur zur Klarstellung - der aktuelle (vorübergehende) Ansatz zum Schreiben von AutoFixture in z. B. .NET 4.7 Testprojekten zu verwenden und die Testprojekte zu migrieren. zu .NET Core zu einem späteren Zeitpunkt?

Ist das vorerst die vorgeschlagene Problemumgehung? (Solange die App, die ich schreibe, vollständig .NET Core sein darf, ist es eigentlich kein großes Problem, die Tests in einer normalen .NET 4.7 Umgebung zu schreiben).

@andersborum Ich habe nie über die temporäre

Lassen Sie es uns wissen, wenn Sie einen Weg gefunden haben, sowohl v3 als auch .Net Core zu kombinieren, damit wir das anderen Leuten raten können 😉

Nur um alle zu benachrichtigen - .Net Standard-Unterstützung für AutoFixture PR (#773) wurde in den v4 Zweig zusammengeführt. Sie können das Paket aus unserem privaten Feed konsumieren.

Beachten Sie, dass nur die AutoFixture-Bibliothek migriert wurde. Andere Leimbibliotheken werden später folgen.

Ist es möglich, die v4 auf nuget.org zu verschieben, sogar die Alpha-Version? Konnte bis jetzt nichts Vergleichbares zu Autofixture finden, das .netstandard unterstützt.
Steht das Release-Datum für v4 bereits fest?

@RomanKernSW Im Moment nicht - wir haben noch nicht einmal die Hälfte der Projekte migriert (wie xUnit, NUnit, NSubstitute-Unterstützung), also ist es zu früh. Außerdem haben wir den Plan, den Namespace zu master mit v4 und es nach der Änderung eine Hölle sein wird, dies zu tun.

Haben Sie Probleme mit dem privaten Feed? Sie können den Feed über NuGet.config hinzufügen, wenn dies dringend erforderlich ist.

hm ich muss prüfen, ob es möglich ist, nuget.config für die nuget-Wiederherstellung zu verwenden (.Net Core 2 - Vorschau-Aufgabe in VSO). Im Moment haben wir einen privaten Feed (VSO) mit nuget.org ohne nuget.config-Dateien. Brauche Zeit um das zu testen...

.Net Standard 2.0 verfügt über einen Kompatibilitätsmodus für .Net Framework NuGets.
Ich habe .Net Core Tests mit AutoFixture 3.50.x geschrieben und keine Probleme damit
weit.

@roarwrecker Super , danke fürs Teilen! Das heißt, wir haben einen größeren Zeitpuffer, bis wir die offizielle Unterstützung für NuGet einführen :wink:

@roarwrecker danke ... das war bei .netstandard 1.6 nicht das Problem. Ich konnte das Nuget installieren, aber es wurde nie fehlerfrei kompiliert

Hey Leute, ich bin mir nicht sicher, wie weit die Arbeit von .NetCore fortgeschritten ist, aber ist es möglich, eine Alpha-Version auf NuGet zu erhalten?

@selmendorfFrontline Die Antwort von hier kopieren :

Die Veröffentlichung der Vorabversion im NuGet ist für mich eine etwas schmerzhafte Frage. Während wir damit begonnen haben, .NET Core für die meisten Projekte zu unterstützen , haben wir den Plan, den Standardnamespace zu

• Wenn wir alpha mit bestehendem Namespace freigeben und den Namespace zwischen alpha und RTM ändern, wird dies unsere Kunden verwirren, da sie bereits v4 mit bestehendem Namespace gesehen haben. Ich möchte, dass unsere Kunden das Gefühl haben, dass v4 immer mit einem neuen Namespace veröffentlicht wurde, wenn das Governance-Modell geändert wurde.
• Wenn wir alpha mit geändertem Namespace freigeben, können wir master nicht mehr ohne Probleme v4 Zweig zusammenführen. Derzeit verpflichten wir uns zu beiden Zweigen, deshalb möchte ich die Namensraumänderung bis zum Ende verschieben. Ein weiterer Punkt ist, dass unsere Dokumentation derzeit noch nicht fertig ist, sodass die Leute möglicherweise einfach nicht verstehen, warum alle Namespace-Importe ungültig sind und dass sie einfach einen Textersetzungsvorgang ausführen müssen. Das macht sie beängstigend und die Erfahrung wird nicht so glatt sein, wie ich es mir wünsche.

Der beste Weg, diese Situation zu lösen, wäre, alpha nicht freizugeben und nur den RTM freizugeben. Leider kann ich Ihnen keine genaue ETA nennen, da diese von meiner Kapazität (ich arbeite in meiner Freizeit an diesem Projekt) und der Verfügbarkeit anderer Mitwirkender (meine PRs sollten überprüft werden ) abhängt. In meinem Kopf stelle ich mir die Veröffentlichung in ein oder zwei Monaten vor und hoffe, dass sie in diesem Bereich stattfinden wird. Dieses Projekt war aufgrund der Änderung des Governance-Modells für etwa 9 Monate tot - das ist der Hauptgrund für eine solche Verzögerung der Unterstützung.

Bitte verwenden Sie in der Zwischenzeit das Paket aus dem Vorschau-Feed. Sie können Ihre Nuget.config wie oben erwähnt tunen, also sollte dies ein Problem sein.

Ich werde dieses Problem schließen, nachdem die #857 endgültig zusammengeführt wurde. Unsere endgültige .NET-Kompatibilitätstabelle wäre folgende:

| Produkt | .NET Framework | .NET-Standard |
| ------------------ | ------------------------ | ------------------------ |
| AutoFixture | :heavy_check_mark: 4.5.2 | :heavy_check_mark: 1.5 |
| AutoFixture.xUnit | :heavy_check_mark: 4.5.2 | :heavy_minus_sign: |
| AutoFixture.xUnit2 | :heavy_check_mark: 4.5.2 | :heavy_check_mark: 1.5 |
| AutoFixture.NUnit2 | :heavy_check_mark: 4.5.2 | :heavy_minus_sign: |
| AutoFixture.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 |
| AutoNSubstitute | :heavy_check_mark: 4.5.2 | :heavy_check_mark: 1.5 |
| AutoRhinoMock | :heavy_check_mark: 4.5.2 | :heavy_minus_sign: |
| Redewendungen | :heavy_check_mark: 4.5.2 | :heavy_check_mark: 2.0 |
| Idioms.FsCheck | :heavy_check_mark: 4.5.2 | :heavy_minus_sign: |
| Semantischer Vergleich | :heavy_check_mark: 4.5.2 | :heavy_check_mark: 1.5 |

Alle nicht unterstützten Bibliotheken außer Idioms.FsCheck können nicht aktualisiert werden, da ihre Abhängigkeiten .Net Standard nicht unterstützen und es unwahrscheinlich ist, dass sie dies tun (die meisten von ihnen sind veraltet). Ich habe versucht, Idioms.FsCheck zu portieren, um sowohl .NET 452 als auch .NET Standard 2.0 (wie es technisch möglich ist), konnte es jedoch nicht zum Laufen bringen. Es scheint, dass das F# SDK immer noch ziemlich rau ist und wir auf neue Releases warten müssen. Die Kompilierung und das Laden des Projekts schlagen einfach fehl, nachdem ich den Knoten TargetFrameworks .

Sofern niemand eine andere Vision hat, werde ich diesen Plan verfolgen 😃Ich spüre auch, wie nah wir der Veröffentlichung sind und wie viel dahinter steckt 😊

Geh! Geh! Geh!

Ich habe versucht, Idioms.FsCheck zu portieren, um sowohl .NET 452 als auch .NET Standard 2.0

Haben Sie versucht, auf eine neuere F#-Version umzusteigen? IIRC, es ist auf F# 3.1 und dies könnte der Fall sein.

Tolle Arbeit @zvirja. Glaubst du, wir können v4 rausbringen? Je näher wir kommen, desto aufgeregter fühle ich mich :)

Ich wünschte, ich könnte dir ein Bier anbieten :)

Haben Sie versucht, auf eine neuere F#-Version umzusteigen? IIRC, es ist auf F# 3.1 und dies könnte der Fall sein.

@moodmosaic Ja . Wenn Sie FsCheck 2.9.0 überprüfen, FSharp.Core (>= 4.1.17) abhängt, daher hatte ich keine andere Wahl 😅 Das Problem liegt eher am SDK. Wenn ich beginne, beide Frameworks gleichzeitig anzusprechen, kann ich die Lösung nicht in VS laden
Projekt:

<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>

Versuchen, in VS zu öffnen:

Mit dem Projekt ist alles in Ordnung - das Problem liegt irgendwo im F# SDK. Aus diesem Grund möchte ich die .NET Core-Unterstützung durch FsCheck in bessere Zeiten verschieben.

@Kralizek Bitte beachten Sie die Antwort ein paar Antworten oben .

Gerade in VS 2017.4 eingecheckt und kann immer noch nicht auf mehrere Frameworks für das F#-Projekt abzielen. Daher schließe ich dieses Thema vorerst, da wir .NET Core für alle anderen Projekte unterstützen.

JFYI: Ich habe v4 rc1 für NuGet veröffentlicht, damit Sie einen benutzerdefinierten Feed konsumieren und testen können, ohne ihn spielen zu müssen.