Nancy: Wechseln Sie zu .Net Core 1.1 und migrieren Sie project.json zu csproj

Erstellt am 16. Nov. 2016 · 7Kommentare · Quelle: NancyFx/Nancy

.Net Core 1.1 wurde am 16. November 2016 veröffentlicht und bringt allgemeine Fehlerbehebungen und Verbesserungen. Die einzige Stelle, die dafür geändert werden muss, ist das Kestrel-Beispiel, es muss auf netcoreapp1.1 und Microsoft.NETCore.App 1.1.0 ausgerichtet sein

Am selben Tag wurden auch .Net Core Alpha-Tools veröffentlicht, die Tools enthalten, um Projekte, die project.json verwenden, über dotnet migrate zurück in das csproj-Format zu migrieren.

Weitere Informationen hier - https://blogs.msdn.microsoft.com/dotnet/2016/11/16/announcing-net-core-tools-msbuild-alpha/#visual -studio-code

Ich nehme an, wir werden alle MSBuild-Ordner entfernen, die packages.config- und csproj-Dateien enthalten, da dies csproj zurückbringen wird? Ich nehme an, sobald csproj zurück ist und das Projekt auf 4.5.2 oder netstandard1.6 abzielt, kann der Entwickler/Mitwirkende unsere Sachen auf VS2015 kompilieren, ohne dass zusätzliche Tools erforderlich sind?

Nachfolgend finden Sie eine Liste von Projekten, die verschoben werden müssen (fügen Sie ein Häkchen hinzu und verlinken Sie auf PR, wenn Sie fertig sind):

[ ] Nancy.Authentication.Basic/
[ ] Nancy.Authentication.Forms/
[ ] Nancy.Authentication.Stateless/
[ ] Nancy.Embedded/
[ ] Nancy.Encryption.MachineKey/
[ ] Nancy.Hosting.Aspnet/
[ ] Nancy.Hosting.Self/
[ ] Nancy.Metadaten.Module/
[ ] Nancy.Owin/
[ ] Nancy.Testing/
[ ] Nancy.Validation.DataAnnotations/
[ ] Nancy.Validation.FluentValidation/
[ ] Nancy.ViewEngines.DotLiquid/
[ ] Nancy.ViewEngines.Markdown/
[ ] Nancy.ViewEngines.Nustache/
[ ] Nancy.ViewEngines.Razor.BuildProviders/
[ ] Nancy.ViewEngines.Razor/
[ ] Nancy.ViewEngines.Spark/
[ ] Nancy/
[ ] Nancy.Authentication.Basic.Tests/
[ ] Nancy.Authentifizierung.Formulare.Tests/
[ ] Nancy.Embedded.Tests/
[ ] Nancy.Encryption.MachineKey.Tests/
[ ] Nancy.Hosting.Aspnet.Tests/
[ ] Nancy.Hosting.Selbst.Tests/
[ ] Nancy.Metadaten.Module.Tests/
[ ] Nancy.Owin.Tests/
[ ] Nancy.Testing.Tests/
[ ] Nancy.Tests.Funktional/
[ ] Nancy.Tests/
[ ] Nancy.Validierung.Datenanmerkungen.Tests/
[ ] Nancy.Validierung.FluentValidation.Tests/
[ ] Nancy.ViewEngines.DotLiquid.Tests/
[ ] Nancy.ViewEngines.Markdown.Tests/
[ ] Nancy.ViewEngines.Razor.Tests.Models/
[ ] Nancy.ViewEngines.Razor.Tests/
[ ] Nancy.ViewEngines.Spark.Tests/
[ ] Nancy.Demo.Hosting.Kestrel/

Epic

Quelle

jchannon

Hilfreichster Kommentar

Wir werden wahrscheinlich auf .NET Standard 2.0 abzielen, wenn das herauskommt, aber das bedeutet nicht, dass wir nicht gegen .NET Core testen sollten.

Merken; .NET Standard ist nur eine _Spezifikation_, gegen die Sie kompilieren. Das bedeutet nicht unbedingt, dass Sie auf allen implementierenden Plattformen _laufen_ (ohne Fehler) können. .NET Core ist eine dieser Plattformen, aber auch .NET Framework und Mono. Diese liefern die eigentliche _Implementierung_ zur Laufzeit. Das bedeutet, dass wir unsere Tests wahrscheinlich auf diesen Plattformen durchführen sollten, um sicherzustellen, dass wir tatsächlich laufen und nicht nur gegen den Standard kompilieren.

khellang am 30. Nov. 2016

👍4

Alle 7 Kommentare

Wenn Sie derzeit ein Projekt mit dotnet migrate migrieren, können Sie es (noch?) nicht mit VS2015 erstellen.

jvandertil am 17. Nov. 2016

👍2

https://twitter.com/davkean/status/799400509564035072

Am Donnerstag, 17. November 2016 um 22:25 Uhr, Jos van der Til [email protected]
schrieb:

Wenn Sie derzeit ein Projekt mit dotnet-Migration migrieren, können Sie es nicht erstellen
es mit VS2015 (noch?).
—
Sie erhalten dies, weil Sie den Thread verfasst haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/NancyFx/Nancy/issues/2621#issuecomment -261389526, oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AAGaplWRcllTEAJFrMZ8NTTpnsxKmnPrks5q_NRrgaJpZM4K0btY
.

jchannon am 18. Nov. 2016

Daher laden sie gerne Gepäck um Gepäck auf .net Core, das niemand außer Unternehmen, die es sowieso nicht verwenden werden, benötigt; aber das Hinzufügen von Abwärtskompatibilität für ein Projektformat, das eigentlich nützlich wäre, ist ein No-Go.

Genial.

grumpydev am 18. Nov. 2016

👍2

Gut int!

Am Freitag, den 18. November 2016 um 08:23 Uhr, Steven Robbins [email protected]
schrieb:

Sie freuen sich also, weiterhin Gepäck für Gepäck auf den .net-Core zu laden
niemand außer Unternehmen, die es sowieso nicht verwenden werden, braucht;
aber das Hinzufügen von Abwärtskompatibilität für ein Projektformat, das Sie tun würde
wissen, tatsächlich nützlich sein, ist ein No-Go.
Genial.
—
Sie erhalten dies, weil Sie den Thread verfasst haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/NancyFx/Nancy/issues/2621#issuecomment -261474607, oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AAGapiQmH694ZegeUa0r7AVKVVnxsKKyks5q_WB3gaJpZM4K0btY
.

jchannon am 18. Nov. 2016

An dieser Stelle würde ich einfach auf die bevorstehende Veröffentlichung von .NET Standard 2.0 warten und .NET Core 1.1 ganz überspringen.

Es ist ziemlich erstaunlich, dass Microsoft seit der ursprünglichen Ankündigung von .NET Core so lange gebraucht hat, um sich zusammenzureißen. Meiner Meinung nach wird .NET Standard 2.0 + VS 2017 die _echte_ "Version 1" von .NET Standard/Core sein.

nathan-alden-sr am 30. Nov. 2016

Wir werden wahrscheinlich auf .NET Standard 2.0 abzielen, wenn das herauskommt, aber das bedeutet nicht, dass wir nicht gegen .NET Core testen sollten.

khellang am 30. Nov. 2016

👍4

Gemacht als Teil von #2720

jchannon am 3. Nov. 2017

War diese Seite hilfreich?

0 / 5 - 0 Bewertungen

Nancy: Wechseln Sie zu .Net Core 1.1 und migrieren Sie project.json zu csproj

Hilfreichster Kommentar

Alle 7 Kommentare

Verwandte Themen