Wie würdet Ihr bestehende Visual Studio 2017 Projekte nach dotnetcore migrieren?

Wie würdet Ihr bestehende Visual Studio 2017 Projekte nach dotnetcore migrieren?

Mit der Portabilitätsanalyse habe ich gesehen, daß es auf Code Ebene außer der Änderung im Konfigurationsmodell keine Probleme gibt, was recht schnell und sicher zu Ändern ist. Meine Projekte sind bisher Windows Desktopm Console App.

Ich hatte es mit Multitarget probiert, doch das hat die Projekte in Visual Studio zum Absturz gebracht - wahrscheinlich, weil ich bisher mit Batch für den Build arbeite. Wahrscheinlich müsste ich das dann alles rausnehmen, damit das funktioniert.

Wie sind Eure Erfahrungen/Empfehlungen?

Hallo weismat,

Multi-Targeting ist ein guter Weg um das zu bewerkstelligen. MS macht es bei vielen ihren Projekten auf github auch nicht anders.

nach dotnetcore migrieren?

Sofern möglich .NET STandard verwendne, denn so können die Projekte universeller verwendet werden. Ggf. auch einen Target für .NET Core 2.1 hinzufügen, da es dort coole Span-API gibt 😉

Ein alternativer Weg ist das Projekt basieren auf .NET Standard / .NET Core neu zu beginnen und den Code eher per Copy & Paste zu übertragen und so gleich die Altlasten im Code über Bord werfen. Wie z.B. bei EF und EF Core od. aber auch Asp.net und Asp.net Core.

Es kommt auf den Umfang deiner Projekte an und was das Ziel der Migration ist. Nur Migrieren um des Migrierens-Willen ist zu wenig, da kannst du es lassen...

mfG Gü

Meine Empfehlung:
-> Neue Projekte anfangen, Code manuell migrieren und den höchsten möglichen .NET Standard verwenden.

Hallo Abt,

den höchsten möglichen .NET Standard

warum den höchsten?

Soll das Projekt möglichst universell einsetzbar sein, so würde ich den möglichst niedrigsten .NET Standard (also z.B. 1.5 statt 2.0) verwenden.

Ist das Projekt ohnehin nur für internen Gebrauch, so den höchsten (aktuell: .NET Standard 2.0) od. wenn es rein auf .NET Core laufen kann, so dann auch dieses, da so u.U. mehr API zur Verfügung stehen.

mfG Gü

@gfoidl
Warum sollte es durch den niedrigeren .NET Standard universeller einsetzbar sein als mit dem höchsten?
Warum sollte man sich noch mit alten Versionen aufhalten, wenn es bereits neuere Versionen gibt?
gerade da die neue .NET Core Version auch eine LTS Version wird, dürfte dies sinnvoller sein auf den aktuellen Standard zu setzen.
Oder habe ich ein Detail übersehen?

T-Virus

Warum sollte es durch den niedrigeren .NET Standard universeller einsetzbar sein als mit dem höchsten?
Warum sollte man sich noch mit alten Versionen aufhalten, wenn es bereits neuere Versionen gibt?
gerade da die neue .NET Core Version auch eine LTS Version wird, dürfte dies sinnvoller sein auf den aktuellen Standard zu setzen.

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

When choosing a .NET Standard version, you should consider this trade-off:

The higher the version, the more APIs are available to you.
The lower the version, the more platforms implement it.

In general, we recommend you to target the lowest version of .NET Standard possible. So, after you find the highest .NET Standard version you can target, follow these steps:

Musst halt schauen was für dich passt bzw was für dich wichtiger ist. Wobei der Standard 2.0 schon sehr viele Libs inkludiert.

Gruss

Coffeebean

Mein Code wird nur von uns selber benutzt.

Migrieren möchte ich vor allem aus Performance Gründen - Span statt Substring ist in den kritischen performance-kritischen Bereichen bereits implementiert. Ich bin sehr gespannt, wie viel das bringen wird, da ich teilweise schon mehrere 100 ms Pausen bei der Garbage Collection in Gen 0 und 1 sehe.

Ich tendiere bisher zu neuen Projekten - ich habe zum Beispiel bisher VS Batches zum Build benutzt und da hat das erste Projekt nach Wechsel zu Multitarget gleich VS regelmässig zum Absturz gebracht. Bei den neuen Projekten verliert man zwar die Historie für jede Datei, aber man beginnt auch ohne Altlasten.

Hallo T-Virus,

ergänzend zu Coffeebeans Antwort: wenn du z.B. ein Projekt hast, das via NuGet allgmeine verfügbar sein soll, so erreichst du mit einem niedrigeren .NET Standard mehr "TargetFrameworks" als mit einem höheren (siehe dazu auch im Link den ".NET implementation support").

Hallo weismat,

Span statt Substring

Span ist eine coole Sache. Bedenke dass eine "fast" und "portable" Variante der Span gibt.

Die schnelle Variante wird direkt durch den JIT unterstützt und ist großteils fast so performant wie (sz-) Arrays. Diese Variante wird aktuell nur von .NET Core 2.1+ unterstützt.

Die portable Variante hat keine direkte JIT-Unterstützung, sondern ist auf zusätzlichen C#-Code angewiesen, daher ist diese ein wenig langsamer als die schnelle Variante.
Vom Funktionsumfang sind beide aber ident.

Wenn ihr das Projekt nur intern verwendet und es möglich ist, so würde ich als TargetFramework direkt auf netcoreapp2.1 gehen.

Noch ein Hinweis: ich weiß nicht ob du string.Create kennst, aber das finde ich super, da so direkt mit einer Span in den String-Buffer während der Konstruktion des Strings geschrieben werden kann. Das erspart das kopieren vom Quell-Buffer zum String-Speicher.

mfG Gü

Ich bin neben Span/Slice noch in Richtung Utf8Parser und auch noch MemoryMarshal.Cast am testen, da ich UTF8 String verarbeite.
Wird Zeit, daß ich mal End2End mit BenchmarkDotNet schaue, was am schnellsten ist. Bin mir da nicht so sicher.