Im Standup erwähnt Damian, dass die Nuget-bezogenen Dinge möglicherweise in etwas verschoben werden, das die aktuelle package.config ersetzt. Offensichtlich sind diese Entscheidungen ein gutes Stück weiter, ich bezweifle, dass Sie an dieser Stelle konkrete Antworten bekommen werden.

Und ich stimme nicht zu, dass "JSON umwerfend einfacher ist, diese Abhängigkeiten darzustellen". Es gibt Vor- und Nachteile. Siehe dies https://gist.github.com/darrelmiller/07fed784d2c20de9f5d3719977167181

Ich stimme der Änderung zu, _wenn_ zu nuget.json verschoben würde. das ist der einzige Teil von project.Json, von dem ich dachte, dass er sowieso von Entwicklern bearbeitet werden muss.

@darrelmiller Yaml ist in Bezug auf die Ausführlichkeit wahrscheinlich eine noch bessere Alternative. Und Sie haben mit der durch Kommas getrennten Zeichenfolge anstelle von Arrays geschummelt ;).

@sandorfr Es ist. Ich vermute jedoch, dass einer der Gründe für die Rückkehr zu einem XML-basierten Projektsystem in den vorhandenen bedeutenden Tools für XML-basierte Projektsysteme im .net-Ökosystem liegt. Meine Kommentare sollen nicht versuchen, das beste Format zu identifizieren, sondern nur darauf hinweisen, dass XML nicht an sich schlecht ist.

Ja und das ist die schlimmste Nachricht dieser Woche. Es ist, als würde man in die Vergangenheit zurückversetzt... :( Tatsächlich ist Xml nicht schlecht, aber msbuild... Und ein msbuild-XML-Basisprojekt wird nicht so glatt sein, wie Sie es beschrieben haben.

Ich vermute jedoch, dass einer der Gründe für die Rückkehr zu einem XML-basierten Projektsystem in den vorhandenen bedeutenden Tools für XML-basierte Projektsysteme im .net-Ökosystem liegt.

Ich verstehe einfach nicht, warum all die Dinge mit " core " angehängt wurden, um darauf hinzuweisen, dass es sich um eine brandneue Sache handelt, wenn die Absicht besteht, auch das Gepäck wie msbuild weiterzuleiten.

Der Prozess war seit mehr als zwei Jahren zu schmerzhaft, aber viele Leute waren in Ordnung, weil alle Neuzugänge und Verbesserungen das Ökosystem an andere Ökosysteme anpassten und alle Änderungen aus guten Gründen waren. Doch plötzlich begannen Entwickler von Dark-Materie-Unternehmen, hinter verschlossenen Türen Feedback zu geben, und wir sehen, dass viel Gepäck mitgenommen werden muss.

Es gibt nicht viele Ökosysteme, die eine XML-basierte Konfiguration haben. Tatsächlich umfassen alle neu gestalteten Ökosysteme andere Formate (YAML, JSON usw.). Schauen Sie sich die Reaktion all der Leute in den sozialen Medien an, ich sehe nicht viele Leute, die diese Veränderung mögen. Allerdings scheint Feedback, das privat gegeben wurde, dem Team wichtiger zu sein. Das ist keine schlechte Sache, ich verstehe die Gründe, aber es zeigt nur, wie die Entscheidungen in diesem Ökosystem verarbeitet werden.

+1 bei den schlimmsten Nachrichten der Woche. Wo war die Diskussion dazu? Ich kann nichts finden, nur eine einseitige Entscheidung.

Ich sehe keine Unterstützung der Community für diese Entscheidung, und viel dagegen (85 % bis 15 % bei der letzten Zählung). Wie ist die Diskussion verlaufen, wer hat die Entscheidung aufgrund welcher Informationen getroffen?

Gehen wir in .NET Core so vor? Kompromisse bei der Qualität hinter verschlossenen Türen einzugehen, weil wir eine nicht offengelegte Liste von Legacy-Technologien unterstützen möchten?

Lassen Sie uns auf jeden Fall eine VS-Erweiterung erstellen, die eine .csproj aus einer project.json erstellt, die Leute, die diese alten Technologien verwenden, nutzen können.

Aber schicken Sie uns nicht zurück in den Alptraum der XML-basierten Projektdateien. Sie waren eine schlechte Idee, als sie eingeführt wurden, und wir zahlen seit über einem Jahrzehnt die Steuer für fehlerhafte Zusammenführungen und schwierige Lesbarkeit. Es ist genug.

Ich denke, Sie sind zu pessimistisch - und ich denke, das liegt hauptsächlich daran, dass wir alle davon überrascht wurden. Lassen Sie sie mehr Informationen zu ihren Plänen teilen und dann werden wir sehen. @DamianEdwards hat klar gesagt, dass sie die guten Teile des project.json-Modells behalten möchten.

Das wäre meiner Meinung nach:

• nicht jede cs-Datei angeben zu müssen
• in der Lage zu sein, die Datei zu ändern, ohne das Projekt entladen zu müssen
• die Möglichkeit, Nuget-Abhängigkeiten direkt in der Datei zu ändern (mit IntelliSense)
• in der Lage sein, Nuget-Pakete durch lokale Quellen über global.json zu ersetzen

Was die Kompilierung angeht, denke ich nur, dass es möglich sein sollte, es zu kompilieren, ohne dass Visual Studio installiert ist. Für mich ist es egal, ob der eigentliche Befehl "dotnet build" oder "msbuild" ist. Wichtig ist, dass es eine Möglichkeit geben sollte, die gesamte Lösung zu kompilieren, die übrigens in "dotnet cli" noch nicht existiert (zumindest nicht meines Wissens).

Wenn dies erreicht werden kann, bin ich mit der verwendeten Syntax einverstanden. XML ist nicht großartig, aber JSON hat eindeutig auch seine Nachteile.

Bearbeiten: Ich denke, dies ändert nichts an den grundlegenden (und großartigen) Ideen von .NET Core usw.

IMHO, das Hauptproblem ist, dass diese Art von drastischen Änderungen kurz vor RTM nicht gut ist. Wenn dies in Beta-Zeiten passiert, werden die Entwickler/Teams möglicherweise nicht so überrascht sein. Denken Sie an die Investitionen, die die Leute seit den letzten 2 Jahren getätigt haben . Denken Sie je nach project.json-System an aktuelle Produkte/Bibliotheken/Frameworks. Asp.Net ist in RC nicht in der Vorschau/Alpha/Beta, diese Art von Änderungen bricht das Vertrauen der Entwickler/Teams :(.

IMHO, das Hauptproblem ist, dass diese Art von drastischen Änderungen kurz vor RTM nicht gut ist.

Das dachte ich auch zuerst, aber soweit ich das verstanden habe, führt dies zu keinen Änderungen an Ihrem Anwendungscode. Es wirkt sich nur auf Ihre project.json/xproj/csproj-Dateien aus und sie sagten, dass die Änderung möglicherweise automatisch erfolgt – dies wird also den guten alten Projektmigrationsschritten ähnlich sein, die bereits viele Male beim Upgrade von Visual Studio durchgeführt wurden.

Übrigens fand ich es immer seltsam, eine project.json- und eine xproj-Datei zu haben (die den Standard-Namespace für Visual Studio-Vorlagen und einige Ausgabepfade enthält, sodass Sie sie manchmal auch bearbeiten müssen).

Übrigens fand ich es immer seltsam, eine project.json- und eine xproj-Datei zu haben (die den Standard-Namespace für Visual Studio-Vorlagen und einige Ausgabepfade enthält, sodass Sie sie manchmal auch bearbeiten müssen).

Vielleicht ist es seltsam, aber sie antworten auf verschiedene Dinge. project.json ist die einzige Datei, die zum Erstellen eines .net-Kernprojekts benötigt wird, und xproj bezieht sich auf proprietäre Tools, auch Visual Studio genannt. Bei package.json und .idea ist es sehr ähnlich, wenn Sie Webstorm verwenden, um an Ihren Knotenprojekten zu arbeiten. Nur Trennung von Bedenken. Visual Studio könnte project.json unter Eigenschaften ausblenden, wenn sie möchten, und eine zusammengeführte kuratierte GUI-Erfahrung anbieten, wenn sie möchten, ohne alles miteinander zu vermischen.

Ich benutze dieses Zeug schon so lange auf einem Mac in VS Code, dass ich alles über xproj vergessen habe. OTOH, ich habe das Debuggen wirklich vermisst und noch einiges mehr von Visual Studio!

Ich glaube, du bist zu pessimistisch - und ich denke, das liegt hauptsächlich daran, dass wir alle davon überrascht waren

Nein, tut mir leid, ich glaube nicht, dass ich zu pessimistisch bin. XML ist ein schlechtes Format für jede Situation, in der Sie Code-Zusammenführungen durchführen, dh für alle Softwareprojekte. XML wurde nicht für Dinge wie Konfigurationsdateien und Projektdateien entwickelt und hätte nie für sie verwendet werden dürfen.

http://c2.com/cgi/wiki?XmlSucks
http://www.ibm.com/developerworks/xml/library/x-sbxml/index.html
http://nothing-more.blogspot.co.za/2004/10/where-xml-goes-astray.html

Jetzt wird .NET Core entwickelt, wenn jeder denkt, dass JSON alles lösen wird. Ich glaube nicht, dass JSON mehr eine langfristige Lösung ist als XML, aber ich weiß , dass es einfacher ist, JSON-Konflikte als XML-Konflikte zusammenzuführen.

Ich fand es ein Hauch frischer Luft, mich nicht mit XML-Müll für Projektdateien zu befassen, ich fand es einfacher, die JSON-Dateien zu lesen, ich fand es einfacher, mit den JSON-Dateien außerhalb von Visual Studio zu arbeiten, und ich nicht zu XML/MSBuild zurückkehren möchten.

Ja, das sind meine persönlichen Gefühle, und ja, sie sind subjektiv, aber aufgrund der Kommentare auf Twitter und anderswo glaube ich nicht, dass sie isoliert sind. Um ehrlich zu sein, lässt mich diese Entscheidung die gesamte Richtung von .NET Core und vor allem die Art und Weise, wie wichtige Entscheidungen wie diese getroffen werden, vollständig anzweifeln.

@DamianEdwards hat klar gesagt, dass sie die guten Teile des project.json-Modells behalten möchten.

Aus meiner Sicht sind die besten Teile des project.json-Modells, dass es nicht csproj, nicht MSBuild und nicht XML ist. Bleiben die "guten" Teile erhalten? Scheinbar nicht. Nachdem wir zu der Annahme verleitet wurden, dass sie endlich auf dem Rasen waren, stellte sich heraus, dass es sich nur um eine Irreführung handelte. Uns wurde über das neue Build-System erzählt, über Gulp und project.json und wie die Dinge jetzt anders sein würden, und dann stellte sich heraus, dass alles eine Farce war und es wieder ein beschissenes altes MSBuild war.

Ich denke, die Formate JSON und XML sind in Bezug auf das Zusammenführen ziemlich gleich - beide haben schließende Tags (obwohl es in JSON nur eine geschweifte Klammer ist), was bedeutet, dass Sie Probleme mit leeren/eins/vielen Szenarien haben. Ändern Sie einfach ein leeres JSON-Array in eines mit Elementen. Ich würde argumentieren, dass JSON sogar den zusätzlichen Nachteil des Endkommas hat, das zwei Zeilen ändert, wenn Sie ein Element zu einer Liste hinzufügen.

Sie müssten zu YAML usw. wechseln, wenn Sie dies vermeiden möchten.

IMO liegt das Problem mit csproj nicht bei XML, sondern daran, wie Visual Studio es behandelt hat und dass es jede cs-Datei enthielt. Wenn dies behoben wird und die Tools nicht zufällig Dinge in der Datei ändern, sollte das Zusammenführen kein Problem mehr sein.

In Bezug auf die Lesbarkeit bevorzuge ich jedoch auch JSON. Ich konnte eine project.json von Grund auf neu schreiben - ich denke, das werde ich mit dem csproj nicht mehr tun können (csproj erfordert eine zufällige ProjectGuid usw.). Dafür brauchen wir also definitiv Tooling-/Kommandozeilen-Unterstützung.

Meine Hauptsorge bei dieser ganzen Sache, von der ich noch nicht viel gehört habe, ist, dass project.json in Bezug auf Referenzen viel aussagekräftiger ist als .csproj Projektdateien. Das Schöne an den Abhängigkeiten in der project.json Datei und warum ich mich darauf gefreut habe, unsere Codebasis dorthin zu migrieren, ist, dass Sie einfach sagen "Ich brauche diese Abhängigkeit" und es spielt keine Rolle, ob es sich um ein lokales Projekt oder ein NuGet-Paket. In unserem Fall würde uns das viel Flexibilität und coole neue Optionen verschaffen. Im Gegensatz dazu ist derzeit eine Referenz in einer .csproj Datei ein fester, relativer Pfad zu einer .dll Datei auf der Festplatte. Im Moment bringt das Hinzufügen eines Eintrags in Ihre package.config in einem traditionellen Projekt nicht wirklich etwas, Sie müssen auch einen Verweis auf ein bestimmtes .dll aus diesem Paket zur .csproj Datei hinzufügen . Das erledigen die NuGet-Tools in Visual Studio für Sie, aber ich möchte diese Tools nicht verwenden, wenn das Hinzufügen einer Textzeile zu einer project.json Datei viel einfacher ist.

Mir ist klar, dass das Team alle Funktionen der project.json Datei beibehalten und die Funktionen des .csproj Formats erweitern möchte, aber sie haben auch darüber gesprochen, project.json als Datei beizubehalten um Ihre NuGet-Pakete anzugeben. Ich sehe nicht, was das im Vergleich zur aktuellen Situation mit packages.config hinzufügen würde, wo es nicht ausreicht, nur einen Eintrag hinzuzufügen, da Sie immer noch eine Referenz zu einem .dll hinzufügen müssen .csproj . Wenn die .csproj Datei die Zukunft werden soll, würde ich viel lieber sehen, dass das Kernteam den ganzen Weg geht und project.json oder nuget.json fallen lässt, oder wie auch immer, es wird _vollständig_ genannt und fügt hinzu eine deklarativere Methode, um Verweise auf das Format .csproj hinzuzufügen. Ich kann gut damit leben, eine XML-Datei anstelle einer JSON-Datei bearbeiten zu müssen (obwohl ich sicherlich JSON bevorzuge), aber es wäre wirklich schade, die deklarative Natur von project.json zu verlieren und ich brauche keine zwei verschiedene Stellen, an denen ich meine Abhängigkeiten angeben muss.

Bitte geben Sie Feedback unter https://www.surveymonkey.com/r/H6Q88PP

Nur um es klarzustellen, beim Lesen der Standup-Notizen wird erwähnt, dass eine Option darin besteht, eine Option nuget install --save zu haben (siehe https://blogs.msdn.microsoft.com/webdev/2016/05/11/ note-from-the-asp-net-community-standup-may-10-2016/). Obwohl ich das für eine gute Idee halte, halte ich es für eine schlechte Idee, die '.json-Datei mit Intellisense bearbeiten' durch diese zu ersetzen. Ich denke, es ist eine gute Idee, im Editor zu bleiben, für einige von uns, die nicht zu einer Shell wechseln möchten, um alles zu tun. Ich persönlich bevorzuge es, beide Erfahrungen zu machen. Befehlszeile + Benutzeroberfläche zum Hinzufügen von Abhängigkeiten sind nicht gut genug.

Ich bin Programmierer, ich möchte den Editor nicht verlassen.

Ich denke, das ist eine schreckliche Entscheidung. Sie sagten, Sie möchten .NET Core wirklich einfach machen, aber dann nehmen Sie diese Änderung vor. Es ist mir egal, wie viel Lippenstift Sie auf MSBuild auftragen, es wird immer noch MSBuild sein und Außenstehende werden es sich ansehen und sofort deaktivieren. Es wird nie ein einfaches handbearbeitbares Format sein. Vielleicht gab es einige schwierige technische Probleme, aber es hört sich so an, als ob diese damit zusammenhingen, das Projektsystem zu mehr als nur einem einfachen Projektsystem zu machen. Wenn die Leute komplexere Dinge in ihren Builds tun möchten, könnten sie einige Skripte schreiben oder dazu msbuild verwenden. project.json ist eine wunderbar einfache Sache und ich bin jetzt wirklich ratlos.

Mein Lieblingszitat zu MSBUILD-Dateien?

Ich musste vor kurzem viel Zeit mit csproj-Dateien verbringen. Sie sehen aus und verhalten sich ziemlich ähnlich wie Ant/Maven. Dies ist kein Punkt zu ihren Gunsten.
Ant/Maven wurde von vielen Java-Entwicklern geliebt und später gehasst. XML ist eine extrem ausführliche Syntax, mit der man umgehen muss.
Aber der wahre Mörder ist Lockin. Ja, Sie können msbuild verwenden, um Dinge mit ihnen zu tun, aber die Syntax ist wirklich nicht dafür ausgelegt, dass ein Entwickler sie liest/bearbeitet, sondern für eine IDE, um den Zustand zu serialisieren. Nur weil es einen Befehlszeilen-Runner gibt, heißt das nicht, dass das Format entwicklerfreundlich ist. Solange Sie in VS bleiben, werden Sie es nicht wirklich bemerken. Sobald Sie gehen, ist es jedoch nicht mehr bequem. csproj-Dateien sind eine Sache, von der ich wünschte, .Net hätte einen anderen Pfad als Java genommen.

Quelle

Ich denke, es ist wichtig, zwischen MSBuild und der Art und Weise, wie Visual Studio derzeit MSBuild verwendet, zu unterscheiden. Ich bearbeite seit Jahren MSBuild-Dateien von Hand und verwende sie für alle meine Projekte. ZB https://github.com/tavis-software/Tavis.home/blob/master/build/Build.proj

Die csproj-Dateien, die Visual Studio erstellt, sind ziemlich eklig, aber MSBuild die Schuld zu geben, ist, als würde man sagen, dass C# Mist ist, weil Sie einmal gesehen haben, wie ein Codegenerator damit hässlichen Code erstellt hat.

@darrelmiller Ich stimme zu.

Lassen Sie uns die Zeit um sechs Monate nach vorne verschieben und sehen, ob es ein Moment "hat es dir gesagt" oder eher ein "einer Kugel ausgewichen" ist.

Nach dem Aufruf von @shawnwildermuth auf seinem Blog werde ich meine eigenen 2 Cent einwerfen:

Ich verstehe nicht, warum das so eine große Sache ist. Ich freue mich, wieder auf ein XML-basiertes csproj umzusteigen, denn:

• Das manuelle Bearbeiten von JSON ist NICHT natürlicher/einfacher als XML. Es ist tatsächlich das Gegenteil IMHO. Jeder dumme Editor gibt mir XML-Tag-Vervollständigung, das manuelle Erkennen eines Formatfehlers ist einfacher und so weiter. JSON ist nicht einfacher, wenn ich es manuell schreiben muss. Damit komme ich zu Punkt 2...
• Warum macht es überhaupt so viel Aufhebens, eine Projektdatei mit einem Editor zu bearbeiten? Das Bearbeiten einer Projektdatei ist NICHT der Ort, an dem ich meine Zeit als Entwickler verbringen möchte. Dies sollte zu Beginn eines neuen Projekts eine einmalige Sache sein, aber danach sollte es IMHO nicht sehr oft vorkommen. Ob ich es mit JSON, XML, YAML, TOML oder was auch immer jemandem gerade einfällt, bearbeiten muss, ist mir völlig egal.
• Die eine Sache, die ich vermeiden möchte, ist, NuGet eng mit ASP.NET zu koppeln . NuGet ist großartig, ich liebe es und ich möchte, dass mein ASP.NET sehr gut damit funktioniert, aber es ist NICHT erforderlich, um ASP.NET auszuführen. Ja, ich muss möglicherweise die Binärdateien aus einem NuGet-Feed ziehen, um die Funktionen von MVC usw Ordner soll eine Flexibilität sein, die mir weiterhin zur Verfügung steht. Ich möchte nicht, dass ASP.NET, das csproj oder irgendetwas anderes eng an diese "unterstützenden" Systeme von Drittanbietern gekoppelt ist. Ich möchte, dass sie eine großartige Integration ermöglichen, aber die Tür für die Anpassung offen halten ! Daher würde ich hoffen, dass NuGet-Pakete nicht in der .csproj-Datei deklariert werden und eine nuget.json nicht fest in MSBuild integriert wird.
  Enge Integration hinter einer gut definierten Schnittstelle == GROSSARTIG.
  Enge Kopplung, vorausgesetzt, dies ist der Standard für alle == BAD.
• Abschließend möchte ich sagen, dass die Datei project.json sehr wenig mit .NET Core und ASP.NET Core zu tun hat. Core hat so viel mehr zu bieten als eine Datei project.json. Project.json war kein neues Feature, es war ein Versuch, etwas umzugestalten, das bereits in einem anderen Format existierte. Das ist mir nicht so wichtig, denn als Entwickler konzentriere ich mich eher auf die neuen Features und Möglichkeiten, die .NET Core bietet, um eine großartige Anwendung in der Cloud zu entwickeln, anstatt auf die langweilige Konfiguration, die ich ab und zu vornehmen muss.

Ich denke, es ist ein großartiger Schritt, zu MSBuild zurückzukehren, da ich mich als Entwickler mehr für Kompatibilität interessiere und ich denke, dass dies der Schlüssel ist. MSBuild funktioniert, und um fair zu sein, funktioniert es größtenteils sehr gut, und anstatt es durch etwas Neues zu ersetzen, was neue Probleme mit sich bringt und Kompatibilitätsprobleme verursacht, lasse ich lieber jemanden die Dinge verbessern, die bereits funktionieren und im Laufe der Zeit besser werden. Jeder denkt, dass er Dinge neu schreiben und verbessern kann, bis Sie feststellen, dass Sie nur einen kleinen Problembereich gelöst haben, der Ihnen zu dieser Zeit wichtig war, und später, wenn Sie erweitern möchten, stellen Sie fest, dass Sie dasselbe alte Ding wieder aufbauen, das Sie haben Sie haben am Anfang versucht, zu ersetzen. Es ist besser, die Dinge zu verbessern, die bereits funktionieren.

Aus diesem Grund hätte ich es wahrscheinlich auch vorgezogen, Mono besser zu machen und die Lücken zu schließen, anstatt eine neue plattformübergreifende Laufzeit zu implementieren, aber das ist eine andere Diskussion.

Endgültige Umfrageergebnisse: 100 Antworten, für eine 9 Millionen .NET-Entwicklerpopulation, das sind ±10 % mit 95-prozentiger Konfidenz.

Hat Ihnen der Wechsel zu project.json gefallen?
Ja, es war eines meiner am meisten erwarteten Features 19,19 %
Ja 39,39 %
Nein 13,13 %
Nein, es war eine schreckliche Richtung, 16,16% zu nehmen

Sind Sie glücklich über den Wechsel zurück zu MSBuild?
Ja, jetzt kann ich darüber nachdenken, es zu übernehmen 9,09%
Ja 16,16%
Nein 30,30%
Nein, das lässt mich die Richtung in Frage stellen, die .NET Core einschlägt 29,29 %
15,15% egal

Glauben Sie, dass MSBuild verbessert wird?
Verbessert? Es ist schon perfekt. 1,01%
Ja 63,64 %
Nein 12,12 %
Es ist grundlegend kaputt, wie kann es verbessert werden? 20,20%
Ist mir egal 3,03%

Glauben Sie, dass diese Entscheidung richtig getroffen wurde?
Ja, das Team nahm Feedback auf und änderte die Richtung, als es 20,41 % brauchte.
Ja 6,12 %
Nein 24,49 %
Nein, das Team traf unverantwortliche Entscheidungen hinter verschlossenen Türen, ohne die Community einzubeziehen 39,80 %
Ist egal 9,18%

Wie wirkt sich diese Entscheidung auf Ihre Wahrnehmung von .NET Core aus?
Verbessert es, sie kommen endlich zur Vernunft 13.00%
Verbessert es 11,00%
Verschlimmert es 42,00%
Verschlimmert sich, lässt mich das Ganze in Frage stellen 18.00%
Ist egal 16%

100 Personen haben an der Umfrage teilgenommen. Ich wusste bis jetzt noch nicht einmal davon. Schauen wir uns das noch einmal an, wenn wir repräsentative Zahlen haben, denn 100 Personen sind höchstens ein schlechter Scherz.

Tatsächlich geben Ihnen 100 Personen, wie angegeben, eine Fehlerquote von ±10 % mit 95-prozentiger Sicherheit. Welches Maß an Selbstvertrauen benötigen Sie, um zu sehen, dass Sie ein wahres Spiegelbild sehen? Müssen wir alle 9 Millionen Entwickler befragen?

Zeigen die 800 Stimmen bei UserVoice zur Erweiterung von project.json auf den Rest von VS nicht auch den Trend?

Und wenn wir ein wirklich repräsentatives Beispiel erstellen wollen, dann sollte Microsoft es vielleicht tun. Da sie nicht ein einziges Mal um Stellungnahme zu dieser Entscheidung gebeten haben, auch nach wiederholten Beschwerden aus zahlreichen Richtungen.

Sie haben eine viel größere Reichweite als ich bei einer privaten Umfrage. Ich müsste meinen SurveyMonkey-Plan gegen Aufpreis aktualisieren, um auf mehr als 100 Ergebnisse zuzugreifen, damit ich eine Umfrage durchführen kann, die Microsoft selbst hätte durchführen sollen!

Nun, wenn Sie aussagekräftige Zahlen haben möchten, möchten Sie eine faire Darstellung der 9 Millionen Entwickler anstreben. Wenn ich 100 Twitter-Follower habe, die mir folgen, weil wir das gleiche Interesse haben, und ich bitte alle, an der Umfrage teilzunehmen, dann haben Sie 100 Leute mit einer sehr einseitigen Ansicht, die nur eine bestimmte Gruppe von Entwicklern repräsentieren.

Die Begründung im Standup für die Wiederbelebung von MSBUILD war, eine Integration zwischen bestehenden Tools zu ermöglichen und bestehenden Projekten die Nutzung von .NET Core zu erleichtern. Nachdem ich jedoch ein ziemlich großes Projekt auf .NET Core migriert hatte, war das Projektsystem ehrlich gesagt die GERINGSTE meiner Herausforderungen. Das als alleinige Begründung zu verwenden, scheint mir kein guter Grund zu sein. Ich arbeite auch seit Jahren mit dem csproj-System, einschließlich der manuellen Bearbeitung von Dateien. Das war immer schmerzhaft. Das auf project.json basierende System ist VIEL einfacher und für alle (einschließlich Neulinge) viel zugänglicher. Ich denke, das ist das Ziel. Und doch machen wir jetzt einen Schritt zurück, indem wir MSBUILD wiederbeleben. Meine persönliche Meinung ist, dass dies ein großer Fehler ist. Ich habe meine Stimme abgegeben, um project.json zu behalten.

Tatsächlich habe ich fast keine Twitter-Follower, das sind größtenteils Follower von .NET Core-Entwicklern, deren Twitter-Streams ich gepostet habe.

Und noch einmal, Microsoft wäre sicherlich die richtige Person für eine solche Umfrage? Warum bleibt es mir überlassen, der einzige zu sein, der die Leute wirklich fragt, was sie wollen?

Warum ist es MS egal, was die Leute denken?

TBH Ich wusste bis vor 30 Minuten nicht, dass es eine Umfrage gab und ich wusste nicht, dass Sie die Umfrage privat durchführen. Ich stimme zu ... wenn Microsoft ein Interesse an der Reaktion der Entwickler auf diese Änderung hat, sollten sie eine solche Umfrage durchführen. Aber vielleicht haben sie ihre Hausaufgaben schon gemacht und nehmen deshalb diese Veränderung vor. Ich weiß nicht, aber ich würde die Dinge nicht immer so negativ sehen, denn schließlich bauen diese Jungs das Zeug für uns, also bin ich sicher, dass sie nur das beste Interesse für uns haben.

Wenn sie ihre Hausaufgaben gemacht hätten, hätten sie gewusst, dass 60 % der Entwickler gegen diesen Schritt sind, und hätten entsprechend kommuniziert und sich engagiert. Sie taten es nicht, was bedeutet, dass sie keine Ahnung von der Reaktion hatten, was bedeutet, dass sie sich nicht engagierten.

Ich bin ein zahlender Kunde mit Unternehmenslizenzen für VS. Ich habe nichts gesehen. Ich arbeite bei vier Blue-Chip-Finservice-Firmen und bezahle auch Unternehmenskunden. Sie sahen nichts. Mit wem haben sie sich also genau beschäftigt? Diese Frage stelle ich seit gestern Abend und habe keine Antwort darauf erhalten.

Ich sehe die Dinge negativ, weil dies eine massive, späte Änderung an einem grundlegenden Teil der .NET Core-Geschichte ist, einem Teil, der uns als Kern der Zukunft mitgeteilt wurde, und wir (vielleicht dummerweise) haben sie auf ihre Kosten gebracht Wort und haben eine CD/CI-Pipeline basierend auf dieser Technologie aufgebaut, die jetzt völlig wertlos ist. Ich sehe es auch negativ, weil während eines ganzen Tages, in dem ich nach Details zur Entscheidungsfindung gefragt habe, völlige Funkstille herrschte.

Es hört sich so an, als ob sie die Benutzer unter den Bus geworfen haben, um den Werkzeugmachern zu helfen. Wenn ja, können sie bitte meine VS-Lizenzgebühren von den Werkzeugherstellern einziehen und nicht von mir.

@shederman Obwohl ich den Ergebnissen Ihrer Umfrage zustimme, sind die Fragen offensichtlich in die bevorzugte Richtung

Ich stimme Ihnen zu, dass dies keine ideale Umfrage ist. Ich habe es in 5 Minuten erstellt. Der Punkt ist: Warum erstelle ich es?

Warum ist Microsoft nicht daran interessiert, herauszufinden, was die Leute denken?

Ich erwartete nur etwa 30 Antworten und hoffte, dass es ausreichen würde, um sie davon zu überzeugen, die Diskussion wieder aufzunehmen, ihre Gedanken offen zu teilen und sich angemessen mit uns zu beschäftigen, anstatt die Meinung zu kritisieren.

Es sind jetzt 138 Antworten, aber es gibt immer noch keine Anzeichen dafür, dass Microsoft auch nur bedenkt, dass ihre Entscheidung vielleicht eine schlechte war. Nur sehr vage, mit der Hand winkende Erklärungen, die nicht durch die Fakten gestützt werden.

Alles, was ich will, ist eine angemessene Beteiligung an dieser Entscheidung. Keine wichtigen Entscheidungen hinter verschlossenen Türen basierend auf geheimen Informationen und Feedback. Dies sollte offen und transparent erfolgen, ein Wort, das in diesem Prozess bisher einzigartig gefehlt hat.

Ach Leute, komm schon. Microsoft besitzt das Framework und lässt ihn tun, was er will. Aber denken Sie für einen Moment nach, die Leute arbeiten seit März-April 2014 daran und kurz vor 1 Monat nach der Veröffentlichung ist es lächerlich, diese Art von dramatischen Veränderungen zu machen. Es bricht das Vertrauen der Entwickler. Es verschwendet die Zeit der Leute. Sie müssen kein Open-Source-Framework erstellen, wenn Sie der Community nicht vertrauen können. Gehen Sie und schließen Sie die Quelle sofort, damit Sie niemand belästigt, wenn Sie diese Art von Änderungen in den dunklen Räumen vornehmen.

Ich bitte Microsoft um Entschuldigung und Sympathie (MVPs oder Community-Mitglieder), bitte seien Sie in dieser Zeit realistisch.

@shederman

Wenn sie ihre Hausaufgaben gemacht hätten, hätten sie gewusst, dass 60 % der Entwickler gegen diesen Schritt waren.

Es würde mich überraschen, wenn mehr als 20 % der Entwickler im .net-Ökosystem überhaupt von der Existenz von project.json wissen. Wir vergessen manchmal, dass wir in einer Art Entwicklerblase leben und an der Spitze neuer technischer Entwicklungen stehen.

Ich glaube, dass der Reiz von project.json vor allem in seiner Einfachheit liegt. Wenn Sie jedoch die Entwicklung seit der ersten Einführung auf dem ASP Net Insiders-Tag vor 3 Jahren verfolgt haben, hat sie begonnen, immer komplexer zu werden, da versucht wird, mehr Anwendungsfälle zu unterstützen. Um das gesamte .net-Ökosystem zu unterstützen, befürchte ich, dass viel von der geliebten Einfachheit verloren gehen würde.

Das soll nicht heißen, dass project.json nicht einige großartige neue Funktionen mitbringt, und ich glaube, dass es eine gute Sache ist, das Projektformat für den Menschen zugänglicher zu machen. Ich denke jedoch, dass es einfacher ist, diese Vorteile in MSBuild zu integrieren und viel mehr Menschen zu nutzen, als zu versuchen, project.json überall hin zu bringen.

Es würde mich überraschen, wenn mehr als 20 % der Entwickler im .net-Ökosystem überhaupt von der Existenz von project.json wissen.

Ich würde wetten, dass weniger als 20% Entwickler in .net eco über MVC und Web Api Bescheid wissen. Mehr als 70 Personen verwenden WebForms, WCF, WebService. Wieder bitte ich Microsoft um Entschuldigung und Mitgefühl, bitte seien Sie realistisch

@shederman Ihr Bericht über jegliches Vertrauen aufgrund der Ergebnisse Ihrer Umfrage ist wahrscheinlich für die keine Zufallsstichprobe , die für die Angabe eines solchen Konfidenzintervalls, wie Sie es für die Grundgesamtheit implizieren, unbedingt erforderlich ist. Selbst wenn es sich um eine zufällige Stichprobe von .NET-Entwicklern handelt, können Sie nicht für jede Antwort eine 95-prozentige Vertrauenswürdigkeit angeben, da Sie die gleichzeitige Inferenz nicht angepasst haben.

Für die Gesamtbevölkerung können aus Ihrer Umfrage keine aussagekräftigen statistischen Schlussfolgerungen gezogen werden. Ich freue mich jedoch, dass Sie die Umfrage durchgeführt haben. Sie präsentieren viele hervorragende Punkte. Ich denke, die Ergebnisse deuten darauf hin, dass viele Menschen entweder verärgert oder besorgt über die Veränderung sind. Veröffentlichen Sie jedoch bitte keine falschen statistischen Schlussfolgerungen ... geben Sie Zahlen heraus, die praktisch bedeutungslos sind, und machen Sie so empörende Bemerkungen wie "Sie hätten gewusst, dass 60 % der Entwickler gegen diesen Schritt waren".

Was bringt es dann, etwas zu ändern, wenn wir mehr als 70 % der Marktbasis belästigen? Bleiben wir genau dort, wo wir sind, und machen wir weiter mit der inkrementellen Evolution. Wenn es nicht kaputt ist, repariere es nicht, oder?

Ich weiß, dass project.json an Komplexität gewachsen ist. Da stimme ich zu 100 % zu. War die Lösung, zurück zu csproj zusammenzuführen? Ich habe den Leuten vorhin gesagt, dass ich voll und ganz hinter Microsoft stehe, weil ich die Dinge richtig mache, anstatt in Eile zu liefern. Der Wechsel zu csproj sieht überstürzt aus.

Warum macht man das nach RC2? Von wo ist das gekommen? Hatte die Übernahme von Xamarin etwas damit zu tun? War es die dotnet-cli Integration? War es ein großer Kunde? Wer weiß...

Ich konnte den Massen erklären, dass RC1 -> RC2 das Beste war. Vereinheitlicht mit der dotnet cli. Aber die Projekt.json-Änderung? Ich habe nichts zu sagen, um es zu erklären. Nur das weiß ich nicht. Die Leute sind verwirrt und ich habe keine zwingenden Argumente für sie.

Warum macht man das nach RC2? Von wo ist das gekommen? Hatte die Übernahme von Xamarin etwas damit zu tun? War es die dotnet-cli-Integration? War es ein großer Kunde? Wer weiß...

Dies ist der Punkt, der gedacht wurde. Wir kennen nicht die ganze Geschichte hinter dem Wechsel zu csproj. Anstatt sich zurückzulehnen, zu entspannen und zuzusehen und zu verstehen, warum dies geschieht, verfluchen jetzt alle Microsoft und gehen vom Schlimmsten aus. Das macht keinen Sinn. Diese Jungs bauen dieses Zeug nur für uns und nur für uns. Sie nehmen solche Änderungen definitiv nicht wegen eines großen Kunden vor, denn 1 großer Kunde ist wertlos, wenn Sie riskieren, Ihre gesamte Community zu verlieren. Das Microsoft .NET-Ökosystem ist HUUUUUUGE und es ist offensichtlich eine komplexe Aufgabe, .NET Core gut einzupassen davon können wir am meisten profitieren - langfristig. Ich bin hier raus, weil mich all diese negativen Vorzeitspekulationen langweilen.

@darrelmiller Entschuldigung, wenn ich 60 % sage, meine ich 60 % derer, die auf die Umfrage geantwortet haben.

@GuardRex Du hast vollkommen recht. Die einzige Organisation, die uns richtige Ergebnisse liefern kann, ist MS, und sie scheint sich nicht darum zu kümmern.

Meine Umfrage war nur dazu gedacht, ein vages Maß an Unterstützung zu messen, und keine statistisch signifikante Stichprobe zu liefern. Ich glaube, ich habe gezeigt, dass es genug Unzufriedenheit gibt, um diese Entscheidung zu öffnen, aber es scheint, dass Microsoft nicht zustimmt, nun, wenn ihre Funkstille ein Hinweis ist.

Hier ist die Frage: Was genau wäre erforderlich, damit MS zugibt, dass sie vielleicht einen Fehler gemacht haben? Was wäre nötig, um sie dazu zu bringen, die Diskussion wieder aufzunehmen? Denn zu diesem Zeitpunkt scheint die Antwort zu lauten: "Ihr Standpunkt ist uns egal, unsere Entscheidung steht und wir werden die Gründe nicht teilen".

Ich würde jedem empfehlen, sich ein bisschen zu entspannen und davon auszugehen, dass hinter diesen Jungs einige kluge Köpfe stehen, die die richtigen Entscheidungen treffen, damit wir langfristig am meisten davon profitieren können

Das ist, was ich gesagt habe, mach es Close Source, weil dahinter clevere Leute stehen und die immer Recht haben und die Open-Source-Community dumm ist.

@shederman "keine statistisch signifikante Stichprobe bereitzustellen" ... das ist in Ordnung, aber ich wünschte, Sie würden die Umfrage einfach für sich allein stehen lassen und diese Zeile entfernen ...

Endgültige Umfrageergebnisse: 100 Antworten, für eine 9 Millionen .NET-Entwicklerpopulation, das sind ±10 % mit 95-prozentiger Konfidenz.

Das ist der Teil, der wirklich brenzlig wird. Es mag richtig sein, dass 60 % der .NET-Entwickler diese Änderung hassen oder nicht mögen; Sie können es jedoch nicht mit diesem Beispiel zeigen. Sagen wir einfach, ja, viele Entwickler haben große Bedenken hinsichtlich der Änderung und der Art und Weise, wie sie gehandhabt wurde. Das ist klar, und die Umfrage unterstreicht diesen Punkt wirklich gut.

@abcplex : Open Source bedeutet nicht, dass Sie jedes Mal springen müssen, wenn 16 Personen ein Problem auf GitHub öffnen und schreien.

@MaximRouiller Die Standup Notes machen einen ziemlich guten Job, um die Motivation für die Änderungen zu erklären. Und die Realität, wie ich es gelesen habe, ist, dass xproj durch csproj ersetzt wird und project.json wahrscheinlich in nuget.json umbenannt wird und _einige_ Sachen aus project.json verschoben werden.

Und nach den Kommentaren im Standup war dies eine ziemlich neue Entscheidung, der Community wurde fast sofort mitgeteilt, dass project.json erst nach RTM nirgendwo hingeht, also könnten sich wieder Änderungen ergeben.

Für mich scheint dies der umfassendste und transparenteste Prozess zu sein, der jemals hätte passieren können.

@darrelmiller Da muss ich dir zustimmen. Ziemlich durchsichtig.

Wenn sie Feedback wollten, glaube ich, dass sie es bekommen haben. Auf jeden Fall ist dagegen nicht anzukämpfen. Die Leute haben gesprochen. Microsoft hat zugehört. Mal sehen, ob sie etwas dagegen tun können oder ob ihnen die Hände gebunden sind.

Nur die Zeit wird es uns jetzt sagen.

Ich glaube nicht, dass das Problem an ihrer Transparenz lag. Sie haben einen großartigen Job gemacht, transparent zu sein. Ich denke, das Problem ist, dass sie wichtige Entscheidungen treffen, ohne zu wissen, was die Community darüber denkt. Ich weiß, dass es unmöglich ist, ein Komitee zu entwerfen, aber vielleicht hätten sie die Pro- und Contra-Liste, die sie durchgegangen sind, dokumentieren und der Community für etwas so Grundlegendes wie diese Änderung vorlegen sollen. Hoffentlich werden sie diese Art von Informationen bald veröffentlichen, aber trotzdem klingt es so, als ob die Entscheidung bereits gefallen ist.

Dies betrifft Early Adopters mehr als alle anderen.

JSON liest sich gut, aber nur, wenn es einfach ist. </system> ist meiner Meinung nach einfacher zu verstehen als ]} .

Die vernünftigsten Kommentare hier spiegeln meine eigenen Gedanken zum Entladen/Laden von Projekten und zum Abhängigkeitsmanagement wider, die nicht die in XML inhärente Ausführlichkeit benötigen.

Sollte es wirklich eine Diskussion über JSON vs. XML sein? Ist IMHO egal
(Sicher, ich persönlich mag JSON mehr als XML, aber das ist nicht wichtig)

Was ich an ASP.NET Core wirklich mag, ist, dass es ziemlich offen und unabhängig von Visual Studio und jeder anderen IDE ist. Wenn dies noch gegeben ist, habe ich mit dieser Entscheidung kein Problem.

Es gibt ziemlich viele giftige Diskussionen zu diesem Thema, die meiner Meinung nach viele Leute aus den Augen verlieren lassen. Das allgemeine Argument scheint zu sein: "MSBuild ist schlecht!" aber es wird nicht genug verstanden, was bei beiden Ansätzen gut/schlecht ist.

Für alle, die sagen, dass dies ein "Rückschritt" ist, sollten Sie sich bewusst sein, dass, obwohl es zu "csproj" zurückgeht, es nicht _die gleichen_ sein wird wie die csproj-Dateien, die wir seit Jahren haben. Zum einen haben sie klar erklärt, dass Sie keine Liste von Dateien im "neuen" csproj-Format sehen werden. Der Hauptvorteil und Hauptgrund, warum die meisten Leute das project.json-Format mögen, liegt darin, dass diese Dateiliste nicht vorhanden ist.

Das ist sofort ein Unterschied. Werfen Sie noch heute einen Blick auf das xproj und Sie werden ziemlich genau wissen, was Sie vom "neuen" csproj erwarten können. Es wird ein bisschen größer sein, aber nur, weil es ein paar zusätzliche Eigenschaften von project.json haben wird. Die eigentliche Diskussion dreht sich nicht und sollte nicht darum gehen, "wie schlecht MSBuild ist", sondern was Sie im neuen csproj sehen möchten und was in einer .json-Datei verbleiben soll.

@dustinmoris du bist unfair, ich denke, die Community hat die meisten Änderungen begrüßt, außer dieser. Dieser führt uns zurück, und sie sprechen bereits darüber, wie sie es tun werden, ohne eine Einsicht in das Warum zu haben. Es klingt so, als ob die Entscheidung endgültig sei, sodass die Community keinen Platz für einen besseren Vorschlag hat.

Und ja, wir bearbeiten Projektdateien direkt und das haben wir vor project.json mühsam gemacht. Bei Msbuild dreht sich alles um Stammeswissen und macht es ein bisschen schwierig, es zu meistern.

Und das "es wird die Migration von .net 4.5 auf .net Core erleichtern" scheint ein bisschen unehrlich. Das ist definitiv nicht der Schmerzpunkt...

es wird nicht dasselbe sein wie die csproj-Dateien, die wir seit Jahren haben.

Wird es XML sein? Ja, das dachte ich mir.

Der Hauptvorteil und Hauptgrund, warum die meisten Leute das project.json-Format mögen, liegt darin, dass diese Dateiliste nicht vorhanden ist.

Aufgrund welcher Informationen sagen Sie das? Ich meine, die Liste der Dateien nicht zu haben, ist ein großes Plus, aber keineswegs das einzige für mich.

Werfen Sie noch heute einen Blick auf das xproj und Sie werden ziemlich genau wissen, was Sie vom "neuen" csproj erwarten können

Ich habe heute keine xprojs. Warum sollte ich so etwas brauchen?

Die eigentliche Diskussion dreht sich nicht und sollte nicht darum gehen, "wie schlecht MSBuild ist"

Warum _sollte das nicht_ die Diskussion sein? Das Turfing von MSBuild war ein wichtiger Pluspunkt für meine Einführung von .NET Core. 20 % der Befragten meiner (anscheinend) unwissenschaftlichen, voreingenommenen Echokammer-Umfrage stimmen zu, dass sie grundlegend gebrochen ist.

@shederman Ihre Antwort ist genau die Art von giftiger Diskussion, auf die ich mich beziehe. Sie machen nur allgemeine Behauptungen (wie "MSBuild ist schlecht!"), aber Sie untermauern sie nicht mit irgendeiner konstruktiven Diskussion.

Wird es XML sein? Ja, das dachte ich mir.

Ja. Und? Wenn Ihr Problem darin besteht, dass Sie _XML_ nicht mögen, dann ist das fair genug. Wenn Sie der Meinung sind, dass JSON XML überlegen ist, können Sie die Gründe dafür auflisten, aber das hat nichts mit der _Projektstruktur_ und alles mit der Syntax zu tun. Leider haben sowohl XML als auch JSON ihren Platz in der Welt, beide haben unterschiedliche Vor- und Nachteile und es wird nie eine definitive "richtige" Antwort geben, was besser ist. Nochmals, an Ihrer Stelle würde ich mich darauf konzentrieren, was die Unterschiede in der _Projektstruktur_ mit dem Umzug sein werden.

Aufgrund welcher Informationen sagen Sie das? Ich meine, die Liste der Dateien nicht zu haben, ist ein großes Plus, aber keineswegs das einzige für mich.

Ich habe nie behauptet, dass es der einzige Vorteil ist, ich habe nur gesagt, dass es bei weitem der _Hauptvorteil_ ist. Schauen Sie sich jede Diskussion über das project.json-Format an, die Monate zurückliegt, und das erste, worüber die Leute sprechen, ist, wie viel kleiner und einfacher es ist. Das liegt nicht daran, dass JSON syntaktisch sauberer ist, sondern daran, dass die Liste der Projektdateien entfernt wurde. Das größte Plus, das die Leute erwähnen, ist, dass es gut zusammengeführt wird und dass es gut zusammenführt, weil es keine Reihe von Dateiverweisen darin auflistet.

Ich habe heute keine xprojs. Warum sollte ich so etwas brauchen?

Diese ganze Diskussion dreht sich um das neuere Projektdateiformat. Wenn Sie nicht bereit sind, die aktuelle Landschaft zu vergleichen, wird Ihre Meinung uninformiert sein.

Warum sollte das nicht die Diskussion sein? Das Turfing von MSBuild war ein wichtiger Pluspunkt für meine Einführung von .NET Core. 20 % der Befragten meiner (anscheinend) unwissenschaftlichen, voreingenommenen Echokammer-Umfrage stimmen zu, dass sie grundlegend gebrochen ist.

Da Sie nicht wirklich über _MSBuild_ sprechen, diskutieren Sie die Art und Weise, wie Visual Studio in der Vergangenheit MSBuild-Projekte behandelt hat – was Microsoft selbst zugegeben hat, ist schlecht. MSBuild unterstützt eigentlich bereits fast alles, was erforderlich ist – einschließlich der Notwendigkeit, nicht jede einzelne Datei in einem Projekt aufzulisten.

Genauer gesagt, alles, was Sie bisher in dieser Diskussion getan haben, ist zu schreien und zu schreien, dass Sie XML nicht mögen, aber ich habe noch keine wirklichen Argumente für oder gegen über "Es fügt sich einfach nicht als" well", was, wie ich jetzt schon mehrfach erwähnt habe, im Allgemeinen auf die Anzahl der Dateien zurückzuführen ist, die in einem "alten" csproj aufgelistet sind. Wenn Sie sich die Mühe gemacht hätten, sich das xproj-Format anzuschauen, würden Sie feststellen, dass es ziemlich klein ist und Daniel sagte während des Standups, dass das "neue" csproj-Format ungefähr die gleiche Größe wie die aktuelle Datei project.json haben würde - also noch einmal, was ist? das Problem? Sie stellen kühne Behauptungen, aber Sie unterstützen sie überhaupt nicht.

@neoKushan Sie sollten bald eine Art Auszeichnung von Microsoft erhalten, indem Sie sie ohne triftigen Grund verteidigen. Kommen Sie zu dem Punkt, dass dies die schlechteste Entscheidung ist, die in Hintertüren getroffen wird. Ich empfehle, das Asp-Netz wieder zu schließen und Microsoft und ihren Unterstützern wie Ihnen zu erlauben, zu entscheiden, was sie dann wollen, ohne die Mitglieder der Open-Source-Community zu fragen

@abcplex Werden Sie etwas anderes als

Bisher haben Sie sich nur über die Änderung beschwert, ohne einen einzigen Grund anzugeben, was Ihr eigentliches Problem damit ist.

@neoKushan Der größte Punkt ist, dass es nicht die Zeit für diese Art von Änderung ist, erst vor einem Monat zu RTM. Diese Änderung zu diesem Zeitpunkt macht keinen Sinn.

@abcplex Die Änderung findet bei RTM nicht statt. Es wird eine schrittweise Änderung nach RTM sein . Alles, was bei RTM passiert, ist, dass Ihr xproj in csproj umbenannt wird - buchstäblich nichts anderes ändert sich und Änderungen werden schrittweise vorgenommen, wobei die Tools Ihre Änderungen für Sie migrieren.

Stimmen Sie zu, dass JSON vs XML (vs XAML, wie im Standup-Blogpost einige Leute danach fragen) eine Ablenkung von den Vorteilen einer Abwärtskompatibilität mit den vorherigen Tools sein sollte.

Und ich würde argumentieren, dass dies eine sehr fehlgeleitete Denkweise ist. Ob es Ihnen gefällt oder nicht, csproj und MSBuild folgen der Tradition von ant, bei der es darum geht, die Toolchain anzuweisen, wie ein Projekt erstellt wird, anstatt es zu definieren. Dies sind sehr unterschiedliche Dinge, aber dieses Erbe scheint dem Projekt "Definitionskraft" zu verleihen, weil wir jetzt Logik darauf anwenden können und so weiter. Das macht die Dinge unglaublich kompliziert.

In der alten Welt habe ich bei zahlreichen Gelegenheiten gesehen, dass Projektdateien beschädigt wurden, einfach weil eine Zeile, die "ganz unten sein musste", nach oben verschoben wurde oder jemand mit einer Umgebungsvariablen herumgespielt hatte und plötzlich zogen wir die falsche .targets-Datei ein. Die bloße Vorstellung, dass ein Element der ersten Ebene (Kind der Wurzel) in einer deklarativen Syntax reihenfolgeabhängig ist, ist völlig gebrochen. Das ist das Land von MSBuild und csproj. Dies ist das Erbe, das wir hierher zurückbringen. Um nun ein csproj zu verstehen, muss man es "ausführen" und es genau so ausführen, wie es MSBuild tun würde. Ja, MSBuild ist Open Source, aber das behebt nichts. Es führt immer noch eine einzelne, erzwungene Abhängigkeit ein. Es verlässt sich immer noch auf Dateien mit magischen Zielen, die irgendwo sitzen.

Eine Projektdatei sollte mehrere Eigenschaften haben, die sie unabhängig von der Form der Toolchain machen, die ein bestimmter Shop verwendet:

• Es sollte von Menschen editierbar/lesbar sein
• Es sollte Kommentare zulassen
• Es sollte deklarativ sein
• Es sollte in sich geschlossen sein
• Es sollte so gestaltet sein, dass Zusammenführungskonflikte reduziert / Zusammenführungen vereinfacht werden, wenn möglich
• Es sollte vollständig dokumentierbar sein (wobei das Prinzip der Eigenständigkeit für die Dokumentation gilt)
• Es sollte werkzeugunabhängig sein

Und das "es wird die Migration von .net 4.5 auf .net Core erleichtern" scheint ein bisschen unehrlich. Das ist definitiv nicht der Schmerzpunkt...

100 % zugestimmt. Lassen Sie mich klarstellen, was die Herausforderungen für uns waren: Die einzigen Schwierigkeiten bei der Migration von Codebasen waren bisher der Verlust bestimmter .NET-Klassenbibliotheken (mit Blick auf System.Drawing), die Zurückhaltung der Microsoft-Teams bei der Unterstützung des .NET-Kerns (mit Blick auf Ihre DocumentDB) und die standardmäßigen Breaking Changes, die zwischen den Hauptversionen zu erwarten sind.

Project.json war zu keinem Zeitpunkt ein Problem. Tatsächlich war das einer der Vorteile. Ebenso die Möglichkeit, MSBuild in ein unsichtbares Detail zu verschieben, das auf magische Weise passiert, wenn Strg+Umschalt+B gedrückt wird.

@neoKushan

1. Ich mag XML nicht. Es ist ein schlechtes Format für Projekt- und Konfigurationsdateien. Es war eine schlechte Idee, als es während der "XML for Everything"-Phase eingeführt wurde, und es ist jetzt eine schlechte Idee.
2. Ich finde, dass JSON-Dateien viel besser zusammengeführt werden als XML-Dateien. Ich akzeptiere, dass dies eine Meinung ist, aber es ist meine und basiert auf meinen Erfahrungen.
3. Ich verwende vscode, das keine xproj-Dateien benötigt und nicht verwendet. _Das_ ist meine aktuelle Landschaft, und ich will oder brauche keine xproj-Datei, die mir nichts bedeutet.
4. Nein, ich bespreche MSBuild. Ich habe viele Dinge mit MSBuild und Team Build gemacht. Sie haben nie Spaß gemacht und waren nie einfach und haben immer mit dem Schwein im Schlamm gerungen. Ich _hasse_ MSBuild, und ich bin ganz sicher nicht allein.
5. MSBuild macht selbst einfache Aufgaben schwierig. Ich schlage vor, dass Sie sich Alternativen ansehen und sich nicht von MSBuild abschrecken lassen. Schauen Sie sich vor allem an, wie Schluck und sbt funktionieren.

@shederman

Ich mag XML nicht. Es ist ein schlechtes Format für Projekt- und Konfigurationsdateien. Es war eine schlechte Idee, als es während der "XML for Everything"-Phase eingeführt wurde, und es ist jetzt eine schlechte Idee.

Nichts davon erklärt, _warum_ es eine schlechte Idee ist.

Ich finde, dass JSON-Dateien viel besser zusammengeführt werden als XML-Dateien. Ich akzeptiere, dass dies eine Meinung ist, aber es ist meine und basiert auf meinen Erfahrungen.

Ich hatte Alptraum-.json-Zusammenführungen und Alptraum-.xml-Zusammenführungen, ich bin auch nicht besonders beliebt, wenn es um Zusammenführungen geht. Nach meiner Erfahrung steigt die Wahrscheinlichkeit einer problematischen Zusammenführung mit der _Größe_ der Datei, unabhängig vom Format.

Ich verwende vscode, das keine xproj-Dateien benötigt und nicht verwendet. Das ist meine aktuelle Landschaft, und ich will oder brauche keine xproj-Datei, die mir nichts bedeutet.

Das bedeutet nicht, dass Sie sich nicht die aktuelle xproj-Datei ansehen können , um eine Vorstellung davon zu bekommen, was es ist. Indem Sie dies nicht tun, tun Sie das Gleiche, indem Sie sich die Finger in die Ohren stecken, die Augen schließen und "La la la" sagen.
Anders ausgedrückt: Sie können sich darüber aufregen, dass eine Veränderung stattfindet, und darüber jammern, nichts erreichen, oder Sie können sich am eigentlichen Gespräch beteiligen und das Ergebnis mitbestimmen.

Eine Sache, die zum Beispiel noch unentschieden ist, ist, ob die Nuget-Abhängigkeiten Teil des csproj werden oder ob es nuget.json wird - da ist Ihre Präferenz genau dort. Wenn Sie Ihre Abhängigkeitslisten in einer .json-Datei haben, was bleibt im csproj übrig? Wie oft wird sich das ändern? Wie schwierig wird _das_ zu fusionieren sein?

Ich persönlich würde es vorziehen, wenn alles in einer einzigen Projektdatei enthalten wäre, aber ich sehe den Reiz und die Vorteile der Trennung von Nuget vom Projekt selbst. Beides hat Vor- und Nachteile und die vielleicht beste Lösung besteht darin, beides zuzulassen, ein csproj mit einer Liste von Abhängigkeiten zu erstellen, aber stattdessen auch auf eine .json-Datei mit Ihren Abhängigkeiten verweisen zu lassen. Das Beste aus beiden Welten und jeder gewinnt, auf Kosten einer zusätzlichen Komplexität von MSbuild selbst.

Nein, ich bespreche MSBuild. Ich habe viele Dinge mit MSBuild und Team Build gemacht. Sie haben nie Spaß gemacht und waren nie einfach und haben immer mit dem Schwein im Schlamm gerungen. Ich hasse MSBuild und bin ganz sicher nicht allein.

Nachdem ich mich mit den XAML-basierten Build-Definitionen von TFS auseinandersetzen musste, kann ich Ihnen zumindest bei (einigen) dieser hier zustimmen.

MSBuild macht selbst einfache Aufgaben schwierig. Ich schlage vor, dass Sie sich Alternativen ansehen und sich nicht von MSBuild abschrecken lassen. Schauen Sie sich vor allem an, wie Schluck und sbt funktionieren.

Dann schlage ich vor, dass Sie aufhören, Ihre Spielsachen aus dem Kinderwagen zu werfen, und sich aktiv an der Diskussion darüber beteiligen, wie die "neue" Projektstruktur _eigentlich_ aussehen soll. Stellen Sie sich eine Zukunft vor, in der Sie mit einer XML-basierten Projektdatei arbeiten müssen. Wie soll diese Projektdatei tatsächlich aussehen?

Stellen Sie sich eine Zukunft vor, in der Sie sich mit einer XML-basierten Projektdatei befassen müssen

Äh. Okay, also muss ich mir eine Zukunft vorstellen, die ich nicht will und dir erklären, wie das geht? Ähm, nein, das glaube ich nicht. Wie wäre es, wenn wir uns lieber einige moderne, innovativere Build-Systeme ansehen. wissen Sie, diejenigen, die XML in der fernen Vergangenheit hinterlassen haben.

Wie wäre es mit:

var gulp = require('gulp')
, minifyCss = require("gulp-minify-css");

gulp.task('minify-css', function () {
    gulp.src('./Css/one.css') // path to your file
    .pipe(minifyCss())
    .pipe(gulp.dest('path/to/destination'));
});

Oder vielleicht

organization := "com.devdaily"

name := "ScalatraTest1"

version := "0.1.0-SNAPSHOT"

scalaVersion := "2.9.1"

seq(webSettings :_*)

libraryDependencies ++= Seq(
  "org.scalatra" %% "scalatra" % "2.0.4",
  "org.scalatra" %% "scalatra-scalate" % "2.0.4",
  "org.scalatra" %% "scalatra-specs2" % "2.0.4" % "test",
  "ch.qos.logback" % "logback-classic" % "1.0.0" % "runtime",
  "org.eclipse.jetty" % "jetty-webapp" % "7.6.0.v20120127" % "container",
  "javax.servlet" % "servlet-api" % "2.5" % "provided",
  "com.mongodb.casbah" %% "casbah" % "2.1.5-1"
)

resolvers += "Sonatype OSS Snapshots" at "http://oss.sonatype.org/content/repositories/snapshots/"

Oh ja, das xproj, das du verlinkt hast, ist so viel besser. Schön und klar und prägnant. Und ausdrucksstark, ausdrucksstark nicht vergessen. Wozu dient dieser ProjectGuid? Und ich liebe die 90 Zeichen, um die Tool-Version einzustellen. Und der DnxInvisibleContent? Das ist für mein Build- System nützlich zu wissen? Welche Dateien sollen nicht in der IDE angezeigt werden, die ich nicht ausführe?

Ich schlage vor, du hörst auf, deine Spielsachen aus dem Kinderwagen zu werfen

Will nicht :-)

Nee, ich bin fertig. Ich habe mich lange mit Immo unterhalten und ich bin über diesen Kampf hinweg. Jeder hat seine Teilansichten und niemand will sich das abscheuliche Konzept anhören, dass sein Weg nicht für jeden perfekt ist.

[Bearbeitet, um Gereiztheit zu entfernen]

@shederman : Sie zeigen hier Build- Definitionsdateien an; Ich möchte weg von Build-Definitionen als Projektdefinition. Es gibt Platz zum Definieren der statischen Details über ein zu generierendes Projekt/Artefakt, unabhängig von den Anweisungen zu seiner Generierung. Die Verschmelzung der beiden ist eines der Hauptprobleme bei der Verwendung von MSBuild-Dateien als Projektdateien.

Ich möchte in der Lage sein, nur die Informationen anzugeben, die erforderlich sind, um die zu generierenden Artefakte und die zu verwendenden Abhängigkeiten und Toolchains sowie das Layout der verschiedenen Elemente, aus denen das Projekt auf der Festplatte besteht, zu beschreiben. Alles andere sollte getrennt sein. Wenn Sie MSBuild unter der Haube verwenden möchten, fahren Sie gleich fort. Dito, wenn Sie Schluck oder Babel oder was-haben-Sie bevorzugen. Für mich ist das, was project.json gemacht wurde. (Ich war jedoch kein Fan von der Möglichkeit, dort Befehle zu definieren)

Ja, das macht Sinn. Das war eines der Dinge, die mir an project.json gefallen haben. Es definierte das „Was“, nicht das „Wie“. Indem wir zu viele Dinge in eine Datei packen, machen wir die Datei zu komplex, besonders wenn unsere IDE dumm ist. Und dieses Zeug wird für Editoren und einfache IDEs nicht benötigt.

Von einer Benutzeroberfläche mit geringer Zeremonie wie VS Code aus ist kein Projektsystem erforderlich. Es ist alles gebaut. Vieles davon ist deklarativ und sagt aus, was gebaut werden soll und Metadaten. Einige können zwingend erforderlich sein und sagen, welche Schritte durchgeführt werden sollten.

Ja, das größte Problem von MSBuild ist, dass es versucht, alles in einem System zu erledigen.

Ich vermute, was ich nicht verstehe, ist Folgendes: Zeigen Sie mir einige Anwendungsfälle, die durch die Verwendung von MSBuild als Projektsystem verbessert werden, anstatt nur project.json zum Laufen zu bringen. Ich sehe es nicht. Vielleicht sind meine Anwendungsfälle zu einfach, also zeig mir welche.

@shederman In den Standup-Notizen wird erwähnt, dass

Also... dies ist ein Open-Source-Projekt, und ich weiß, dass Microsoft "die Mächtigen" ist, aber wenn dies für die Leute so wichtig ist, dann - und ich verstehe, dass ich hier eine ignorante Frage stelle - wie viel Zeit? /effort/energy müsste aufgewendet werden, damit .NET Core weiterhin project.json als Alternative zu MSBuild verwenden kann? Wenn genügend Leute dazu beitragen und der Code gut genug ist, warum sollte MS ihn dann nicht in dieses Projekt aufnehmen? Ein Teil der Schönheit (und des Untergangs) von Open Source ist die Androhung des Forkens des Codes, wenn der oder die primären Betreuer zu viel von dem ablehnen, was von anderen angeboten wird. Ein Teil des Codes, der Open Source ist, ist nicht nur anzusehen, sondern zu modifizieren und zu verbessern.

Meine persönliche Meinung zu der Änderung ist, dass sie mit Xamarin zu tun hat, da es um Zukunftspläne geht. Ich glaube, ich habe sie in den letzten Stand-ups auch sagen hören, dass sie wollen, dass Konsolen-Apps ein erstklassiger Bürger sind. Denken Sie daran, dass sich das neue .NET (ASP.NET 5 + DNX) ursprünglich auf das Erstellen von Webanwendungen konzentrierte, jetzt geht es um mehr. All dies geschah vor relativ kurzer Zeit, die .NET- und ASP.NET-Teams fusionierten und auch der Kauf von Xamarin. Sie kamen zu dem Schluss, dass sie ein besseres Projektsystem benötigen, um diese vielfältigen Szenarien (und neue Zukunftsszenarien, über die ich hier nicht spekuliere) zu unterstützen, und sie wollen auch .NET Core bald ausliefern. Was ist zu tun? Ignorieren Sie das bereits vorhandene MSBuild, das bereits die Anforderungen erfüllt, vollständig und beginnen Sie von vorne? Entschuldigung, ich kenne den Weg, den ich wählen würde.

Ein Großteil der Bedenken scheint das Zusammenführen zu sein, ABER wenn die Projektdatei nicht die Namen der Dateien im Projekt enthält und wenn die Abhängigkeiten in eine separate Konfigurationsdatei verschoben werden, sollte das Zusammenführungsproblem verschwinden, da sich die Projektdateien dann ändern sollten relativ selten.

Nur meine Meinung

Das Zusammenführungsproblem ist nur ein Problem. Von MSBuild wegzukommen ist eine andere. Ein verrücktes Ergebnis dieses Szenarios ist, dass sie jetzt Zeit und Mühe darauf verwenden werden, MSBuild auf Linux und OSX zu portieren! Stell dir das vor.

Ich verstehe ihre Gründe, aber ihre Gründe funktionieren bei mir überhaupt nicht und bei vielen Menschen nicht. Wir haben Investitionen auf der Grundlage fester Zusicherungen bezüglich der Richtung getätigt, die sie eingeschlagen haben, und sie sind ohne Verantwortung darauf zurückgegangen und nur ein Hinweis darauf, dass sie die Entscheidung vielleicht besser _kommunizieren_ hätten sollen. Sie treffen eine Entscheidung für project.json basierend auf den von MSBuild unterstützten Randfällen und der Schwierigkeit, diese Randfälle zu unterstützen. Nun, das bedeutet, dass es _niemals_ aufhören wird, verwendet zu werden, weil niemand, der bei klarem Verstand ist, all diese Randfälle unterstützen würde. Sicherlich braucht niemand, der ASP.NET-Projekte durchführt, diese Randfälle.

Forking ist eine Möglichkeit, aber angesichts der Größe und Integration von allem ist es eine entmutigende Aussicht, überhaupt in Erwägung zu ziehen, den entsprechenden Code zu lernen . Die Realität ist, dass dies nicht wirklich ein Open-Source-Projekt ist, sondern ein Microsoft-Projekt, und sie haben ohne unseren Beitrag eine Unternehmensentscheidung getroffen, und wir müssen sie einfach aufsaugen und akzeptieren. Mir wurde klar gemacht, dass es im Grunde keine Möglichkeit gibt, dass sie es _jemals_ noch einmal überdenken, egal, welchen Widerstand es gab.

Es ist also entweder der Aufwand, den wir aufwenden und das Build-System project.json abzweigen, oder wir wechseln zu einem anderen Build-System (FAKE?), oder Sie saugen es auf oder verwenden eine andere Plattform. Ich glaube, ich habe alle Auswahlmöglichkeiten dort aufgezählt.

@shederman MSBuild ist seit Anfang 2015 Open Source und die Builds geben OSX/Ubuntu weiter, daher denke ich, dass es nicht so viel Arbeit ist, wie Sie vielleicht denken, um zu portieren (https://github.com/Microsoft/msbuild) , beim Durchsuchen des Repositorys sieht es zum Beispiel so aus, als ob OSX im März in Ordnung war.

Ach je. Ich mache mir Sorgen, ob wir das _sollten_, und sie haben es getan...

Fühlen Sie sich ein wenig wie jemand, der Frankensteins Monster in die Ferne rast. Interessiert, fasziniert, besorgt und mehr als nur angeekelt :-)

@darrelmiller In den Standup-Notizen wird erwähnt, dass

Wirklich? Machen die Leute das immer noch? Ich meine, ich habe es für AssemblyInfo.cs gemacht, und im Mittelalter haben wir unseren Strong Name-Schlüssel in eine freigegebene Quelldatei gelegt.

Okay, das ist ein Anwendungsfall, aber jetzt möchte ich wirklich einen Anwendungsfall für den Anwendungsfall hören. Fasziniert.

@shederman

Äh. Okay, also muss ich mir eine Zukunft vorstellen, die ich nicht will und dir erklären, wie das geht? Ähm, nein ich glaube nicht

Alles, was Sie tun müssen, ist XML anstelle von JSON zu akzeptieren, um zu sehen, welche Vorteile es haben könnte, aber Sie sind nicht bereit, dieses Spiel zu spielen, weil Sie nur darüber sprechen möchten, wie schlecht XML ist, ohne den Grund dafür anzugeben.

Ach je. Ich mache mir Sorgen, ob wir das tun sollten, und sie sind losgezogen und haben es getan...

Sie sind jetzt buchstäblich _Jahre_ lang "abgegangen und machen es". Sie haben vor Jahren über Open-Sourcing von .net gesprochen, sie haben Roadmaps gegeben und deutlich gemacht, dass es letztendlich darum geht, auf jeder Plattform für jeden Anwendungsfall zu laufen.

Sie sind ziemlich verärgert über diese Änderung und ich vermute, dass die Mehrheit der Leute, die über die Änderung verärgert sind, alle Webentwickler sind, aber das ist nur ein kleiner Teil des .net-Ökosystems, es gibt ein riesiges Ökosystem von Service-, Mobil- und Cloud-Entwicklern mit riesigen Codebibliotheken, die auf .net Core portiert werden sollen. Ob es Ihnen gefällt oder nicht, project.json funktioniert derzeit einfach nicht für alle diese Modelle. Sie sagen "mach es zum Laufen", aber Sie werden am Ende mit einer anderen unordentlichen Projektdatei enden, außer einer, die keine offensichtliche und klar definierte Struktur hat und - schlimmer noch - keine Kommentare. Dieser letzte Punkt ist Grund genug, um project.json zu überdenken.

Oh ja, das xproj, das du verlinkt hast, ist so viel besser. Schön und klar und prägnant. Und ausdrucksstark, ausdrucksstark nicht vergessen.

Zumindest hast du es dir endlich angeschaut. Es brauchte nur was, 72 Kommentare in dieser Ausgabe, bevor Sie sich überhaupt die Mühe gemacht haben? Ich sage Ihnen das immer wieder, aber Sie verstehen es nicht: Anstatt sich darüber zu beschweren, wie schrecklich MSBuild ist, sprechen Sie darüber,

Das Zusammenführungsproblem ist nur ein Problem. Von MSBuild wegzukommen ist eine andere.

Warum ist das überhaupt ein Thema? Sie hassen MSBuild, das verstehen wir, aber was hassen Sie an MSBuild, abgesehen davon, dass es _wagt_, XML zu verwenden?

Ein verrücktes Ergebnis dieses Szenarios ist, dass sie jetzt Zeit und Mühe darauf verwenden werden, MSBuild auf Linux und OSX zu portieren! Stell dir das vor.

Du hast recht! Das wird schrecklich sein, jede Art von .net-App auf jeder gewünschten Plattform und mit jeder gewünschten IDE entwickeln zu können. Denk an die Kinder!
Wie kann Microsoft es wagen, Zeit damit zu verbringen, seine Arbeit zu öffnen und seine Tools auf andere Plattformen zu portieren, anstatt in seine eigene Closed-Source-Technologie zu investieren?

Ich verstehe ihre Gründe, aber ihre Gründe funktionieren bei mir überhaupt nicht und bei vielen Menschen nicht.

Aber vielleicht arbeiten sie für viel mehr Leute als Sie?

Wir haben Investitionen auf der Grundlage fester Zusicherungen bezüglich der eingeschlagenen Richtung getätigt, und sie sind ohne Verantwortung darauf zurückgegangen und nur ein Hinweis darauf, dass sie die Entscheidung vielleicht besser hätten kommunizieren sollen.

Auf welche _Richtung_ beziehen Sie sich? Das Ziel war immer überall .net. "Jeder Entwickler, jede App, jede Plattform" ist das Mantra des Tages und an dieser Änderung ändert sich absolut nichts. Sie haben klar erklärt, dass ihr Ziel darin besteht, die Projektdatei klein, einfach, für Menschen lesbar und ohne IDE bearbeitbar zu halten. Ihnen wird nichts weggenommen. Sie müssen sich vielleicht mit ein bisschen XML auseinandersetzen, Big Whoop, wenn das bedeutet, dass .net ein erstklassiges Erlebnis für Mobile, Cloud und Web ist, dann lohnt es sich.

Sie treffen eine Entscheidung über project.json basierend auf Randfällen, die MSBuild unterstützt

Dies geht weit über _edge_-Fälle hinaus, es ist lächerlich, auch nur zu behaupten, dass project.json fast perfekt ist.

Sicherlich braucht niemand, der ASP.NET-Projekte durchführt, diese Randfälle.

Ich nehme an, dies ist der Kern des Problems: Sie interessieren sich für niemanden außer sich selbst, einem asp.net-Entwickler. Fair genug, aber ich würde Ihnen noch einmal sagen: Akzeptieren Sie, dass andere Entwickler wichtig sind, und arbeiten Sie daran, es zum bestmöglichen System zu machen, anstatt nur die Arme zu heben. Das bedeutet nicht , sich eine beliebige Syntax für ein völlig anderes Markup auszudenken, sondern zu akzeptieren, dass das Bild größer ist als nur Sie selbst und mit anderen zusammenzuarbeiten, um es für alle großartig zu machen.
Wie ich immer wieder sage, was bleibt übrig, wenn nuget.json alle Ihre Abhängigkeiten auflistet? Was ist das Problem beim Definieren einiger ziemlich statischer Felder in benannten XML-Elementen?

Die Realität ist, dass dies nicht wirklich ein Open-Source-Projekt ist

Wie andere gesagt haben, bedeutet Open Source nicht, sich vor ein paar Nörglern zu beugen. Sie akzeptieren Pull-Requests, schreiben etwas Besseres.

Wenn man bedenkt, wie groß und integriert alles ist, ist es eine abschreckende Aussicht, überhaupt in Erwägung zu ziehen, den entsprechenden Code zu lernen.

Okay, im Grunde lese ich das so: "Ich verstehe das Gesamtbild nicht und ich möchte das Gesamtbild nicht verstehen, aber ich werde mich trotzdem beschweren, weil es meine kleine Blase betrifft, ohne die Auswirkungen zu berücksichtigen meine Blase hat auf anderen".

Es ist also entweder der Aufwand, den wir aufwenden und das Build-System project.json abzweigen, oder wir wechseln zu einem anderen Build-System (FAKE?), oder Sie saugen es auf oder verwenden eine andere Plattform. Ich glaube, ich habe alle Auswahlmöglichkeiten dort aufgezählt.

Oder ... und ich meine, das ist nur ein verrückter, unkonventioneller Gedanke, aber Sie könnten versuchen, tatsächlich etwas Konstruktives zu dem Gespräch beizutragen.

Zurück zum Thema....

Ich habe mehr darüber nachgedacht und tendiere jetzt dazu, aus project.json nuget.json zu machen, wobei das Abhängigkeitsmanagement weitgehend so bleibt, wie es jetzt ist. Es funktioniert jetzt gut, der Intellisense ist bereits drin und stimmt mit Dingen wie gulp und npm überein.

Lassen Sie das csproj einfach die statischen Teile definieren.

Der Nachteil dieses Ansatzes ist jedoch, dass ich nicht sicher bin, wie gut das bei der Ausrichtung auf mehrere Frameworks funktionieren würde muss es noch wissen.

project.json ist nicht nur eine JSON-Datei.
csproj ist nicht nur eine XML-Datei.

IMHO waren viele Leute wie ich aufgeregt, Microsoft zu sehen, genauer gesagt das Asp.Net-Team,
sich von sehr altem Legacy-Code/Konzepten/Systemen/Tools/Auftritten/...

Das hat uns „Hoffnung“ gemacht!

Ich entwickle Asp.Net seit den ersten Preview-Bits. Am liebsten arbeite ich damit. Aber nach 15 Jahren
das 'alte' Zeug, wie XML, fühlt sich wirklich, wirklich schwer und veraltet an. Wahrnehmung IST wichtig.

Ohne XML und zumindest mit JSON ist meine „Entwicklerglück“ viel größer.
Ich kann mit Dingen arbeiten, die der Rest der Welt verwendet hat. Meine IDE bevorzugt diese Dinge gegenüber älteren Formaten.
Ich muss die „Angle Bracket Tax“ nicht mehr bezahlen.

Das Entfernen von project.json ist keine große Sache, aber es fast im letzten Moment hinter verschlossenen Türen zu tun, tötet diese "Hoffnung" sofort.

Plötzlich fühlt sich das nicht mehr wie ein Open-Source-Projekt an.

Zur Info: "Asp.Net Core" hat viele fantastische Funktionen. Ich liebe es meistens.
Das Asp.Net-Team ist großartig und ich könnte nicht stolzer sein, ein Asp.Net-Entwickler zu sein.

Aber ich bin verletzt. Vielleicht bin ich nicht der einzige.

Nur meine 2 Cent.

Ich denke, wir sind uns fast alle einig, dass msbuild (insbesondere wie VS es verwendet) nicht perfekt ist, und während ich von project.json begeistert war, ging es mehr darum, dass MS viele meiner Schwachstellen behebt und ehrlich gesagt so lange Sie tun es. Ich werde mich wahrscheinlich nicht so darum kümmern, wie sie es gemacht haben.

• csproj-Zusammenführungen funktionieren nicht so gut, ich muss jede zweite Woche eine fehlerhafte Zusammenführung manuell reparieren. Das Entfernen der Dateiliste aus dem csproj würde hier sehr hilfreich sein.
• NuGet-Referenzen und Projektreferenzen stimmen nicht immer überein, was wiederum an fehlerhaften Zusammenführungen liegen könnte. So oder so ist es ärgerlich zu diagnostizieren und zu korrigieren.
• Gelegentlich muss ich mich in den Build-Prozess einklinken (nicht sicher, wie das in project.json funktionieren sollte), aber die ganze Notwendigkeit zum Entladen / Laden macht das Debuggen des Build-Skripts zu einem schmerzhaften Prozess.

Wenn sie einen Weg finden, diese 3 Elemente zu reparieren, würde ich mich wahrscheinlich nicht so sehr über csproj-Dateien beschweren.

@neoKushan

Alles, was Sie tun möchten, ist, darüber zu sprechen, wie schlecht XML ist, ohne den Grund dafür anzugeben

Nicht ganz fair, ich möchte auch darüber sprechen, wie schlecht MSBuild ist :-)

Ich bin mir sicher, dass ich tatsächlich gesagt habe, warum ich XML für Build-Dateien nicht mag, aber lassen Sie mich es noch einmal versuchen. XML ist ausführlich, es ist hässlich, es ist besser für Werkzeuge als für Handbearbeitung, und ich genieße die Erfahrung, es zusammenzuführen. Es wurde für MSBuild verwendet, weil die Industrie damals dachte, XML könne für alles verwendet werden. Seitdem sind wir weitergezogen. Nun, an manchen Stellen.

noch schlimmer - keine Kommentare

Ich glaube, mehrere Leute haben hier Alternativen angeboten. HJson ist nur eine Option. Yay! Wir müssen es doch nicht umdenken ;-)

Du bist ziemlich verärgert über diese Änderung

Um fair zu sein, bin ich meistens verärgert darüber, wie diese Änderung in einem geschlossenen Raum vorgenommen wurde, ohne die Community zu berücksichtigen oder mit ihr in Kontakt zu treten, die die vorherige, sehr feste Unterstützung für project.json für bare Münze genommen hatte. Junge, werde diesen Fehler nicht noch einmal machen!

Versteh mich nicht falsch, mag XML nicht, mag MSBuild nicht. Aber ich hasse es, wenn man mir sagt, ich solle etwas adoptieren, das ich wirklich liebe, und dann in letzter Minute gesagt wird, dass es weggenommen wird. Bewegen Sie meinen Käse nicht!

Ich vermute, dass die Mehrheit der Leute, die über die Änderung verärgert sind, alle Webentwickler sind

Ähm, ja, das liegt daran, dass sie die einzigen Entwickler sind, denen Sie project.json angeboten haben. In anderen Nachrichten sind die Swift-Entwickler auch nicht verärgert über die Entscheidung. Ich meine, denk mal, was du hier sagst:

1. Nur Webentwickler haben diese neue Funktion
2. Viele von ihnen waren wirklich sauer, als wir es weggenommen haben
3. Niemand sonst darf es benutzen
4. Die Leute, die es nicht benutzt haben, sind nicht verärgert, dass es weggenommen wurde
   ergo alle anderen devs würden es nicht wollen.

Ich denke, Sie müssen sich die Qualität Ihres Denkens ansehen, und das habe ich lange Zeit versucht, zu befragen, und bin zu keinem Ergebnis gekommen. Das Fehlen von Informationen über das Denken und die Tatsache, dass sich die betroffenen Parteien zusammengetan haben, deutet für mich darauf hin, dass das Denken möglicherweise verdächtig war.

Und was meinst du mit "Webentwickler"? Sie denken an eine kleine Website für ein kleines Unternehmen? Wie wäre es mit einem Stapel von Microservices, die ein Asset-Management-Unternehmen mit einem verwalteten Vermögen von mehreren zehn Milliarden Dollar unterstützen. Natürlich gibt es dort auch eine Website. Aber das sind etwa 10 % des Systems. Oh, und ja, es ist tatsächlich auch auf die Cloud ausgerichtet, also sprechen wir vielleicht tatsächlich von "Cloud-Entwicklern".

Es hört sich so an, als ob Sie nicht einmal verstehen, wie die Technologie, über die Sie vorschnelle Entscheidungen treffen, verwendet wird oder von wem.

Was hassen Sie an MSBuild, abgesehen davon, dass es es wagt, XML zu verwenden?

Es ist zu kompliziert
Es handelt sich um eine Impedanz-Fehlanpassung, die inferenzbasierte Logik in Situationen schiebt, in denen Menschen hauptsächlich mit zwingender oder deklarativer Logik zu tun haben.
Mein Gott, haben Sie sich die MSBuild-Dateien tatsächlich _gesehen_? Okay, sorry, du hast gesagt, außer XML zu verwenden ;-)
Die Art und Weise, wie Eigenschaften und Gegenstände deklariert werden, ist für jeden, der sie nicht regelmäßig verwendet, kontraintuitiv
Es wird als One-Size-Fits-All-Tool verwendet, das versucht, Aufgaben zu erledigen, die in Skripten erledigt werden sollten. Hammer Nägel.
In vielen Fällen könnte alles, was es in einer großen Datei tut, in höchstens 3 Zeilen Skript ausgedrückt werden
Der VS-Müll, der hineingespuckt wird. Ich habe gehört, das wird behoben. Warten mit einiger Beklemmung, um zu sehen, ob das auch geschnitten wird. Wie oben erwähnt, bin ich jetzt ein bisschen schüchtern, was Versprechen angeht.

Was liebst du so sehr? Und vor allem: Sind Sie bereit zu akzeptieren, dass andere Ihre Ansichten nicht teilen? Wenn ja, können Sie zugeben, dass "one size fits all" möglicherweise nicht der richtige Ansatz ist?

Welche Richtung meinst du

project.json ist die Basis unseres neuen Projektansatzes wurde kommuniziert. Aufgrund dieses Engagements haben wir viel Geld, Zeit und Mühe investiert.

Aber vielleicht arbeiten sie für viel mehr Leute als Sie?

Vielleicht tun sie es tatsächlich. Aber wenn ja, wo sind die Beweise dafür? Ich habe versucht, das Denken und die Entscheidungsfindung und die Beweise, die dabei verwendet wurden, zu befragen, und ich bekomme von niemandem etwas. Für alle Beweise, die geliefert wurden, hätten Sie nach allem, was wir wissen, einen Magic 8-Ball schütteln können.

Niemand weiß, wie viele so oder so denken. Ich bin eigentlich der einzige, den ich kenne, der versucht hat , es herauszufinden.

Sie interessieren sich für niemanden außer sich selbst, einem asp.net-Entwickler

Nicht sehr nett. Was ich eigentlich sage ist, dass die Behauptung ist, dass die neue Richtung für alle Anwendungsfälle funktioniert, und ich hebe meine Hand und sage, dass es für mich nicht funktioniert. Sie sind diejenige, die mit rauen Schuhen über alle Widerstände hinweg reitet. Ich bin derjenige, der die Leute fragt, was sie denken, MS nicht.

Ich habe zu keinem Zeitpunkt gesagt, "MSBuild vollständig loszuwerden und meinen Build-Prozess auf allen anderen Entwicklern durchzusetzen". Sie sind derjenige, der sagt: "Entfernen Sie project.json vollständig und erzwingen Sie MSBuild auf allen Entwicklern". Wir hatten in allen Vorschauen zwei Build-Systeme und waren zufrieden. Die Web-Entwickler waren glücklich und die Nicht-Web-Entwickler waren glücklich.

Wir können darüber diskutieren , wie möglich , das ist, und es ist vielleicht nicht, aber wir wissen nicht, weil wir mit nie konsultiert oder beschäftigt waren.

Du liebst wirklich dein Argument der ausgeschlossenen Mitte.

Sie akzeptieren Pull-Requests

Wirklich? Wenn wir eine Pull-Anfrage ausgeben würden, die ein nicht MSBuild-basiertes Build-Tool in der Haupttool-Funktionalität hinterlässt, das nur project.json liest, würden Sie es in das Framework einschließen? Wirklich?

Okay, ich lese das im Grunde als...

Wow, da hast du viel hineingelesen. Meine Güte, wenn ich wie du lese, würde ich nie ein Buch zu Ende lesen. Und es wäre ganz anders als das, was der Autor geschrieben hat.

Versuchen Sie es lieber: "Ich verstehe das Gesamtbild nicht ganz und denke über den Aufwand und die Zeit nach, die damit verbunden wären. Es wäre viel besser, wenn wir die Unterstützung der bestehenden Entwickler hätten, um einen erheblichen Anteil zu liefern." ihrer Community wollen, aber ich denke, wenn es ihnen egal ist, was ihre Benutzer wollen, müssen wir vielleicht diesen Weg gehen."

Teufel noch mal! Ich lese wie du! Nur dass es tatsächlich etwas besser zum Originaltext passt als Ihre etwas hysterischen Interpretationen.

Sie könnten versuchen, tatsächlich etwas Konstruktives zum Gespräch beizutragen.

Nun, ich dachte eigentlich, ich wäre konstruktiv. Nachdem ich den anfänglichen Schock überwunden hatte, versuchte ich herauszufinden, was die Grundlage dieser Entscheidung war. Ich habe versucht herauszufinden, wie der Entscheidungsprozess war. Ich versuchte, die Qualität des Denkens zu hinterfragen, das dahinter steckte. Als mir gesagt wurde, dass die Mehrheit der Entwickler dies wollte, aber keine Beweise für diese Behauptung vorgelegt wurden, fragte ich sie tatsächlich, was _niemand_ im Team übrigens getan hatte.

Was habe ich bekommen? Behinderung, Beleidigungen und Ausflüchte. Also sagen Sie mir, warum halten Sie es für unkonstruktiv, zu fragen, ob jemand, der eine wichtige Entscheidung trifft, die Millionen betrifft, seine Hausaufgaben gemacht hat? Und empfinden Sie es als konstruktiv oder verdächtig, wenn diese Personen sich weigern, das Hausaufgabenheft zu zeigen?

Ich meine, realistisch sind dies die wahrscheinlichen Szenarien:
1) Sie haben die Entscheidung auf der Grundlage eines vollständigen Satzes von Feedback und Informationen getroffen, und die Entscheidung ist wirklich bei weitem die beste Option, um weiterzumachen. Wenn ja, würde ich die Klappe halten, versprochen. Ich halte diese Situation für ziemlich unwahrscheinlich, da Sie so viel Einspruch erhalten haben und dass Sie die Beweise und die Entscheidungsfindung verstecken.
2) Sie haben die Entscheidung aufgrund von Teilansichten getroffen, aber die besten, die Sie zu diesem Zeitpunkt hatten. Ich würde sagen, die richtige Antwort wäre, die Entscheidung erneut zu öffnen und die Ansichten einzuholen, die Sie ausgelassen haben. Das halte ich für die wahrscheinlichste Situation.
3) Sie haben die Entscheidung falsch oder auf der Grundlage falscher Informationen getroffen. In diesem Fall sollten Sie die Entscheidung erneut öffnen und die Community bitten. Ich glaube wirklich nicht, dass dies der Fall ist, denn so sehr Sie mir vielleicht nicht glauben, respektiere ich die DotNetCore-Entwickler sehr. Alle von ihnen.

Und wissen Sie was, wenn Sie die Entscheidung erneut öffnen, die Ansichten einholen und die Entscheidung auf die gleiche Weise gefällt wird, was ist dann der Schaden? Und wenn Sie nach dem Einholen der Meinungen feststellen, dass einige Ihrer Entscheidungen fehlerhaft waren, und Sie dies korrigieren, ist das nicht tatsächlich besser ?

Wow, ernsthaft. Können wir das beenden?

Einfache Frage: Werden Sie die Opposition mit ins Boot holen und die Entscheidung aufgrund der neuen Informationen noch einmal überprüfen?

Oder werden Sie weiterhin nur andeuten, dass Leute, die mit Ihnen nicht einverstanden sind, verrückt, dumm, ungelernt, _uninformiert_ oder auf andere Weise unfähig sind, eine informierte, gültige Meinung zu vertreten?

Vorschlag: Microsoft-Fork zur Unterstützung von msbuild csproj-Legacy-Kunden. #carryOnAsNormal

Ich bin auch ein langjähriger .Net-Entwickler, habe mit Previews von 1.0 gearbeitet, bevor das Marketing überhaupt den Namen .Net erfunden hat. Ohne mich zu sehr im Unkraut zu verlieren, hier sind meine zwei Cent.

Ich könnte den Rest meines Lebens verbringen, ohne jemals eine andere XML-Konfigurationsdatei zu sehen, und vollkommen glücklich sein.

Ich möchte keine XML-Konfiguration. Irgendwo. Immer.

Es ist mir egal, ob das Team jeden einzelnen Painpoint von csproj behebt; wenn es immer noch eine xml-config-Datei ist, wenn Sie fertig sind, dann interessiert es mich nicht. Sie können auch einfach das .net 4.5-Projektsystem behalten.

Was MSBuild angeht... MSBuild kann in einem Feuer sterben.

Ich verstehe, dass es mächtig ist und es viele Tools gibt, aber außerhalb von MS wissen nur ernsthafte Experten für MSBuild, was es tut oder wie es funktioniert. Jedes Mal, wenn ich irgendwelche Anpassungen in den Build-Prozess einbauen muss, verliere ich 3 bis 5 Tage meines Berufslebens. Ich kann selten etwas bekommen, selbst triviale Dinge wie das Einfügen eines leeren Ordners in die Ausgabe, um gleichzeitig in VS, VS-Publishing und meinem CI-Server zu funktionieren.

Ich verstehe ... wenn Sie keine Zeit haben, einen guten Ersatz für MSBuild für den Zeitrahmen von asp.net core 1.0 zu bauen, dann finden Sie sicher ... eine Möglichkeit, MSBuild bis zum asp.net Core 2.0 weiter zu nutzen Kreislauf; aber arbeiten Sie zumindest weiter daran, diesen Scheißhaufen durch etwas zu ersetzen, mit dem der Rest von uns möglicherweise arbeiten kann.

Versuchen Sie in der Zwischenzeit, so viel wie möglich von der Konfiguration in json zu behalten. Es ist mir egal, ob es sich um project.json oder etwas Neues und Besseres handelt. Lassen Sie bei Bedarf die Tools bei Bedarf im Handumdrehen ältere MSBuild-Dateien generieren – stecken Sie sie irgendwo in einen Unterordner oder so.

Was ich nicht möchte, ist, dass mein Dateisystem so aussieht:

• bower.json
• Paket.json
• nuget.json
• alles-sonst.json
• microsoft-old-ass.xml.csproj

Könnten Sie bitte auch die Pfadlänge von 260 Zeichen korrigieren... bitte... ja, ich weiß, das hat viel mit Windows zu tun, aber im Ernst... es ist 2016. .

PS. Wenn Sie zu tragen gehen Widerspruch zu ignorieren, können Sie bitte Folgendes:

• Wie wir Zugang zu den Slack-Channels für Entwickler von Build-Tools erhalten
• Ein Überblick über die aktuelle Architektur und den aktuellen Code und wo die Änderungen für den Wechsel zu MSBuild/xproj vorgenommen werden, damit wir unseren Ansatz so planen können, dass die gewünschten Teile beibehalten und gut integriert werden.
• Zusicherung, dass Pull-Requests in project.json-basierten Werkzeugen gebacken werden, wenn sie die Qualitätskriterien erfüllen
• Wenn die Qualitätskriterien erfüllt sind, können wir "dotnet build"-Unterstützung für die vollständige project.json sowie ASP.NET Simple-Vorlagen und möglicherweise auch einige Vorlagen für Standardprojekttypen einschließen.

„Sei konstruktiv“, „trage nichts bei, bekomme keine Stimme“. Nun, du bekommst was du verlangst...

@Mike-EEE, möchten Sie Xaml-Serialisierungen für SimpleUseCaseBuild durchführen?

Nachdem ich das alles gelesen habe, bin ich zu folgenden Schlüssen gekommen:

• project.json hat viele Verbesserungen gebracht. All dies wäre nicht möglich gewesen, wenn .net und asp.net Core an Legacy-Code und -Tools gebunden gewesen wären
• project.json (und json) ist nicht perfekt
• xml vs. json vs. anyserializationlanguage sind steril. Diskussionen darüber, wie man sie nutzen kann, um .net-Kernherausforderungen zu begegnen, wären interessanter
• Die Rückkehr zu msbuild bringt Legacy zurück und bedeutet wahrscheinlich, dass wir keine Verbesserungen mehr am Projektsystem sehen werden, da .net-Teams wahrscheinlich einen Teil ihrer Freiheit verlieren werden

Ich hoffe, dass .net-Teams tief durchatmen, dies ein wenig ins Stocken geraten, Feedback sammeln (und die Annahme und Wahrnehmung dieses neuen Stack in Betracht ziehen) und den msbuild-Ansatz (der vielleicht nicht so schlecht ist, wie einige von uns denken) mit herausfordern einige Alternativen. Ich denke, da ist Eile geboten.

LOL @shederman, in was hast du mich jetzt

xml vs. json vs. anyserializationlanguage sind steril. Diskussionen darüber, wie man sie nutzen kann, um .net-Kernherausforderungen zu begegnen, wären interessanter

Ja, für mich ist es wichtig, das Begleitmodell zu verwenden, um die Projekte und/oder ihre Aktivitäten zu beschreiben, und einige dieser Gespräche haben dies berührt. Ich würde mir ein verbessertes Projektmodell/eine verbesserte API wünschen, die einfacher zu beschreiben und zu handhaben ist (egal in welchem ​​Format sie beschrieben wird – obwohl ich das tue :heart: my Xaml!). Ich habe diesbezüglich eine offene Diskussion über das Repository von MSBuild (https://github.com/Microsoft/msbuild/issues/613) und auch über das Projektsystem von Roslyn (https://github.com/dotnet/roslyn-project .). -system/issues/37) bei Interesse ebenfalls.

Viele wirklich großartige Punkte hier, und ich persönlich grabe die Energie, "unkonstruktiv" oder nicht. Ich denke, jeder hier hat sein Herz daran, MSFT zu verbessern und das Beste aus dem zu machen, was produziert wird. :+1:

Meine 2 Cent:

Ich glaube, dass es zwei Arten von Leuten gibt, die über diese Änderung diskutieren:

• Entwickler, die VS & .NET zum Erstellen von _verschiedenen_ Arten von Projekten verwenden und diese Projekte für lange Zeit unterstützen müssen
• Entwickler, die kein solches Gepäck haben und ein neues, sauberes und schickes, plattformübergreifendes ASP.NET Core-Framework wollen

Persönlich gehöre ich in die erste Kategorie, daher möchte ich, dass das neue ASP.NET Core mit anderen VS-Projekttypen so kompatibel wie möglich ist, und der Wechsel zur "alten" csproj/msbuild-Lösung ist ein Gewinn für mich (+meine Team und wahrscheinlich viele andere Entwickler). Auf diese Weise wäre der Übergang viel glatter und klarer. Vielleicht würden mir Leute aus der zweiten Kategorie nicht zustimmen (oder es ist ihnen einfach egal).

Das einzige große Problem, das ich jetzt sehe, ist, wie NuGet-Pakete definiert und referenziert werden. Es ist mühsam, sowohl die Dateien package.config als auch @JulianRooze bereits in https://github.com/aspnet/Home/issues/1433#issuecomment-218606377 erwähnt hat). Dies muss umgestaltet werden. Idealerweise sollte dies wie in @cwe1ss vorgeschlagen in https://github.com/aspnet/Home/issues/1433#issuecomment-218519705 ) erfolgen. Es war übrigens einer der konstruktivsten Kommentare zu diesem Thema...

Was den Heiligen Krieg von XML/JSON angeht... IMHO ist XML besser für die Handbearbeitung als JSON. XML unterstützt Kommentare und bietet mehr Kontextinformationen, wenn Sie es betrachten. JSON ist besser für Daten, nicht für Konfigurationsdateien. Das Zusammenführen ist für beide Formate gleich gut und schlecht, es hängt allein vom Inhalt ab. Wenn Projektreferenzen von den aktuellen csproj-Dateien getrennt würden, würde auch das Zusammenführen viel einfacher ...

@Funbit versucht, Leute zu kategorisieren, wird nicht helfen. Und ich passe in keine deiner Kategorien. Ich bin ein asp.net-Entwickler seit v1 Betas. Ich hätte vor 2 Jahren fast aufgehört, einer zu sein, aber .net Core hat mich zurückgebracht, weil es sauber und das Beste aus .net und der Node-Welt war.

Ich möchte, dass .net Core ein Erfolg wird und kein alter Firmen-Techno ohne Akzeptanz und ohne Community.

Mir für meinen Teil ist diese Entscheidung ziemlich egal, XML ist mir egal, und um ein Zitat zu klauen: "Geschwungene Klammern sind besser als spitze Klammern", aber es stört mich nicht wirklich, zurück zu csproj/msbuild - Ich bin flexibel und kann damit umgehen.

Ich möchte jedoch einige der Kommentare von @shederman wiederholen :

Die Realität ist, dass dies nicht wirklich ein Open-Source-Projekt ist, sondern ein Microsoft-Projekt, und sie haben ohne unseren Beitrag eine Unternehmensentscheidung getroffen, und wir müssen sie einfach aufsaugen und akzeptieren. Mir wurde klar gemacht, dass es im Grunde keine Möglichkeit gibt, dass sie es jemals wieder überdenken, egal wie viel Widerstand es gab.

und

Um fair zu sein, bin ich meistens verärgert darüber, wie diese Änderung in einem geschlossenen Raum vorgenommen wurde, ohne die Community zu berücksichtigen oder mit ihr in Kontakt zu treten, die die vorherige, sehr feste Unterstützung für project.json für bare Münze genommen hatte. Junge, werde diesen Fehler nicht noch einmal machen!

Das _stört_ mich, Microsoft hat viel aus Open Source .NET gemacht und möchte die Community wirklich einbeziehen und mit ihr arbeiten, ihr Feedback einholen und ein gutes „Mitglied“ (Partner?) der Community sein. Aber diese Art von Dingen setzt diesen ganzen Aufwand wirklich zurück und verleiht dem .NET-Ökosystem dieses ganze "borgishe" Gefühl, dass die /. Community beschriftet es seit Jahren.

Um Microsoft gegenüber fair zu sein, sind sie nicht die Einzigen, die so etwas mit einem von Unternehmen gesponserten Projekt machen; Erinnern Sie sich an die Aufspaltung in der nodejs-Community (die den io.js-Fork verursacht hat)? Aber ich denke, wenn es Microsoft ist, ist es viel schlimmer.

Das sprengte viel mehr als ursprünglich beabsichtigt.

Das sprengte viel mehr als ursprünglich beabsichtigt

@MaximRouiller bist du überhaupt Entwickler, Bruder??? :Lächeln:

@Mike-EEE Ich tue es. Ich hatte einen hitzigen Streit erwartet, aber ich habe viel zu viele persönliche Angriffe gesehen. :enttäuscht:

Sie müssen in der Lage sein, Quelldateien projektübergreifend freizugeben

@darrelmiller Das klingt für mich beängstigend, denn das scheint zu bedeuten, dass das Auflisten von Dateien in der .csproj-Datei zurückkommt.

@lokitoth Es gibt wahrscheinlich keinen Grund, warum verknüpfte Dateien nicht auch Wildcard-Globs verwenden können.

@MaximRouiller Auch ich bin schuldig, aufgedreht zu werden und viel zu impulsiv zu sein und meine Meinung zu @shederman weiß, wie man @shederman mein inneres Kodierungstier darstellt, aber das war, bevor ich wusste, dass es einen @CodingGorilla gibt. :Lachen:

Ich denke, wir müssen uns daran erinnern, dass das, was wir tun, wirklich harte Arbeit ist, und dann funktioniert es! Der Weg dorthin ist noch schwieriger. Nach meiner Erfahrung mit Silverlight (ja, ich habe mich damit baaaaaaad verbrannt, also weiß ich, woher @shederman kommt), hat mir geholfen zu sehen, dass ich vielleicht nicht _alles_ (oder manchmal sogar _alles_, so fühlt es sich anfühlt!) und offen für die Dinge zu bleiben. Ich scheitere immer noch. Selbst als ich die Initiative project.json sah, tat ich mein Bestes, um auf die Kluft hinzuweisen, die sie erzeugte, aber ich war den Leuten hier im Repo vielleicht etwas zu aggressiv vorgegangen.

Wie auch immer, es ist immer am besten, tief durchzuatmen, (versuchen) eine bescheidene Einstellung zu haben und uns daran zu erinnern, dass wir im selben Team sind, auch wenn dieses Team jetzt in "Web"- und "Native"-Lager unterteilt ist. Es mag für eine Weile scheiße sein, aber wir reden hier über etwas, das uns lange Zeit dienen wird – sogar ein Jahrzehnt oder länger. Konzentrieren wir uns auf einen langfristigen Ansatz und haben gleichzeitig Empathie für andere und deren Herkunft.

OK... genug gepredigt und rah-rah für den Tag. :stuck_out_tongue: Zurück zu unserem regelmäßig stattfindenden Schlagabtausch!

Das klingt für mich beängstigend, denn das scheint zu bedeuten, dass das Auflisten von Dateien in der .csproj-Datei zurückkommt.

Und nebenbei, bin ich der einzige Mensch auf der Welt, der diese Funktion zu schätzen weiß? :stuck_out_tongue:

Das klingt für mich beängstigend, denn das scheint zu bedeuten, dass das Auflisten von Dateien in der .csproj-Datei zurückkommt.

Nebenbei gesagt, bin ich der einzige Mensch auf dem Planeten, der diese Funktion zu schätzen weiß? :stuck_out_tongue:

@Mike-EEE Ja, das glaube ich. :zwinkern:

Der Hauptanwendungsfall für verknüpfte Dateien ist die Ausrichtung auf mehrere Plattformen. Das ist eine Funktion von project.json, die ich unbedingt beibehalten möchte. Ich glaube, ich habe keine speziellen Kommentare zu dieser Funktion gesehen, aber es wäre schön, wenn das Team seine Absicht bekräftigen könnte, dies in msbuild neu zu erstellen.

@shederman weiß, wie man
😆

Ich versuche es doch. Ich hoffe trotzdem, dass ich niemanden beleidigt habe. Ich habe mich sehr bemüht, nur Argumenten nachzugehen.

Ich ärgere mich besonders über abfällige persönliche Beleidigungen, also ist jeder, der gegen mich argumentiert, NICHT der Weg, mich zum Schweigen zu bringen. 😉 Und davon gab es einige.

Ich bin neugierig auf die Anwendungsfälle zum Bearbeiten von csproj-Dateien. Meine Erfahrung ist, dass ich nur csproj-Dateien bearbeiten musste, wenn nuget etwas durcheinander gebracht hat oder ein Hinweispfad beschädigt wurde. Um dem Build-Prozess neue Schritte hinzuzufügen, habe ich immer eine Datei build.proj auf höherer Ebene verwendet, die von meinem CI-System ausgeführt wurde. Ich verwende die .sln-Dateien nie in meinem CI-Setup.

Ist der Hauptzweck, dass Benutzer csproj-Dateien bearbeiten möchten, um BeforeBuild- und AfterBuild-Schritte hinzuzufügen, die sie beim Debuggen in Visual Studio ausführen möchten?

@ Mike-EEE Vielleicht; Ich erinnere mich meistens daran, dass es eine königliche Nervensäge war, wenn es um Projekte mit einer sehr großen Anzahl von Dateien (z. B. Expression Blend, Visual Studio XAML Designer usw.) ging Ich weiß nicht, wie man richtig damit arbeitet, was bedeutet, dass ich jedes Mal, wenn ich eine Datei hinzufüge, das Projekt neu laden muss (oder beim Build den Fehler "Diese Datei wurde bereits hinzugefügt" auftritt).

Was gefällt Ihnen an dieser "Funktion" (keine gemeinsame Nutzung von Dateien über Projekte hinweg, das ist offensichtlich nützlich, aber daran, dass VS nur richtig funktioniert, wenn jede Datei einzeln aufgelistet wird)?

Was gefällt Ihnen an dieser "Funktion" (keine gemeinsame Nutzung von Dateien über Projekte hinweg, das ist offensichtlich nützlich, aber daran, dass VS nur richtig funktioniert, wenn jede Datei einzeln aufgelistet wird)?

Zugegeben, das ist eine schlechte Angewohnheit, aber ich mag es, wenn ich beim Refactoring Dateien aus meinem Projekt entfernen kann. Oder auch aus historischer Sicht. Wenn ich weiß, dass ich an etwas arbeite, das ich zu einem späteren Zeitpunkt vielleicht haben möchte, behalte ich es auf der Festplatte, entferne es jedoch aus dem Projekt. Zugegeben, das belastet die Repository-/Quellcodeverwaltung (siehe: schlechte Angewohnheit), aber ich genieße diese Art der Kontrolle. Weil ich jetzt, wenn ich diese Datei haben möchte, nicht mehr mit der Historie eines Repos herumspielen muss (wie finde ich diese Historie einer gelöschten Datei??? zu viel Arbeit!), ich "zeige alle Dateien" und füge es wieder in meine Lösung ein. Sofortige Geschichte. :Lächeln:

Ich bin neugierig auf die Anwendungsfälle zum Bearbeiten von csproj-Dateien

Für .csproj (jede davon habe ich gemacht und für die meisten mehrmals)

• Wenn Sie von einer Desktopanwendung aus auf UWP-Typen verweisen müssen
• Wenn Sie VS-Probleme mit NuGet beheben müssen (insbesondere beim Hinzufügen von a.targets-Dateien und .proj/.props-Includes)
• Wenn Sie das Layout der generierten Ausgabe ändern müssen
• Wenn Sie Projekte umgestalten und Assemblys umbenennen
• Wenn Sie ein umfangreiches Refactoring durchführen, das sich auf viele Dateien auswirkt
• Wenn ein Zusammenführungskonflikt aufgetreten ist, weil mehrere Personen an demselben Projekt arbeiten und Sie keine Platzhalter verwenden
• Wenn Sie verstehen müssen, warum der Build plötzlich nicht funktioniert (Bearbeiten: Ich hätte angeben sollen - dies ist eher ein "Warum ich es brauche, dass es lesbar und "in sich geschlossen" ist")
• Wenn Sie Konflikte mit Assemblyversionen aufgrund lästiger Abhängigkeiten beheben müssen
• Wenn Sie versuchen, eine "verknüpfte" (freigegebene) Datei hinzuzufügen

Für project.json

• Erstellen der Datei von Grund auf von Hand (von entscheidender Bedeutung)
• NuGet-Pakete hinzufügen/entfernen
• Ändern des Zielrahmens
• Ändern der Ausgabepaketversion

@shederman Ich

Wirklich? Machen die Leute das immer noch? Ich meine, ich habe es früher für AssemblyInfo.cs gemacht und zurück ins Mittelalter

Sie geben einen Ton an. Es ist in Ordnung, ein Gespräch von Angesicht zu Angesicht zu führen, aber in dieser Art von Umgebung öffnet es die Tür zu einer ganzen Reihe von emotionalen Kommentaren, die dazu neigen, das Gespräch zu polarisieren und es schwierig macht, sich auf die wichtigen Punkte zu konzentrieren. Ich weiß, es ist schwer, Emotionen aus diesen Diskussionen herauszuhalten (meine Zunge ist voller Bissspuren ;-) ), aber wir müssen wirklich versuchen, die Diskussion nützlich zu halten.

@Mike-EEE Könnten Sie nicht das gleiche erreichen (ohne jede einzelne Datei aufzulisten) mit dem Exclude Attribut/Muster ? Um es festzuhalten, ich mache oft dasselbe, es ist sehr praktisch, wenn Sie nur schnell etwas eliminieren möchten, ohne einen Commit/Rollback-Zyklus durchführen zu müssen.

Fürs Protokoll, ich mag den Vorschlag von @ Mike-EEE tatsächlich, wenn er Roslyn verwendet und die Projektdatei ein serialisiertes AST ist. Aber nur, wenn wir es schaffen, die Arbeit mit nur Notepad genauso einfach zu machen. (Ja, ich meine Notepad, nicht Notepad++ oder etwas anderes fortgeschritteneres: das ist der "Rauchtest" für die Verwendbarkeit eines von Menschen bearbeitbaren Dateiformats)

@CodingGorilla Ich bin offen dafür. Ich würde es vorziehen, wenn mir die Tools dabei helfen (definieren Sie das Muster für mich, anstatt herauszufinden, wie es geht - wenn ich das Gefühl habe, wieder mit DOS zu arbeiten, VERLIEREN ALLE!!). Ich sollte in der Lage sein, genau die gleichen Erfahrungen zu machen wie jetzt.

Betrachten Sie also im Grunde eher ein "Opt-out"-Modell als ein "Opt-in".

Für diejenigen, die Projektdateien bearbeiten möchten, ohne sie zu entladen.... https://twitter.com/migueldeicaza/status/730978470734401536

Für diejenigen, die Projektdateien bearbeiten möchten, ohne sie zu entladen....

@darrelmiller was schlage ich stattdessen vor, Xamarin Studio zu verwenden? Ja, das Entladen/Laden Geschäft/Workflow/Erfahrung ist das SCHLECHTESTE! Es gibt es schon seit 2003, heh.

Ich unterstütze den Gedanken, dass die letztendliche Datei mit einem Standard-Texteditor (zB Notepad) leicht editierbar und lesbar sein sollte, unabhängig vom Format.

Ich denke auch, dass bessere Tools viele der Schwachstellen hinter dem aktuellen csproj beseitigen würden. VS ist nicht das beste Beispiel und ich denke, die Erfahrung, die VS Ihnen bietet, ist das, was viele Leute am MSBuild-Projektsystem hassen.

@Mike-EEE Die Antwort auf Miguels Kommentar stammte von David Kean, der an dem neuen Projektsystem arbeitet. Das Team weiß, dass VS auch dazu in der Lage sein muss.

@Mike-EEE Ich denke, mein Ding ist, ich kann mit allem umgehen, was sie sich einfallen lassen. Das MSBuild-Projektsystem ist robust genug, um fast alles zu tun (es sei denn, wie @shederman sagt, es kann _nicht_ XML sein). Ich denke, einige Leute stecken nur das "Es muss mein Weg oder es ist ein FAIL" ab, und wie jemand anderes sagte (sorry, wer vergessen hat, dieser Thread ist YUUUUUUGE!) "Ich versuche, aufgeschlossen zu bleiben ..." und einfach anpassen.

Außerdem lernt man vielleicht etwas Neues, und das ist immer gut so. :grins:

@neoKushan Früher

@CodingGorilla Eigentlich ist mein

Ich habe angeboten, die Arbeit selbst zu erledigen, damit die Unterstützung von project.json Seite an Seite mit xproj läuft. Wer sich am meisten interessiert, macht die Arbeit, oder?

Und das ist in der Tat der Knackpunkt. Wird das Team mir erlauben, diesen Beitrag zu leisten? Und wenn nicht, warum nicht? Es ist doch OSS, nicht wahr?

Wenn Sie MSBuild mögen und seine Leistung nutzen möchten, verwenden Sie xproj.

Und wenn Ihnen die Tools gefallen, die für ASP.NET Core entwickelt wurden, verwenden Sie diese weiterhin.

Sie verwenden denselben zugrunde liegenden Compiler.

Und so viel Arbeit sollte es auf keinen Fall sein. Alles, was ich tun muss, ist, den Code, den sie veralteten, in einen anderen Befehl umzugestalten.

Idealerweise möchte ich in der Lage sein, "dotnet build" zu verwenden und mir das Verzeichnis anzusehen und zu entscheiden, welches basierend auf den vorhandenen Dateien verwendet werden soll. Aber ein Options-Flag beim Build oder sogar ein neuer Befehl wäre in Ordnung.

@sandorfr Ich stimme zu, vollwertige MSBuild-Dateien zu schreiben, die Ihren _gesamten_ Build-Prozess definieren, ist nichts weniger als ein kolossaler Schmerz, aber wenn ich mich nicht irre, reden wir hier nicht wirklich darüber - wir reden _nur_ über das Projekt Struktur.

Anders ausgedrückt, MSBuild ist ein riesiges, leistungsstarkes System und damit verbunden eine Menge Komplexität - aber nur, wenn Sie es verwenden. VS hat standardmäßig eine Menge Mist hineingeworfen, den Sie nicht brauchten, und wenn man sich das xproj ansieht, ist klar, dass MSBuild es auch nicht wirklich brauchte. Wenn sich das Donet-Team darauf konzentriert, die Anforderungen im csproj zu minimieren, sollte es für die meisten Leute relativ minimal und sauber sein. Die einzigen, die eine "Merge-Hölle" erleiden sollten, werden diejenigen sein, die diese zusätzliche Funktionalität wünschen (von denen ich vermute, dass sie diese Änderung treiben, sei es auf dem Kopf).

Es gibt immer noch nichts, was Sie davon abhält, das Build-System Ihrer Wahl zu verwenden, sei es CAKE oder TFS Team Services oder was auch immer.

Auch dies setzt voraus, dass das Team es "richtig" macht.

VS ist nicht das beste Beispiel und ich denke, die Erfahrung, die VS Ihnen bietet, ist das, was viele Leute am MSBuild-Projektsystem hassen.

@neoKushan So

Ich denke nicht, dass es produktiv ist, dieses Github-Problem als Chat-Fenster zu verwenden. Ich wollte die E-Mail-Benachrichtigungen für diesen Thread behalten, falls jemand von MS antwortet, aber die Menge an E-Mails wurde einfach zu nervig.

Das MSBuild-Projektsystem ist robust genug, um fast alles zu tun

Das ist ein Teil des Problems und macht es so schwer zu verstehen, was in einer csproj-Datei beim Lesen vor sich geht, was sie zu einer schlechten Wahl für ein Projektdateiformat macht (nicht zu verwechseln mit einem Build-Definitionsdateiformat).

(Edit: hinzugefügt)

Es gibt immer noch nichts, was Sie davon abhält, das Build-System Ihrer Wahl zu verwenden, sei es CAKE oder TFS Team Services oder was auch immer.

Leider bedeutet dies, dass wir nicht versuchen, unser Build-System in MSBuild zu integrieren, wenn wir möchten, dass VS mit ihm kommunizieren kann (und ordnungsgemäß funktioniert, wenn es sowohl verwalteten als auch nativen Code gibt und wir debuggen möchten). Aus diesem Grund glaube ich, dass es ein _Feature_ ist, die Projektdatei aus der Build-Datei aufzuteilen.

Haha yeah @cwe1ss (

Darf ich vorschlagen, dass wir alle am Mittwoch beim nächsten Community-Standup mitmachen? Ich vermute, es wird hauptsächlich über die Veröffentlichung von RC2 ein oder zwei Tage zuvor gesprochen (man kann hoffen!), aber es wird uns allen die Möglichkeit geben, sie mit den notwendigen Fragen anzupingen und eine ehrliche Diskussion mit einem Live-Publikum zu führen das kann tatsächlich Antworten geben.

Darf ich vorschlagen, dass wir alle am Mittwoch beim nächsten Community-Standup mitmachen?

Nur wenn @shederman repräsentiert. Ich möchte sehen, wie er Entwickler und ihre Ideen in Echtzeit zerschlägt. Wie ein WWE PPV-Event!

Ich denke, der Vorteil von project.json gegenüber [projectName].csproj liegt nicht im Format. Es geht darum, nicht mit all dem alten Zeug abwärtskompatibel sein zu müssen. Dadurch war es ziemlich einfach. Angenommen, Damian Edward und sein Team können alle seine festgelegten Ziele erreichen, mir ist XML im Vergleich zu JSON oder YML im Vergleich zu... Was mir wichtig ist, ist Einfachheit und ich muss keine Dinge sehen, die es für Windows gibt, wenn ich unter Linux arbeite .

@glennsills Ich glaube nicht, dass es wirklich viel in einer MSBuild-Projektdatei gibt, die spezifisch für _windows_ ist, sondern eher spezifisch für MS Build selbst oder andere Projekttypen, die Ihnen einfach egal sind. Es ist wirklich nicht notwendig, viele leere Elemente zu haben, nur um MSBuild glücklich zu machen. Ich hoffe, dass das Team plant, so viel wie möglich davon zu streichen, aber wir werden sehen.

@Mike-EEE Nur wenn @shederman repräsentiert. Ich möchte sehen, wie er Entwickler und ihre Ideen in Echtzeit zerschlägt. Wie ein WWE PPV-Event!

Ich werde versuchen, es zu schaffen. Ich warne dich jedoch, dass ich langsamer spreche als ich tippe, also mach dir keine Hoffnungen 😄

Auf die Gefahr hin, eine Dose Würmer zu öffnen, wie würden sich die Leute angesichts von https://github.com/dotnet/roslyn-project-system/issues/40 von einer wirklich reduzierten csproj-Datei halten, die nur (Standardmäßig) ) das Nötigste für das Projekt?

(Bitte verwandle dies nicht in eine "Ich hasse XML!"-Tirade).

Wie wäre es mit einer "Ich hasse MSBuild-Tirade"?

@shederman

Was wäre, wenn wir MSBuild dazu bringen würden, JSON-Dateien zu akzeptieren? :lachen: (konnte nicht widerstehen)

@shederman Es ist schwer, jede Art von Tirade ernst zu nehmen und ich würde es viel lieber machen, dass Microsoft diese _Diskussion_ ernst nimmt.

So wie das geht, wirst du in 5 Jahren Swift, Java(!!), Node.JS oder Elixir programmieren. ;)

Es gibt heutzutage zwei beschissene Technologien in .NET-Projekten/Lösungen/was auch immer. Nuget- und .csproj-Dateien. Wenn Sie in einem 5+-Team mit Git (und zB GitFlow) arbeiten, ist dies ein totaler Albtraum. Das "Oh Mist, wenn vergessen, die Datei in .csproj einzubinden" wird ermüdend. Tools sollten das beheben, Tools sollten mich auch warnen, dass ich widersprüchliche DLL-Versionen habe, Tools sollten mir beim Zusammenführen helfen.

Schneiden Sie den Mist. Project.json schien zunächst nett, aber dann passierten Politik und Gefühle.

MS Team sollte es Beta nennen, nicht RC.
Es sieht so aus, als ob ich nicht vertrauen kann, selbst wenn RTM veröffentlicht wird.
Ich bin kein Pessimist, aber diese Bewegung rund um .NET Core ist sehr seltsam.

@neoKushan Ich werde versuchen,

Ich stimme Diskussionsbedingungen nicht zu, bei denen ich meine Positionen aufgeben muss, um an der Diskussion teilzunehmen. Ich höre immer wieder, dass diejenigen von uns, die für project.json sind, im Grunde genau das akzeptieren müssen, was MS beschlossen hat, mit vielleicht ein oder zwei kleinen Änderungen.

Ich sehe nicht, wie das folgt. Ich möchte einfach das Build-System, das versprochen wurde und zu dem ich mich verpflichtet habe. Wenn MS nicht bereit ist, es beizubehalten und fortzusetzen, habe ich es angeboten.

Wo liegt also das Problem? Ich fordere MS nicht auf, sich von ihren Plänen zurückzuziehen, ich fordere sie nicht auf, Arbeit hinzuzufügen. Ich bitte sie nur, mir zu erlauben, die Versprechen zu erfüllen, die sie einseitig gebrochen haben.

Kaum ein revolutionärer Wunsch.

Meine 2 Cent:

Ich glaube, dass es zwei Arten von Leuten gibt, die über diese Änderung diskutieren:

Entwickler, die VS & .NET zum Erstellen verschiedener Arten von Projekten verwenden und diese Projekte lange Zeit unterstützen müssen
Entwickler, die kein solches Gepäck haben und ein neues, sauberes und schickes, plattformübergreifendes ASP.NET Core-Framework wollen
Persönlich gehöre ich in die erste Kategorie, daher möchte ich, dass das neue ASP.NET Core mit anderen VS-Projekttypen so kompatibel wie möglich ist, und der Wechsel zur "alten" csproj/msbuild-Lösung ist ein Gewinn für mich (+meine Team und wahrscheinlich viele andere Entwickler). Auf diese Weise wäre der Übergang viel glatter und klarer. Vielleicht würden mir Leute aus der zweiten Kategorie nicht zustimmen (oder es ist ihnen einfach egal).

Das einzige große Problem, das ich jetzt sehe, ist, wie NuGet-Pakete definiert und referenziert werden. Es ist mühsam, sowohl die Dateien package.config als auch @JulianRooze bereits in #1433 (Kommentar) erwähnt hat). Dies muss umgestaltet werden. Idealerweise sollte dies wie in #1433 (Kommentar) vorgeschlagen @cwe1ss erfolgen . Es war übrigens einer der konstruktivsten Kommentare zu diesem Thema...

Was den Heiligen Krieg von XML/JSON angeht... IMHO ist XML besser für die Handbearbeitung als JSON. XML unterstützt Kommentare und bietet mehr Kontextinformationen, wenn Sie es betrachten. JSON ist besser für Daten, nicht für Konfigurationsdateien. Das Zusammenführen ist für beide Formate gleich gut und schlecht, es hängt allein vom Inhalt ab. Wenn Projektreferenzen von den aktuellen csproj-Dateien getrennt würden, würde auch das Zusammenführen viel einfacher ...

Ich passe auch in Kategorie eins (Entwickler, die mehrere Projekte/Typen entwickelt haben und diese seit langem unterstützen müssen). Mein Arbeitgeber hat Millionen von Codezeilen von Projekten im csproj-Format und wir haben auch neuere Produkte, die auf ASP.NET RC1 und RC2 Dev Branch laufen. Faire Warnung, wir nutzen MSBuild auch mit benutzerdefinierten MSBuild-Aufgabenassemblys usw.

Die Integration in die reale Welt zwischen den beiden war ein Wrack (aus mehreren Gründen), insbesondere wenn man bedenkt, wie man Wraps generiert, Wraps neu generiert, wenn sich umhüllte Abhängigkeiten ändern, wie dies in der Quellcodeverwaltung aussieht (wir unterstützen und verwenden intern sowohl Git als auch TFVC ), wie Projekte zur Entwurfszeit in VS in einer Projektmappe aufeinander verweisen und wie sie zur Build-/Bereitstellungszeit eingezogen werden. Das System fühlte sich nie richtig an. Es machte keinen Sinn, dass ich zwei separate Projekte mit jeweils nur .cs-Dateien haben könnte, aber diese beiden Projekttypen ließen sich nicht gut kombinieren.

Aus diesem Grund verstehe ich vollkommen, warum es wichtig ist, Anwendungen und Code zu unterstützen, die bis zu diesem Zeitpunkt geschrieben wurden. Ich denke, es ist nicht der richtige Zeitpunkt, um diese Art von Änderung einzuführen, während all die anderen Änderungen im Gange sind - es fühlt sich an, als würde zu viel auf einmal passieren.

Vielleicht ist eine mögliche zukünftige Lösung, dass wir uns von anderen Leuten inspirieren lassen und über LTS-Releases oder ähnliches nachdenken? Dies ist ein viel umfangreicheres Gespräch, aber dann könnte eine Funktion wie ein Projektsystemersatz eingeführt werden und den Leuten Zeit geben, sich damit auseinanderzusetzen.

Eine andere mögliche Lösung ist ein steckbares Build-System, aber dies ist eine längerfristige Lösung und hilft der aktuellen Konversation nicht. Grundsätzlich erlauben Sie entweder/oder/3rd-Party.

Was Projektabhängigkeiten angeht, wir haben bereits Unmengen von package.config-Dateien im Umlauf, deren Portierung in eine package.json/nuget.json ist keine große Sache. Ich habe mehr Probleme mit inkonsistenten Assembly-Bindungsumleitungen als mit dem Speicherformat für Abhängigkeiten.

@shederman Sie haben Ihre Meinung zu MSBuild sehr bekannt gemacht, aber was Sie nicht klar gemacht haben, ist Ihr eigentliches _Problem_ mit MSBuild. Das finde ich so frustrierend, dass ich nur die tatsächlichen Probleme kennen möchte, auf die Sie bei MSBuild gestoßen sind, weil ich wirklich der Meinung bin, dass sie behoben werden können.

Okay, Sie mögen XML nicht, in Ordnung - die Debatte zwischen JSON und XML ist nichts Neues und wir werden das hier nie lösen. Dies kann jedoch nicht der _einzige_ Grund sein, warum Sie MSBuild so sehr hassen. Was sind die tatsächlichen Probleme, auf die Sie gestoßen sind?

Der Grund, warum ich frage - und der Grund, warum ich immer wieder frage, ist, dass dies genau die Probleme sind, die Microsoft beheben möchte, und wenn wir nicht klarstellen, was die Probleme sind, werden sie nicht behoben. Viele der Dinge, die wir an MSBuild hassten, werden bereits behoben, von denen wir wissen:

1. Auflistung jeder Datei im Projekt - wird entfernt/behoben (Eigentlich ein VS-Problem)
2. Hölle verschmelzen - In den meisten Fällen um 1 behoben
3. Unnötige Komplexität / Ausführlichkeit - Wird hoffentlich von https://github.com/dotnet/roslyn-project-system/issues/40 behoben
4. Nicht leicht von Hand zu bearbeiten - Auch hier durch 1. und 3. behoben.

Was ist übrig? Lassen Sie uns die Probleme mit MSBuild diskutieren und sehen, ob es eine Lösung gibt, bei der nicht alles abgespalten oder Zehntausende komplizierter, geschäftskritischer Projekte aufgegeben werden müssen. Das ist die Diskussion, die ich führen _will_.

Meine 2 Cent dazu:
Warum zum Teufel findet diese Art von Veränderung gerade jetzt statt? Laut Roadmap bleibt nur noch 1 Monat bis zur endgültigen Veröffentlichung.
Als ich das zum ersten Mal sah, dachte ich, das sei ein Witz. Ist es aber leider nicht.
Das ist ein dicker Schlag ins Gesicht der Community. Eine solche Entscheidung sollte lange Gesprächsstränge haben, BEVOR sie angenommen wird, nicht danach.

@laskoviymishka (und ein paar andere) wie @neoKushan hier

@laskoviymishka Die Änderung findet nicht vor RTM statt.

RTM wird project.json weiterhin so verwenden, wie es heute verwendet wird (ich glaube, das Schema ändert sich für RC2, aber das geschah trotzdem). Der Wechsel zu einem "neuen" csproj soll nach RTM erfolgen und wird schrittweise erfolgen. Bei RTM ändert sich nichts (außer xproj wird umbenannt).

@CodingGorilla Dies ist RC2, die in einem Monat auf die Version 1.0 übertragen wird. In der realen Welt bedeutet dies, dass Sie aufhören, alles zu entwickeln und sich auf die Stabilisierung zu konzentrieren. Diese Änderung ist nicht wirklich stabilisierend.

@neoKushan, wenn es nach RTM passieren wird, warum nicht die aufsuchen ? Starten Sie einen Diskussionsthread auf github. Beginnen Sie damit, auf Argumente usw. hinzuweisen. Warum sollte es ohne Gespräche mit Entwicklern erzwungen werden?

IMHO sollte dieser Schritt von project.json auf project.csproj diskutiert werden, bevor er angenommen wird. Im Moment ist es keine gute Entscheidung, zumindest für mich.

@laskoviymishka Aus den Stand-up-Notizen der

In RC2/Preview 1 wird es keine Änderung geben . In RTM / Preview 2 _die einzige Änderung, die Sie sehen werden, wenn die xproj-Dateien von Visual Studio in csproj umbenannt werden_. Von diesem Punkt an wird project.json neben csproj leben. Das Team beginnt dann mit der Migration von Features von project.json in die csproj-Datei. Es ist möglich, dass die Datei project.json erhalten bleibt und alle Paketverweise für NuGet enthält und in nuget.json umbenannt wird. Das Team hat bereits einige Arbeiten getestet, die zeigen, dass Sie nicht alle Dateien in Ihrer Projektdatei auflisten müssen, einer der Hauptvorteile des project.json-Modells.

Dies ist also hauptsächlich eine Werkzeugänderung, und auf kurze Sicht (dh RTM+) wird die Datei project.json immer noch vorhanden sein und immer noch genauso funktionieren wie jetzt. Die gute Nachricht, denke ich, ist, dass die Community noch Zeit hat, darauf Einfluss zu nehmen, wenn wir die Dinge zivil und konstruktiv halten können.

@laskoviymishka Nun, ich möchte nicht wirklich für Microsoft sprechen, ich weiß nicht, was ihr endgültiger Plan ist, aber ich glaube, sie wissen es auch nicht wirklich. Viele Leute sagen, dass ihnen der Teppich unter den Füßen weggezogen wurde und Microsoft hätte sich vorher mit uns beraten sollen, aber realistischerweise hat sich noch nichts geändert und wird sich noch Monate lang ändern - und wenn die Änderung passiert, wird es so sein eine allmähliche Änderung und hoffentlich eine, die die Werkzeuge mehr oder weniger für Sie tun.

Microsoft oder zumindest das asp.net-Team hat dazu um Feedback gebeten, und zweifellos lesen sie diese Threads, aber vielleicht fehlt uns ein endgültiges Bulletin oder ein Beitrag von Microsoft, in dem es heißt: "Wenn Sie darüber diskutieren möchten, mach es _hier_". Ich denke jedoch, dass der Übergang viel früher erfolgt, als die Leute denken. Bisher wissen sie nur, dass sie xproj in csproj umbenennen.

Ich persönlich finde, dass, obwohl es eine beschissene Veränderung ist, ich ihre Gründe dafür verstehe. Ich habe keine bessere Antwort, also ist meine Meinung, wenn wir uns mit Projekten im csproj-Stil befassen müssen, können wir diese Zeit genauso gut nutzen, um die beste _Art_ von csproj zu präsentieren, die wir können. Es wird nicht project.json sein, aber wenn wir das Beste aus beiden Welten herausholen können, dann werden wir auf lange Sicht alle besser dran sein. Nicht alle sind sich einig und das ist ok.

@neoKushan das ist ein guter Punkt, hoffe MS wird es sehen. Es wird wirklich schön sein, jedes Feedback vom Kernteam zu sehen.

@CodingGorilla Nun, es gibt noch Änderungen in der endgültigen Version, die

@neoKushan

Lassen Sie uns die Probleme mit MSBuild besprechen

Es fällt mir schwer, genügend Informationen zu finden, um mir eine Meinung zu bilden. Es gab viele Änderungen, die _scheinbar_ durch project.json und das Löschen von .csproj-Dateien ermöglicht wurden. Ich möchte nicht, dass diese Verbesserungen verschwinden, aber ich weiß nicht, wie der Wechsel zu einem "neuen und verbesserten" msbuild meinen Workflow ändern wird:

• Derzeit verwenden wir gulp für jede Build-Aufgabe. Ändert sich das? Mein gulpfile wird einfach an dnu oder dotnet-cli ausgegeben, um eine Sammlung von .cs-Dateien tatsächlich in eine Assembly umzuwandeln. Das kann ich behalten, oder?
• Wird VS weiterhin den Aufgaben-Explorer und Afterbuild/Prebuild/usw.-Trigger für meine Schluck-Aufgaben unterstützen, damit VS-Benutzer F5 ausführen können? Oder muss msbuild gulp starten, was bedeutet, dass für alle meine gulp-Aufgaben Wrapper-msbuild-Aufgaben definiert werden müssen? (Autsch)
• Ist msbuild in einer separaten Installation? Wird es getrennt von der dotnet cli oder der Runtime versioniert? Wie ändert sich dadurch das Minimum, das auf meinem CI-Build-Server verfügbar sein muss? Mindestens für die Installation in einer Entwicklungsumgebung?
• Wenn ich einen Texteditor verwende, um Nuget-Abhängigkeiten oder .cs-Dateien hinzuzufügen, welche zusätzlichen Schritte muss ich jetzt ggf. hinzufügen?
• Wenn ich ein Changeset überprüfe, in dem ein VS-Benutzer eine Nuget-Abhängigkeit und eine .cs-Datei hinzugefügt hat, sind die csproj-Änderungen einfach und lesbar? (Zum Vergleich mit .net 4.6 und VS2015 bin ich der Meinung, dass Änderungen am csproj _nicht_ leicht von Menschen lesbar sind.)

Ich würde gerne sehen, dass die Leute, die diese Änderung vornehmen, nach den Szenarien greifen, die sie in Betracht ziehen müssen (wie meinem!) und darüber diskutieren. Ich hoffe, "Hey, wir verschieben Ihren Käse ohne Diskussion"-Sache wird nicht zur SOP von .net Core.

dieses Werkzeug wird mehr oder weniger für Sie tun

Und das ist die wichtigste Crux. Je weniger Werkzeuge _erforderlich_, desto besser. Ich kann derzeit einen Texteditor und die Befehlszeile verwenden, ohne das Gefühl zu haben, stromaufwärts zu schwimmen. Ich hoffe, das ändert sich nicht. Im .net46-Land muss ich eine riesige und ausführliche XML-Datei bearbeiten, wenn ich VS nicht verwenden möchte, und das Mischen von VS-Benutzern mit Nicht-VS-Benutzern im selben Projekt ist ein Albtraum.

"Willkommen bei RTM. Dies ist eine Erinnerung daran, dass sich Ihre Projektdatei irgendwann in sehr naher Zukunft ändern wird. Wir haben dies bereits entschieden. Gründe, aber hauptsächlich, dass wir Winkel besser mögen als Locken, oh und Werkzeuge bauen, ja, bauen Wir haben das endgültige Schema noch nicht festgelegt (aber es wird XML-basiert sein, siehe oben), und der Dateiname wird definitiv mit .csproj beendet, um die größtmögliche Verwirrung in alle Legacy-Tools zu werfen wenn Sie ein Tool-Anbieter sind: :o)"

@Oceanswave schönes Beispiel, wie Sie Ihre Softwareentwicklung nicht verwalten

@neoKushan

Aber was Sie nicht klargestellt haben, ist Ihr eigentliches Problem mit MSBuild

Vielleicht sollten Sie meine vorherige Antwort auf genau dieselbe Frage von Ihnen lesen? https://github.com/aspnet/Home/issues/1433#issuecomment -218993559

Ich habe im Laufe der Jahre Hunderte von Stunden damit verschwendet, MSBuild-Dateien zu reparieren, zu entwickeln und zu debuggen. Ich habe Team Builds gemacht, ich habe riesige Build- und Deploy-Pipelines gemacht. Ich habe Stunden damit verbracht, über ausführliche Protokolle zu grübeln, um herauszufinden, warum zum Teufel eine seltsame Situation auftritt. Ich habe im Laufe der Jahre meine Gebühren für diese Technologie bezahlt und möchte persönlich nichts damit zu tun haben. project.json war ein Hauch frischer Luft. Nach Jahren des Leidens mit MSBuild hatten wir endlich den Eindruck, dass MS es verstanden hat, dass eine Änderung erforderlich war und angewendet wurde.

Und es war herrlich. Einfache Builds, einfache Bearbeitungen, schnelle und leicht verständliche Ausgaben. Es wusch die Erinnerung an die Stunden, in denen die MSBuild-Skripte beschimpft wurden. Es fühlte sich an, als würden wir uns endlich von der Leiche der Vergangenheit lösen. Aber nein, jetzt sind wir wieder an die Leiche gefesselt, die wir so hassen, trotz des Versprechens, dass dies nicht passieren würde.

Ohne Diskussion, ohne Kritik, ohne jegliches Engagement.

Die Tatsache, dass Sie nicht einmal wissen, wie sehr MSBuild in manchen Kreisen gehasst wird, beweist einfach, dass Sie bei dieser Entscheidung keine Sorgfalt walten lassen.

Ich glaube nicht, dass MSBuild als Build-System wesentliche Funktionseinschränkungen hat. Es ist unglaublich mächtig und in gewisser Weise ist das seine Hauptschwäche. Es ist kompliziert, weil es so viele Szenarien bewältigen muss. Für ein einfaches Szenario "Wiederherstellen, Erstellen, Testen, Packen" ist dies wirklich ein großer Overkill.

In meinen Teams haben wir es mit C#-Entwicklern zu tun. Sie stehen unter Druck, enge Termine, hoher Stress. Sie wollen nichts, was ihnen in die Quere kommt oder sie aufhält.

MSBuild ist eine andere Denkweise, ein wichtiger Kontextwechsel von der zwingenden Codierung. Die Entwickler hassen es einfach. Sie finden es stumpf und kontraintuitiv. Sie vermeiden es. Das einzige MSBuild, das heutzutage in einem der Teams erstellt wird, die ich betreue, ist das von mir erstellte Tool.

Ich habe in den letzten 5 oder mehr Jahren keinen einzigen C#-Entwickler getroffen, der von MSBuild begeistert ist oder gerne damit arbeitet. Sehen Sie sich einige Kommentare der letzten Tage auf Github an. Ich bin mit meiner Abneigung gegen MSBuild keineswegs allein. MSBuild gilt seit einem Jahrzehnt als Mühlstein um den Hals von .NET-Entwicklern. Ist vieles von dieser Wahrnehmung ungerecht? Ja, ziemlich wahrscheinlich.

Na und? Aus meiner Sicht als Head of Software Engineering benötige ich Werkzeuge, die die gewünschten Ergebnisse liefern. Ich erhalte diese Ergebnisse mit MSBuild nicht. Ich erhalte diese Ergebnisse von project.json + gulp.js + Powershell.

_Kann_ mir MSBuild diese Ergebnisse liefern? Sicher kann es, aber nur, wenn die Entwickler die Arbeit in MSBuild erledigen, um diese Ergebnisse zu erzielen. Und sie tun es einfach nicht. Wenn wir sie zwingen , tun sie es und behalten es dann nicht bei.

Ich kann mich nicht auf ein Tool verlassen, das die Entwickler hassen. Das ist die einfache Realität. Und wenn man bedenkt, wie sehr ich es geliebt habe, es nicht selbst zu benutzen, kann ich ihnen nicht wirklich einen Vorwurf machen.

Lassen Sie uns die Probleme mit MSBuild diskutieren und sehen, ob es eine Lösung gibt, bei der nicht alles abgespalten oder Zehntausende komplizierter, geschäftskritischer Projekte aufgegeben werden müssen.

Okay, was kann man tun?

Vor ungefähr 5 Jahren, wenn einige der jetzt diskutierten Änderungen eingeführt worden wären, denke ich, dass die Wahrnehmung besser wäre. Aber sie waren es nicht und jetzt hat es eine große negative Meinung unter einer großen Anzahl von Entwicklern. Soweit ich mich erinnere, wurden einige dieser Probleme damals mit MSBuild angesprochen und abgelehnt. Ebenso wie aktuelle Themen angesprochen und abgelehnt werden.

Ich weiß nicht, wie es das wiederherstellen kann, ich weiß es wirklich nicht. Ich denke, es müsste einige große saubere Brüche geben. Wie macht man sie, ohne zu brechen, was da ist? Es ist zu wenig, zu spät. Ich sehe also keinen Weg nach vorne mit MSBuild, nicht für mich, nicht für die Entwickler, die für mich arbeiten, nicht mit meinen Partnern oder den Teams, die für _sie_ arbeiten, nicht für die Kunden, die wir beraten. Keines dieser Zielgruppen möchte MSBuild verwenden, sie verwenden es in den Tools, weil sie es müssen, und sie schwören wiederholt darauf. Zugegeben, normalerweise um die Zusammenführungszeit herum.

Sie möchten _jetzt_ also die Zusammenführungen verbessern? 10 Jahre später. Nachdem das Tool in vielen Kreisen ein Schimpfwort ist?

Grundsätzlich verwenden Sie ein Tool, das in den späten 90ern für Build Masters entwickelt wurde und tatsächlich von Entwicklern nach 2010 verwendet wird. Ein Tool, das eine sehr flexible, aber nicht offensichtliche Methode zum Festlegen von Eigenschaften verwendet, die von Entwicklern verwendet wird, die denken, dass Eigenschaftssätze ein einfacher Zuweisungsoperator sind und nicht verstehen, warum Sie überhaupt einen PropertyGroup Befehl ausführen möchten und nicht es ist mir egal, es herauszufinden.

Das ist die Diskussion, die ich führen möchte.

Klar, das verstehe ich. Die Diskussion, die ich führen möchte, ist jedoch eine andere, es heißt "Geben Sie uns, was Sie uns versprochen haben, oder lassen Sie es uns selbst geben, weil wir Ihre alte neue Idee nicht mögen und wir halten, was uns versprochen wurde".

Darf ich etwas Trauriges teilen? Von meinen Geschäftspartnern, die über ähnliche Erfahrungswerte wie ich verfügen (eigentlich mehr), war ich damals der MSBuild-Profi. Ich habe es tatsächlich _benutzt_. Ich habe es gelernt. Ich habe große Pipelines gebaut. Aber das ist über 5 Jahre her und seitdem ist viel Wasser unter der Brücke durchgegangen.

Mann, ich nicke reichlich, während @shederman lese , da sie meiner sehr ähnlich sind. Ich habe so viel Zeit mit MSBuild und seiner DSL verbracht und war wirklich ein paar Mal damit beschäftigt (ganz zu schweigen von der Zeit, die ich damit verbracht habe, es zu lernen). Seine Syntax und sein Ansatz sind anders als alles andere in .NET und das ist ein Teil des Problems (weshalb ich sage, das Objektmodell neu starten/wiederherstellen/verbessern und es noch einmal versuchen). Das wäre mein Hauptanliegen: Es ist so altmodisch, dass die Art und Weise, wie es Probleme angeht, anders ist als alles andere, mit dem (.NET) Entwickler arbeiten müssen, und dies entfremdet das Produkt, anstatt das Interesse/die Akzeptanz zu fördern.

Denken Sie an: Visual Studio-Erweiterungen (.vsix). Niemand möchte sie anfassen, weil sie so alt und anders sind als alles andere, was heutzutage da draußen ist. Nun, Sie haben EINIGE Entwickler, die das wollen, weil sie ihre Gebühren für das Erlernen des geheimnisvollen Systems bezahlt haben – genau wie MSBuild.

Auch ich bin wahrscheinlich der erfahrenste unter allen, die ich beruflich kenne, der sich jemals mit MSBuild beschäftigt hat. Die meisten Entwickler möchten sich nicht die Zeit nehmen, es zu lernen (weil Sie es definitiv tun). Es ist fast so, als ob es eine eigene Sprache wäre.

Wenn es "eher .NET-ähnlich" wäre (und eine bessere Integration mit VS hätte), dann wären wir uns alle einig, dass es ein besseres Produkt wäre, mit dem man arbeiten kann, und ein attraktives Angebot, das man in Betracht ziehen sollte.

@Mike-EEE & @shederman Um Mike zu die Antwort von

Auch hier habe ich kein Pferd in diesem Rennen, es ist mir egal, welchen Weg sie einschlagen. Ich mag es einfach, Daumen hoch zu bekommen und mich selbst sprechen zu hören (mit einer Seite des tatsächlichen intellektuellen Interesses an der Konversation :lachen:)

Ich mag es einfach, Daumen hoch zu bekommen und mich selbst sprechen zu hören (mit einer Seite des tatsächlichen intellektuellen Interesses an der Konversation :lachen:)

Freue mich zu helfen! :Lächeln:

Aber ist es nicht mehr zu reparieren? Kann es behoben werden?

Kommt wirklich darauf an, wen du fragst. Probleme in ihrem Repo anzusprechen , wie

@PhilipRieck Du

Derzeit verwenden wir gulp für jede Build-Aufgabe. Ändert sich das? Mein gulpfile wird einfach an dnu oder dotnet-cli ausgegeben, um eine Sammlung von .cs-Dateien tatsächlich in eine Assembly umzuwandeln. Das kann ich behalten, oder?

Ich _glaube_ nicht, dass sich das ändern wird, ich bin mir zu 95 % sicher, dass das, worüber wir hier sprechen, nur die _Definition_ des Projekts betrifft, nicht wie das Projekt tatsächlich aufgebaut ist (zumindest über das Aufrufen von dotnet build hinaus). Die dotnet-CLI kann irgendwann MSbuild aufrufen, aber zu diesem Zeitpunkt ist es eine Sache unter der Haube.

Ist msbuild in einer separaten Installation? Wird es getrennt von der dotnet cli oder der Runtime versioniert? Wie ändert sich dadurch das Minimum, das auf meinem CI-Build-Server verfügbar sein muss? Mindestens für die Installation in einer Entwicklungsumgebung?

Ich habe keine definitive Antwort darauf, aber ich würde mir _vorstellen_, dass MSBuild als Teil der dotnet-CLI als vollständig separate Installation geliefert wird, auch wenn Sie MSBuild bereits installiert haben (sagen wir mit VS). Allerdings reine Spekulation meinerseits. Ich weiß, dass ein großes Ziel dieses ganzen ".net-überall"-Projekts darin besteht, mit minimalem Aufwand Menschen zur Entwicklung zu bewegen. Sollte buchstäblich apt-get dotnet-cli (oder was auch immer), dotnet new, dotnet build sein. Sie sollten niemals MSBuild aufrufen müssen, um das Projekt zu erstellen, das ist die Aufgabe von dotnet-cli.

Wenn ich einen Texteditor verwende, um Nuget-Abhängigkeiten oder .cs-Dateien hinzuzufügen, welche zusätzlichen Schritte muss ich jetzt ggf. hinzufügen?

Für .cs-Dateien definitiv nichts anderes, genau wie heute - das Einzige, was sie sehr deutlich gemacht haben, ist, dass die Tage der Spezifikation jeder .cs-Datei in Ihrem Projekt hinter uns liegen (obwohl Sie das vermutlich immer noch tun können, wenn Sie möchten , dich anschauen @Mike-EEE). Was Abhängigkeiten angeht, bleiben sie sicherlich kurzfristig (kurzfristig Monate) in project.json und funktionieren genau wie zuvor. Es besteht die Möglichkeit, dass aus project.json nuget.json wird, und außer einer Namensänderung ändert sich nichts, aber es gibt andere Möglichkeiten dafür und dies scheint eines der wichtigsten Dinge zu sein, bei denen Microsoft sehr unsicher ist - lass deine Stimme auf Ihre Präferenzen für diese gehört werden.
(Meine persönliche Vorliebe ist, in der Lage zu sein, etwas zu tun wie.nuget.json aber das spucke ich nur aus).

Wenn ich ein Changeset überprüfe, in dem ein VS-Benutzer eine Nuget-Abhängigkeit und eine .cs-Datei hinzugefügt hat, sind die csproj-Änderungen einfach und lesbar? (Zum Vergleich mit .net 4.6 und VS2015 bin ich der Meinung, dass Änderungen am csproj nicht leicht für Menschen lesbar sind.)

Für die .cs-Datei sollte sich das csproj überhaupt nicht ändern. Für Nuget-Abhängigkeiten - gute Frage, auch dies liegt etwas in der Luft. Es sollte wirklich nicht dazu führen, dass sich das csproj ändert, aber die große Entscheidung ist im Moment, ob nuget in nuget.json leben soll oder ob csproj dieses Zeug haben sollte - und wenn sie getrennt sind, wie schwierig wird es sein, es einzugrenzen? die Zwei?

Und das ist die wichtigste Crux. Je weniger Werkzeuge benötigt werden, desto besser. Ich kann derzeit einen Texteditor und die Befehlszeile verwenden, ohne das Gefühl zu haben, stromaufwärts zu schwimmen. Ich hoffe, das ändert sich nicht. Im .net46-Land muss ich eine riesige und ausführliche XML-Datei bearbeiten, wenn ich VS nicht verwenden möchte, und das Mischen von VS-Benutzern mit Nicht-VS-Benutzern im selben Projekt ist ein Albtraum.

Ich stimme dem voll und ganz zu, aber Microsoft hat viel zu viel in seine plattformübergreifenden Bemühungen investiert, um es plötzlich zu einem Albtraum zu machen. Durch "Tooling" vermute ich, dass es eher an der .net-CLI als an VS oder ähnlichem liegt. Vergessen Sie nicht, dass das ultimative "Endspiel" für .net Core eine sehr agile, sehr schnelllebige Plattform sein soll, die Sie jedoch nicht dazu zwingt, alle paar Wochen Zeit mit Upgrades zu verbringen. Ich bin _ziemlich sicher_, dass, wenn Sie im Juni eine dotnet 1.0-Anwendung schreiben, diese noch in Jahren erstellt und ausgeführt wird, aber neuere Versionen werden ein Fall sein, in dem Sie "dotnet upgrade" oder etwas in dieser Richtung ausführen müssen, wenn Sie dazu bereit sind . Selbst wenn RTM zuschlägt, werden RC2-Projekte immer noch RC2-Bits erstellen und ausführen, bis Sie tatsächlich hineingehen und das Ziel in RTM ändern (ich denke in global.json oder irgendwo?).

:lachen: Wenn ich solche Threads lese, muss ich mich fragen, ob Microsoft Momente des Bedauerns hat. Ich respektiere und empfinde für die Leute, die alles getan haben und tun, um Microsoft auf den Kopf zu stellen, mit dem Ziel, eine transparente, quelloffene, gemeinschaftsorientierte Oase für Entwickler zu schaffen. Die Jungs hinter dieser Transformation kümmern sich. Sie sind die Guten. Sie müssen im Moment zwischen einem Felsen und einem harten Ort sein; die wenig konstruktiven Gemeinschaftsgefühle, die herumschweben (während sie mich unterhalten), helfen ihrem Fall nicht.

Ich möchte darauf hinweisen, dass es eine schlechte Idee ist, eine Reihe von magischen Funktionen zur Projekterstellung, die derzeit in der IDE vorhanden sind, durch eine Befehlszeilen-App zu ersetzen, die viele magische csproj-Manipulationen durchführt. Es ist ein Muss, die Projektdefinitionsdatei so einfach wie möglich zu gestalten. Das Schönste an project.json ist, dass ich es lesen und verstehen kann.

@shederman Ihr Problem mit MSBuild ist, dass es in einem großen, komplexen System groß und komplex ist....

Ich habe auch mit dem Team gearbeitet Baut und ich habe auch absolut hasste es (Pinging @ Mike-EEE becuse wir beide haben darüber gesprochen , wie schrecklich diese Erfahrung ist), ich bekomme es aber , was Sie beschreiben , ist eine ganz andere Szenario. MSbuild _kann_ groß und komplex sein und standardmäßig _macht_ VS es groß und komplex - aber das ändert sich .

Die neuere csproj-Datei sollte viel kleiner sein, was bedeutet, dass das "Debuggen" stark vereinfacht werden sollte. Keine (oder wenig) Krümel. Sie können immer noch jedes _Build-System_ verwenden, das Sie wollen, verdammt, Sie können eine .bat-Datei aufrufen, die einfach "dotnet build" auf *.csproj aufruft, und Sie erhalten die gewünschte Ausgabe, genau wie heute. Lassen Sie die Dotnet-Cli mit MSbuild umgehen und Sie sollten sie nicht einmal anfassen müssen.

@neoKushan nein danke.

Ich will, was versprochen wurde, nicht Lippenstift auf dem, was uns gesagt wurde, von dem wir weggehen.

Und wenn Sie uns das Versprochene nicht geben wollen, geben wir es uns einfach. Es ist schon alles da. Es sollte nur darum gehen, die Refactorings beizubehalten. Ich werde die Arbeit machen, wie ich schon sagte.

Ich vermute, der Hauptgrund dafür, dass es keine Lust gibt, es zu belassen, ist die Erkenntnis, dass dies der Beginn einer massiven Migration weg von MSBuild-Projekten wäre. Es tut mir leid, aber die Beibehaltung einer veralteten Technologie zur Lebenserhaltung gehört nicht zu den Entwurfszielen von .NET Core. Ist es?

Größtes Problem mit ms build in, wer wird es beheben und wie lange es dauert. Im Moment haben ganze ASPnet-Projekte mehr als 1000 offene Probleme, von denen einige sehr kritisch sind. Sehen Sie sich SignalR an.
Es ist noch ein Monat bis zur Veröffentlichung, und dieser Fehler nähert sich dem endgültigen Zustand nicht wirklich.

Und jetzt sagen sie, dass ms build verbessert werden könnte. Hat MS genug Ressourcen, um all diesen alten Scheiß zu verwalten 💩? Kann die Gemeinschaft damit umgehen? Ich glaube nicht wirklich daran.

@shederman

Und wenn Sie uns das Versprochene nicht geben wollen, geben wir es uns einfach.

Sie hindern dich nicht daran, ALLES zu tun. Gehen Sie voran und geben Sie es ab, nichts hält Sie auf. Wenn Sie auf die Erlaubnis von Microsoft warten, haben Sie sie bereits erhalten, in der Sekunde, in der sie den Code als Open Source bereitgestellt haben.

Es ist schon alles da. Es sollte nur darum gehen, die Refactorings beizubehalten. Ich werde die Arbeit machen, wie ich schon sagte.

Dann tu es? Auch hier hält dich nichts mehr auf.

Ich vermute, der Hauptgrund dafür, dass es keine Lust gibt, es zu belassen, ist die Erkenntnis, dass dies der Beginn einer massiven Migration weg von MSBuild-Projekten wäre.

Warum sollte es sie überhaupt interessieren? Welchen Unterschied macht es für Microsoft, wenn Sie MSbuild oder etwas anderes verwenden?

Der eigentliche Grund Nummer 1 ist, dass die Projektstruktur von ASp.net core nur für asp.net core wirklich gut ist. Es gibt Hunderte anderer Projekttypen, die einfach nicht für project.json geeignet wären. Ungeachtet der Tatsache, dass project.json seine eigenen Probleme hat, die wir anscheinend alle vergessen haben – fehlende Kommentare sind mein Lieblingsärgernis (und nein, was auf ein anderes Format hindeutet, solange es-nicht-ist- XML hilft nicht).

Es tut mir leid, aber die Beibehaltung einer veralteten Technologie zur Lebenserhaltung gehört nicht zu den Entwurfszielen von .NET Core. Ist es?

Nein, aber es ist ein Ziel, Leuten zu helfen, ihre alten, bestehenden Projekte auf .net Core zu portieren. Außerdem sprechen wir über die .net-Core-Version von MSBuild, nicht die vollwertige Desktop-Version, es gibt einen Unterschied .

Ihr einziges Problem ist, dass sie es gewagt haben, es MSBuild zu nennen. Hätten sie einen neuen Projektstil entwickelt, der zufällig XML war, aber "CoreBuild" oder so heißt, wäre man nicht klüger und müsste nur sagen "I hasse XML!".

du wartest auf die Erlaubnis von Microsoft, dann hast du sie schon

Nicht ganz wahr. Ich möchte es nicht abspalten , ich möchte es im Hauptrepo beibehalten. Es besteht ein Unterschied. Es muss also niemand ein komplett neues .NET SDK herunterladen. Ich will es in den Werkzeugen haben, und dafür brauche ich ja ihre Zustimmung.

Ihr einziges Problem ist, dass sie es gewagt haben, es MSBuild zu nennen

Nein, dass sie MSBuild _verwenden_ wollen. Kleiner, aber wichtiger Unterschied. Benennen Sie das neue Build-System project.json um und nennen Sie es MSBuild, und ich werde es gerne verwenden.

Sie wären nicht klüger und alles, was Sie sagen müssten, ist "Ich hasse XML!"

Vielleicht

Wie auch immer, im Kreis drehen.

Ins Bett gehen.

Ich sage, lass es für das Aufstehen. Niemand überzeugt irgendjemanden. Ich bin mir ziemlich sicher, dass ich die Pro-MSBuild-Seite verstehe, aber ich bin damit nicht einverstanden. Und ich bin mir ziemlich sicher, dass die Pro-MSBuild-Seite die Nicht-MSBuild-Seite versteht, aber ich bin damit nicht einverstanden.

Ich sage nur, wir können beides haben. Für keine (oder nur sehr geringe) zusätzliche Anstrengung des MS-Teams. Dann lassen Sie die Optionen im Glanz der tatsächlichen Produktionsnutzung versinken oder schwimmen.

Per @neoKushans Frage:

Was ist übrig?

Ich möchte meine Antwort, wenn ich darf, um die "Grundsätze" herum rahmen, die ich oben skizziert habe, was meiner Meinung nach eine gute, verwendbare Projektdatei ausmacht:

• Es sollte von Menschen editierbar/lesbar sein

Die obige Aussage von

Ich gehe davon aus, dass das Entfernen des Guid-Projekttyps eines der wichtigsten Punkte ist, die angegangen werden müssen.

Aber ich bleibe bei meinem obigen Nachtrag: Es ist eine harte (nicht verhandelbare) Voraussetzung, dass ich für einfache Projekte (zB ASP.Net Hello World in Angular) alles von Hand im Notepad erstellen kann. Wenn ich Yeoman/VS/similar verwenden muss, ist es uns nicht gelungen, eine von Menschen bearbeitbare Projektdatei vorzuschlagen.

• Es sollte Kommentare zulassen

Funktioniert bereits, in MSBuild

• Es sollte deklarativ sein

Ändern der Reihenfolge der ersten Ebene (direkte Kinder von) kann die gesamte Bedeutung des Projekts ändern, oft auf schwer zu debuggen. Nirgendwo ist dies bemerkenswerter, als wenn Sie die .targets-Importe versehentlich an die Spitze bringen.

• Es sollte in sich geschlossen sein

Dies ist mein größtes Problem mit MSBuild. Das statische Lesen einer Datei gibt Ihnen nicht genügend Informationen, um tatsächlich zu wissen, was dort vor sich geht. Von .targets-Dateien, die aus _environment variable_-spezifizierten Pfaden stammen, und der Tatsache, dass Umgebungsvariablen ereignisunterstützt werden, bis hin zu Bedingungen und Importen, zusammen erhalten Sie eine Turing-Complete-Umgebung auf Kosten einer sehr hohen Komplexität , und schlechte Werkzeugfähigkeit. Ich gehe davon aus, dass die miserable Integration von MSBuild in VS eine Folge der Schwierigkeit ist, Tools um solche herum zu erstellen.

Dies ähnelt dem Problem der menschlichen Lesbarkeit/Bearbeitbarkeit.

• Es sollte so gestaltet sein, dass Zusammenführungskonflikte reduziert / Zusammenführungen vereinfacht werden, wenn möglich

MSBuild unterstützt dies technisch in Form von Platzhaltern. Die VS-Unterstützung für Wildcards ist schlimmer als miserabel. Es erschwert die Arbeit aktiv. Wie oben, bin ich bereit zu akzeptieren, dass dies behoben wird - aber es muss ein Element in einem _Vorschlag_ für _Migrate_ sein (und es ist eine Migration zu, da alle Nachrichten bisher über project.json waren) zu MSBuild -basierte Projektdateien.

• Es sollte vollständig dokumentierbar sein (wobei das Prinzip der Eigenständigkeit für die Dokumentation gilt)

Ich glaube, MSBuild hat eine Dokumentation. Diese Dokumentation, insbesondere für das VS _flavor_ von MSBuild, lässt einiges zu wünschen übrig. Ich bin oft ratlos, warum sich verschiedene Dinge in den Gruppen befinden, die sie sind, und VS zu "helfen", sie zu bewegen, ist nicht sehr hilfreich.

Ein perfektes Beispiel ist das Bond NuGet-Paket. Wie viele Leute wissen, dass der Build auf mysteriöse Weise keinen der Bond-Typen in der resultierenden Assembly generiert, wenn Sie keinen BondInclude-Ordner auf der Festplatte haben (wenn er im csproj referenziert wird)? (Auch ohne Fehlerspuck). Dann wird ein leerer Ordner mit diesem Namen erstellt und das Projekt neu geladen.

(Ja, ich weiß, ich werde einen Fehler melden)

• Es sollte werkzeugunabhängig sein

Sagen wir, ich möchte nichts mit MSBuild zu tun haben (sagen wir, weil ich mich konträr fühle, ohne weiter darauf einzugehen); Ich möchte nur mein Projekt definieren und Pakete über Nugget einlesen. Warum bin ich gezwungen, dieses spezielle Build-System zu verwenden? Vor allem, wenn ich nur ein Projekt definieren möchte?

Eine Build-Definitionsdatei ist kein Projektdateiformat. Dass VS es geschafft hat, es (etwas) zum Laufen zu bringen, ist kein guter Grund, es weiterhin als solches zu verwenden. Ich möchte eine echte Datei, die nur das Projekt selbst darstellt, und Informationen über das generierte Artefakt (keine Anweisungen zum Erstellen). Dabei scheitert sogar project.json, weil es uns erlaubt, "Befehle" zu definieren. Warum gibt es die? Definieren Sie einfach, was der Ausgabetyp ist und wo er gefunden werden kann.

Ich habe diesen ganzen Thread gelesen, und eine Sache, die mir in dieser Diskussion über project.json vs project.csproj ist, ist, dass nur einer dieser Dateinamen eine ganze Programmiersprache enthält. Ich bevorzuge die Entwicklung von ASP.NET in F#. Ist das in ASP.NET Core überhaupt möglich? Zu diesem Zeitpunkt habe ich nicht die leiseste Ahnung, aber ich habe das Gefühl, dass es nicht so ist. Ich bin mir nicht einmal sicher, ob die Leute csproj als Abkürzung für csproj, fsproj, vbproj oder ob sie wirklich nur csproj meinen.

Update: Die F#-Leute arbeiten an der CoreCLR-Unterstützung, aber es gibt noch keine echte ETA. Mein Punkt ist, dass jedes Projektsystem, für das jetzt entschieden wird, Programmiersprachen beeinflussen wird, die im Moment noch nicht einmal auf dem Radar der Leute zu sein scheinen. So sehr ich JSON gegenüber XML bevorzuge, wenn mich project.json in C# sperren wird (und die Dateireihenfolge bei der Kompilierung in F# von entscheidender Bedeutung ist), dann bin ich nicht dafür.

Im Moment sieht es für mich so aus, als wäre es zurück zu FAKE und Paket...

Ich arbeite von Anfang an mit .NET und hatte noch nie nennenswerte Probleme mit MSBuild. Der Hauptgrund dafür ist, dass ich es nie für etwas anderes als die Zusammenstellung der Out-of-the-Box-Lösung verwendet habe.

Und das ist es, was ich an dieser Abneigung gegen MSBuild nicht verstehe. Niemand zwingt jemanden, MSBuild für etwas anderes als die Lösungskompilierung zu verwenden. Und ich denke, eine Lösung kompilieren zu können ist eine ziemlich nützliche Funktion - die es übrigens noch nicht einmal in "dotnet cli" gibt (Sie müssen die Projekte jetzt manuell durchschleifen - korrigieren Sie mich, wenn ich falsch liege).

Ihr tatsächliches Build-System muss sich nicht ändern. Wenn Sie Nant verwenden, verwenden Sie Nant weiterhin. Wenn Sie psake verwenden, verwenden Sie weiterhin psake. Wenn Sie ein Powershell-Skript verwenden, verwenden Sie dieses weiterhin. Etc! Höchstwahrscheinlich muss nur der "dotnet build"-Teil durch einen Aufruf von MSBuild ersetzt werden. (Vielleicht ist nicht einmal das notwendig, wenn dotnet build-Aufrufe in MSBuild aufruft)

Ich würde argumentieren, dass dies MSBuild zu einem ziemlich unwichtigen Implementierungsdetail macht. So habe ich es in den letzten zehn Jahren gesehen und so werde ich es auch weiterhin sehen.

Aber wie ich bereits zu Beginn dieses Threads sagte, brauchen wir natürlich einige der _Features_ von project.json und Visual Studio, um das csproj besser zu behandeln - und ich verstehe nicht, warum sie das nicht tun sollten das liefern können.

@jtmueller Es gibt absolut keinen _technischen_ Grund, warum Sie F# (oder VB.net, wenn Sie dazu neigen) nicht verwenden können. Es würde mich nicht wundern, wenn ein Teil der Umstellung auf MSBuild-Projektdateien dazu beitragen würde, dies zu erleichtern. DNX war damit nie wirklich zufrieden, aber CoreCLR unterstützt definitiv F#. Ich weiß nicht, ob Sie F# mit RTM verwenden können, aber es ist definitiv in Vorbereitung.

@jtmueller project.json ist so ziemlich eine Projektdefinition mit Abhängigkeitsmanifest plus benutzerdefinierten Befehlen. Da ist überhaupt nichts an eine bestimmte Sprache gebunden.

Mein Traum-Build-System (um MSBuild vollständig zu ersetzen) würde Roslyn verwenden, um die Aufgaben und Ziele herauszufinden, sodass Sie F# verwenden können, um Ihren Build-Prozess zu definieren (oder C# oder VB.NET, alles, was Roslyn unterstützt).

Das schlägt natürlich noch niemand vor. Aber uns wieder in MSBuild einzuschließen, wird diese Tür mit ziemlicher Sicherheit für sehr lange Zeit schließen.

Hatten eine schöne Pause, und zwar ein bisschen über die Herausforderung, was getan werden muss, um MSBuild zu "retten". Ich glaube nicht, dass wir MSBuild in ein wesentlich anderes Build-System verwandeln können oder sollten. Es ist ein inferenzbasiertes, XML-definiertes Build-System, und das funktioniert für es und für viele Szenarien, insbesondere für einige der komplexeren Szenarien.

Aber nicht alle von uns haben engagierte Build-Master, die sich mit MSBuild herumschlagen können. Nicht alle von uns brauchen die Leistung, die die Komplexität von MSBuild mit sich bringt. Einige von denen, die diese Komplexität benötigen, möchten MSBuild nicht verwenden. In einem meiner Teams zum Beispiel wird die gesamte benutzerdefinierte Build-Logik in Pre- und Post-Build-Schritten ausgeführt, Exec shellt im Wesentlichen zu Powershell. Nicht, weil dies in MSBuild nicht möglich wäre, sondern kann und in diesem Fall wahrscheinlich _sollte_. Aber weil sie es nicht in MSBuild tun wollen .

Schritt eins ist definitiv, dass wir die Projektdefinition vom Build-System trennen müssen. Für mich macht das unglaublich viel Sinn. Wir können darüber diskutieren, Abhängigkeiten aus der Projektdefinition herauszutrennen, aber ich glaube nicht, dass dies erforderlich ist.

Schritt zwei ist, dass wir ein Build-System benötigen. Wir müssen sowohl sehr einfache als auch sehr komplizierte Anwendungsfälle bewältigen. Aber keine Regel besagt, dass ein Build-System _beide_ handhaben muss. Meiner Meinung nach ist es am sinnvollsten, ein einfaches, leichtgewichtiges Build-System zu haben, das im Grunde nur die Projektdefinition erstellt. Es tut restore , build , test und pack .

Ich denke, wir sollten auch nach einer Möglichkeit suchen, _ohne_ eine Projektdefinition zu arbeiten, wobei die Verzeichnisstruktur als Definition verwendet wird. Offensichtlich würde eine solche Situation bedeuten, dass das Standardframework und die Standardabhängigkeiten verwendet werden. Vielleicht möglich, vielleicht auch nicht. Aber wir können uns jedes Element in der Definition ansehen und fragen: "Können wir dafür einen intelligenten Standard ableiten"?

Aber während das wahrscheinlich für 80 % der Anwendungsfälle ausreicht, reicht es für die anderen 20 % nicht aus. Sie brauchen noch etwas. (Vorbehalt: Meinungen zu Verhältnissen von Anwendungsfällen können variieren).

Schritt drei besteht darin, dass wir eine sehr einfache Form der Erweiterbarkeit für dieses Build-System zulassen. Aber wir reden ganz einfach. Grundsätzlich kann es seinen grundlegenden Build oder ein externes Build-System ausführen. Das externe Build-System kann MSBuild oder Skripte oder ein anderes Build-System sein.

Ich bin froh, dass der neue Build-Prozess in der Lage sein sollte, MSBuild zu unterstützen, aber ich glaube nicht, dass etwas so (IMO) altes, streitsüchtiges und aufgeblähtes wie MSBuild die Grundlage für alle zukünftigen Builds sein sollte.

Bei Dingen wie Web-Frameworks sehen wir, wie die MS-Teams hektisch iterieren. Weil sie Konkurrenz haben. Sie müssen sich zum Beispiel Sorgen machen, dass Nancy ihnen im Nacken sitzt. Es ist _einfach_, zu etwas anderem zu wechseln. Und es macht MVC/WebAPI besser dafür.

Da MSBuild in das gesamte .NET-Tooling integriert ist, wird es mühsam, etwas anderes zu verwenden. Wo ist die Konkurrenz? Und Sie können die Auswirkungen im MSBuild Github-Board sehen. Gehen Sie einfach alle geschlossenen Vorschläge durch. Der einzige Grund, warum sie jetzt davon sprechen, diese "abnehmenden" Änderungen vorzunehmen, ist, dass die Leute von project.json zu MSBuild wechseln.

Wenn MSBuild von Anfang an in .NET Core integriert worden wäre, würden wir meiner Meinung nach _keine_ der Bewegungen sehen, die wir jetzt vom MSBuild-Team sehen. Aber was passiert, wenn wir wieder eingesperrt sind? Ist der Wettbewerb einmal grundsätzlich ausgeschlossen? Was wird passieren? Was in Wettbewerbsverbotsszenarien immer passiert und was seit Jahren passiert: gerade genug Verbesserungen, um Massenabwanderungen zu stoppen, aber nichts besonders Interessantes.

Die Leute fragten mich, wie wir MSBuild meiner Meinung nach "retten" können. Ich glaube, dass die Öffnung für echten Wettbewerb und Wahlmöglichkeiten der einzige Weg ist. Es durch Fiat bei allen Entwicklern durchzusetzen, sogar bei denen, die nichts so Mächtiges brauchen (ja, ich glaube, es ist mächtig), wird nur noch mehr Ressentiments dagegen züchten.

Das ist kein Erfolgsrezept eines Frameworks.

Bitte denken Sie daran, dass wir alle wollen, dass .NET erfolgreich ist. Ich _liebe_ .NET, ich denke, dass C# eine der besten Programmiersprachen auf dem Markt ist, und ich habe den langsamen Übergang zu Scala - The Good Parts™ genossen.
Ich glaube nicht, dass wir mit .NET Core neu anfangen und dies tun, indem wir uns an einen der (IMO) schlimmsten Teile von .NET im alten Stil binden. Ja, MSBuild, aber nein, nicht daran gefesselt.

Behalten Sie es auf jeden Fall bei, aber nicht vordergründig in den Kern des Systems eingebaut.

Mein Traum-Build-System (um MSBuild vollständig zu ersetzen) würde Roslyn verwenden, um die Aufgaben und Ziele herauszufinden, sodass Sie F# verwenden können, um Ihren Build-Prozess zu definieren (oder C# oder VB.NET, alles, was Roslyn unterstützt).

YAAAAAAAAAAS!!! Apropos... ist dies der richtige Ort für dieses Gespräch? Wir haben auch die Roslyn- und MSBuild-Repositorys und sie scheinen auch beteiligt zu sein. Ich denke, wir versuchen es im MSBuild-Repo, aber sie sind (wie Sie erwähnen) sehr starr und unflexibel. Ich denke, mehr Leute hier zu haben, wie das Interesse, das dieser Thread geweckt hat, könnte einen großen Beitrag zur Reform leisten.

Schritt drei besteht darin, dass wir eine sehr einfache Form der Erweiterbarkeit für dieses Build-System zulassen.

Ein anbieterbasiertes Build-System/Modell?! GENIUS! Ich stimme dieser Nachricht zu.

Übrigens, wenn Sie Ihren Wunsch haben und Zugriff auf Ihr eigenes Build-System haben, schlage ich vor, wir nennen es ... BERSERKER BUILD! Benannt nach "Berzerker @shederman"... mein neuer Spitzname für dich. :Lächeln:

@Mike-EEE Sei nicht zu aufgeregt. Auf keinen Fall schlage ich etwas so Drastisches vor wie all das _noch_.

Im Moment denke ich, dass es nur die Schritte eins und zwei sein sollten, mit MSBuild-Unterstützung für Schritt drei.

Aber ich dachte, dass wir uns auf diese Art von Möglichkeit zubewegten, als wir project.json bekamen und das Projekt von Build trennten, damit es einfacher wäre, Build-Provider auszutauschen. Meiner Meinung nach schließt die Rückkehr von MSBuild in den Stamm diese Möglichkeiten aus. Oder zumindest macht sie es weitaus weniger wahrscheinlich, dass sie Traktion bekommen.

Im Moment werden benutzerdefinierte Builds nicht angenommen, weil das Root-System so mächtig _ist_. Es ist eine schwierige Konversation, Leute davon zu überzeugen, ein Nicht-MS-Build-System zu verwenden, wenn das MS-Build-System tatsächlich alles tun kann, was benötigt wird (ohne den Schmerz zu ignorieren).

ist dies der richtige Ort für dieses Gespräch?

Ich glaube nicht, nein. Denken Sie auch nicht, dass es jetzt der richtige Zeitpunkt ist. Wir müssen dieses Problem schließen, bevor wir sehen, welche Richtungen möglich sind.

BERSERKER BAUEN! Benannt nach "Berzerker @shederman"... mein neuer Spitzname für dich. :Lächeln:

Ich bin mir nicht sicher, was ich davon halten soll

Ich versuche nicht, ein Berserker zu sein. Ich möchte einfach nicht rückwärts gehen, wenn wir vorwärts _waren_.

Hey Leute, vielleicht anstatt das Rad neu zu erfinden ( nuget.json oder wie auch immer es genannt wird), lasst uns eine bestehende, von der Community betriebene Lösung verwenden, die die meisten Probleme beim Abhängigkeitsmanagement löst - Paket .

1. Es hat das Konzept der transitiven Abhängigkeiten
2. Es ist gut in MsBuild integriert
3. Es hat ein menschenlesbares Dateiformat zum Definieren von Abhängigkeiten
4. Es hat einen sehr guten Migrationspfad von packages.config
5. Und viele andere Funktionen (aber anscheinend sind diese 4 die wichtigsten Dinge für alle, daher werde ich Dinge wie Git-Abhängigkeiten oder eine bessere Paketauflösungsstrategie nicht erwähnen)

@Krzysztof-Cieslak Denken Sie daran, dass der Hauptgrund dafür, dass Microsoft MSbuild-Projektdefinitionen vorantreibt, darin besteht, die Migration derjenigen zu erleichtern, die viel in MSBuild investiert haben. In dieser Hinsicht ist Paket nicht besser als project.json (oder project.yaml oder project.cs oder was auch immer).

Trotzdem sehe ich immer noch keinen Grund, warum Sie nicht das gewünschte Build-System verwenden können. Letztendlich wird sich "dotnet build" nicht ändern, unabhängig davon, in welchem ​​​​Format Ihre Projektdefinition endet, dotnet build wird weiterhin Ihre Ausgabe generieren.

@neoKushan Ja, aber erfordert "dotnet build" eine MSBuild-Datei, auch wenn wir MSBuild nicht verwenden? Wird es erstellt, wenn überhaupt keine MSBuild-Datei vorhanden ist? Oder wird es an MSBuild ausgegeben, das dann an jedes andere Build-System ausgegeben wird, das verwendet wird?

@shederman Zweifellos wird "dotnet build" MSBuild im Hintergrund verwenden, um die Projekte tatsächlich zu erstellen, aber ob wir wirklich etwas davon sehen oder nicht, ist sehr in der Luft. Derzeit benötigen Sie eine project.json, um Ihre Projekte richtig zu erstellen, wenn nicht für Referenzen, dann für andere wichtige Daten (wie Zielframeworks). Irgendwann wird ein Teil (oder sogar alles) davon in eine csproj-Datei migriert, sodass man davon ausgeht, dass Sie diese .csproj-Datei benötigen, damit dotnet build funktioniert, unabhängig davon, was letztendlich im Hintergrund verwendet wird. Welche Auswirkungen dies wirklich auf Sie hat, bleibt jedoch abzuwarten.

Wie gesagt, nur so lange , wie ich die Arbeit zu tun erlaubt bin halten die leichte Build vorhanden, die keine MSBuild überhaupt erforderlich ist , bin ich glücklich. Sie können Ihre selbstreferenzielle "MSBuild überall"-Pipeline in jede beliebige Sackgasse bauen.

Aber wenn das funktioniert, muss csproj project.json einbinden , wie RichiCoder

Auf diese Weise können "Core Build" und "MSBuild" nebeneinander oder Core Build ohne MSBuild funktionieren. Und wenn Sie die Datei project.json nicht importieren, können Sie Ihre Projekteigenschaften natürlich auch in csproj definieren.

Eigentlich eine ganz einfache Änderung. Aus meinem Kopf müssen wir:

• Behalten Sie den vorhandenen Dotnet-Build-Code bei und lassen Sie ihn unter bestimmten (noch zu bestimmenden) Umständen ausführen.
• In anderen wird MSBuild gemäß den Plänen des DotNet-Kernteams ausgeführt
• VS in der Lage sein, entweder project.json oder MSBuild für Projekteigenschaften zu lesen
• Möglichkeit zum Importieren von project.json in MSBuild hinzufügen

Ein ziemlich kleiner Arbeitsaufwand, und es ermöglicht Microsoft, seinen "MSBuild Forever"-Pfad fortzusetzen, und es hält die Versprechen ein, die der .NET Core-Community gemacht wurden, und ermöglicht es denjenigen von uns, die sich von MSBuild abmelden möchten.

Es ist bemerkenswert, dass hier niemand von der asp.net-Mitgliedschaft etwas gesagt hat.

In der Zwischenzeit lese ich einige der Anmerkungen aus dem ASP.NET Community Standup – 10. Mai 2016 , und sie sprechen von einem "neuen" MSBuild-System, sagen aber nicht, was es ist, außer dass es nicht erforderlich ist Visual Studio zu bearbeiten. Es ist schade, dass es nicht in asp.net entworfen wurde und (jetzt) ​​so spät im Spiel hinzugefügt werden muss ... wenn das Design das von Anfang an nicht beinhaltete. Wirklich, project.json sollte nur ein { "BuildSystem" : "MSBuild" }-Element enthalten, wenn Sie diesen Weg gehen möchten/müssen. Ich frage mich auch, warum MS (berühmte letzte Worte) nicht "einfach" Kommentare in Json-Dateien über die Tools zulassen konnte.

@rhires Nach meinem Verständnis enthält das "neue" MSBuild-System einige Optimierungen, um das XML etwas leichter zu machen, z. B. das Einschließen aller cs-Dateien in den Build und das Auslagern der Abhängigkeiten in eine nuget.json-Datei. Keine wesentlichen Änderungen im Design, der Architektur oder der Nutzung von MSBuild.

Ich mag deine project.json-Idee. Ich habe gerade die RC2-Änderungen durchgemacht und sie haben "Testrunner" eingebaut, also gibt es keinen Grund, den man nicht machen könnte. _ABER_, es scheint, dass ihr Herz fest entschlossen ist, project.json vollständig zu entfernen und zu einer MSBuild-first-Welt zurückzukehren.

warum MS (berühmte letzte Worte) nicht "einfach" Kommentare in Json-Dateien über das Tool zulassen konnte

Es gibt keinen Grund, warum sie es nicht konnten. JSON.Net, die von ihnen verwendete Bibliothek, unterstützt Kommentare.

Wirklich, project.json sollte nur ein { "BuildSystem" : "MSBuild" }-Element enthalten, wenn Sie diesen Weg gehen möchten/müssen.

Warum sollte ich wollen, dass mein Projekt sein eigenes Build-System vorschreibt? Sicherlich baut das Build-System das Projekt und nicht umgekehrt?

@neoKushan :

Denken Sie daran, dass der Hauptgrund dafür, dass Microsoft MSbuild-Projektdefinitionen vorantreibt, darin besteht, die Migration derjenigen zu erleichtern, die viel in MSBuild investiert haben. In dieser Hinsicht ist Paket nicht besser als project.json (oder project.yaml oder project.cs oder was auch immer).

Paket ist kein neues Build-System, sondern ein Dependency Manager, der zu 100% mit MsBuild kompatibel ist. Es löst nur das Problem von packages.config .

@Krzysztof-Cieslak Ich habe nie behauptet, dass es sich um ein Build-System handelt und das Abhängigkeitsmanagement kein wirklich großes Problem mit .net-Kern ist (zumindest meines Wissens). .net Core verwendet nicht packages.config sondern project.json .

Wenn .Net Core immer noch geplant wäre, project.json , hätten wir diese 100-Post-Diskussion nicht. ;) Ich sage nur, dass die vielerorts vorgeschlagene Lösung für die Verwendung von "nuget.json" zur Behandlung von Abhängigkeiten darin besteht, das Rad neu zu erfinden, da wir ein Produkt haben, das genau das gleiche tut.

@shederman

„Endgültige Umfrageergebnisse: 100 Antworten, für eine 9 Millionen .NET-Entwicklerpopulation sind das ±10 % mit 95-prozentiger Konfidenz.“

Ja, und wenn Sie auf einer Konferenz nach Katzenspielzeug fragen, welches das bevorzugte Haustier eines Hundes oder einer Katze ist, können Sie ähnliche Ergebnisse erzielen.

@darrelmiller

„Ich denke, es ist wichtig, zwischen MSBuild und der Art und Weise zu unterscheiden, wie Visual Studio derzeit MSBuild verwendet. Ich bearbeite seit Jahren MSBuild-Dateien von Hand und verwende sie für alle meine Projekte. Zum Beispiel https://github.com/tavis- software/Tavis.home/blob/master/build/Build.proj "

Sollen wir die VS-spezifischen Build-Dateien über den Projektdateien diskutieren, bei denen msbuild nicht über die Befehlszeile funktioniert?

@gregoryyoung Wir sollten. Ich habe bereits Build-Dateien erstellt, die von Devenv abhängen, aber keine gesehen, die nicht über die Befehlszeile ausgeführt werden. Irgendwelche Beispiele?

@gregoryyoung

Ja, und wenn Sie auf einer Konferenz nach Katzenspielzeug fragen, welches das bevorzugte Haustier eines Hundes oder einer Katze ist, können Sie ähnliche Ergebnisse erzielen.

Das ist eine interessante Analogie. Außer...

Ich habe den Link in Twitter-Feeds von Leuten gepostet, die den Wechsel zu MSBuild _unterstützt_ haben. Also, eigentlich überhaupt nicht wie Ihre Analogie.

Und ich liebe die fortgesetzten Verleumdungen, dass die Umfrage voreingenommen, im falschen Forum oder unwissenschaftlich war. Aber die Fragen waren nicht führend, die Antworten hatten ein breites Spektrum an Antworten, und die Umfrage war ein selbstgewähltes Publikum, aber ein breites Publikum, das zumindest theoretisch aus meiner Sicht _wegnehmen_ sollte.

Ich habe auch den Eindruck und teilweise Bestätigung, dass die Leute, die diese Vorwürfe machen, nur ein bisschen über Umfragen gegoogelt haben. Ich persönlich habe ein Forschungsprotokoll auf Master-Ebene für eine Gesundheitsstudie entworfen, und obwohl ich nicht behaupten möchte, dass die Umfrage perfekt ist, ist sie sicherlich nicht so fehlerhaft, wie die Microsoft-Mitarbeiter behaupten.

Es ist mit Sicherheit statistisch signifikant und gibt Ihnen einen guten Hinweis darauf, wo die Meinung liegt. GitHub und gitter und Twitter und Blogs unterstützen es in gewissem Maße.

Mehrere Beweisquellen, die dasselbe sagen. Wenn Sie die Meinungen eines bedeutenden Ihrer Benutzer ignorieren möchten, sagen Sie dies. Hören Sie auf zu versuchen, ihre Opposition wegzuwinken, als ob Sie Ihr Recht verlieren würden, Ihre Meinung zu äußern, wenn Sie die „falsche“ Meinung vertreten.

Oder noch besser, wie ich schon oft gesagt habe, erstellen Sie Ihre eigene Umfrage, die die Dinge verbessert, von denen Sie meinen, dass sie mit meinen falsch sind.

Der Grund, warum ich die Umfrage durchgeführt habe, war, dass Microsoft keine Ahnung hatte, was die Leute dachten. Was jetzt ganz klar wird, ist, dass sie kein _Interesse_ daran haben, was die Leute denken.

Hören Sie auf, sich selbst und Ihrer Gemeinschaft gegenüber unehrlich zu sein und engagieren Sie sich für die Opposition, anstatt sie wegzuwinken.

Hören Sie auf zu versuchen, die Fakten zu ändern, und fangen Sie an, Ihre Meinung basierend auf den Fakten zu ändern.

@shederman Ich habe nicht den Eindruck, dass das Microsoft-Team diesen Thread (einschließlich Ihrer Umfrage) wirklich beantwortet hat. Ja, ein Typ aus dem Team sagte, er halte es für nicht so vertrauenswürdig wie Sie, aber das ist alles. Ich denke, es besteht immer noch Hoffnung, dass sie derzeit über den massiven Widerstand gegen ihren eingeschlagenen Weg sprechen und über den richtigen Weg diskutieren und uns antworten, wenn sie mehr wissen.

Ich denke, wir können diesem Team einige Anerkennung zollen ;).

@gregoryyoung Entschuldigung, nach der von Ihnen angegebenen Analogie habe ich angenommen, dass Sie ein MS-Mitarbeiter sind, da sie jetzt seit 2 Tagen ungefähr dieselbe Linie fahren.

@sandorfr

Ich denke, wir können diesem Team einige Anerkennung zollen

Ich dachte, wir könnten, aber meine Erfahrungen in den letzten Tagen haben diese Hoffnung nicht bestärkt.

Ich muss denken, es ist nicht "das Team" schuld, sondern jemand weiter oben in der Organisation, der diese Entscheidung getroffen und auferlegt hat ... und dann muss "das Team" es schlucken und es hübsch aussehen lassen. BTDT. Kein Spaß.

Ist Ihnen allen klar, dass project.json in letzter Zeit bereits großen Änderungen unterzogen wurde , um es mit Nicht-ASP.NET Core-Anwendungen kompatibel zu machen? Wenn Sie sich nur das Beispiel in diesem Ankündigungspost ansehen, wird es mit all dieser Build-Konfiguration bereits ziemlich aufgebläht.

Davon zu einer „klassischen“ csproj-Datei zu gehen, scheint mir eigentlich gar nicht so weit zu sein. Und wenn sich das csproj selbst auch ein bisschen in die flexiblere Richtung entwickelt, die wir aus dem project.json gelernt haben, kann ich tatsächlich sehen, dass das „neue und verbesserte“ csproj wirklich gut funktioniert. Und ich denke, wir können mit Sicherheit davon ausgehen, dass diese jüngsten Änderungen an project.json nicht die letzten im Kurs waren, um es für _alle_ Arten von .NET-Projekten nutzbar zu machen – ich denke, es ist wichtig, dass wir das nicht vergessen sind viele andere Ziele außer ASP.NET (Core).

Und es sollte eigentlich keine Rolle spielen, ob das Dateiformat JSON, XML oder was auch immer ist. Ja, das eine kann aus verschiedenen triftigen Gründen dem anderen vorgezogen werden, aber am Ende sollten Sie sich überlegen, wie viel Zeit Sie tatsächlich in einer Projektdatei verbringen möchten . Ja, mit den Problemen, die wir mit den aktuellen Formaten hatten, verbrachten wir mehr Zeit als uns lieb war, aber wenn wir diese Ursachen beheben sollten, sollten wir im Idealfall einen unglaublich kleinen Bruchteil unserer Zeit mit diesen Dateien verbringen. Und zu diesem Zeitpunkt sollten Sie sich nicht wirklich darum kümmern müssen, in welchem ​​​​Format es ist. Vor allem, wenn es schließlich Tool-unterstützt ist (einschließlich der vollständigen Vervollständigung in Editoren).

Ich habe das Gefühl, dass die Leute, wenn sie an project.json denken, hauptsächlich an die frühen Phasen denken, bei denen es viel um Konventionen vor Konfiguration ging. Ja, das war super nett, aber auch sehr spezifisch für ASP.NET Core und daher sehr eingeschränkt. Es wird für andere Ziele nicht wirklich gut funktionieren, daher ist es sinnvoll, etwas zu verwenden, das seit vielen Jahren gut funktioniert, und es zu erweitern und auf jede erdenkliche Weise zu verbessern, während die Kompatibilität gewahrt bleibt.

Also, tl;dr: Ja, ich mag project.json wirklich und wünschte, es gäbe eine Möglichkeit, es für ASP.NET Core zu behalten (zB mit einer speziellen MSBuild-Aufgabe). Aber gleichzeitig verstehe ich vollkommen, warum das jetzt passiert, und ich denke, dass es eigentlich nicht schlecht ist, was sie tun. Natürlich ist das Timing etwas seltsam, aber da die Änderung nicht parallel zur Veröffentlichung von ASP.NET Core und .NET Core erfolgen wird, glaube ich nicht, dass das Timing ein tatsächliches Problem ist (vorausgesetzt, der Übergang wird später reibungslos verlaufen) ).

Sie müssen in der Lage sein, Quelldateien projektübergreifend freizugeben

@darrelmiller Das klingt für mich beängstigend, denn das scheint zu bedeuten, dass das Auflisten von Dateien in der .csproj-Datei zurückkommt.

@lokitoth Angenommen, csproj funktioniert für Dateiverweise ähnlich wie das neuere project.json, es gibt nichts, was Sie daran hindert, Globs im Allgemeinen zu verwenden und neben ihnen einzelne Dateiverweise zu haben.

@shederman Ich bin kein MS-Mitarbeiter, sondern nur eine rationale Person. Wenn Sie mich googeln, werden Sie sicher feststellen, dass ich ein langfristiges Interesse an der Plattform habe.

Mit der Änderung sind viele Vor- und Nachteile verbunden, aber Ihre Angaben sind für eine vernünftige Diskussion nicht hilfreich.

Dies war eine enttäuschende Änderung. project.json, automatische Dateieinbindung/-globbing und transitive Wiederherstellung waren die ersten Dinge an ASP.NET Core, die mich dazu brachten, "oh, schön!" am Anfang.

Mir ist klar, dass nicht alles verschwinden würde (hoffe ich?). Aber es fühlt sich schlecht an, zu einer XML-Projektdatei zurückzukehren, denn historisch gesehen hat dies den Menschen Kopfschmerzen bereitet. Ich hasse es, eine csproj-Datei zu öffnen, um ein Problem zu beheben, da es sich um eine Wand aus schwer zu analysierendem Text handelt.

Nur meine zwei Cent.

Wenn man sich die Änderungen in @pokes Post ansieht, sieht es so aus, als ob sie das csproj im Grunde in json übersetzt haben, was ehrlich gesagt auch ziemlich eklig ist.

Aufgrund der Tatsache, dass sie die Optionen Compile, Embed, CopyToOutput, Exclude, Shared Files usw. unterstützen möchten, würde das Json-Format sowieso nicht besser funktionieren als XML. Ich vermute auch, dass json für umfangreiche Build-Skriptanpassungen nicht so gut funktioniert hätte.

Ich hoffe nur, dass dies das Team ist, das versucht, keine weitere halbgebackene Lösung in die Produktion aufzunehmen, bis sie Zeit haben, einen Weg zu finden, es gut zu machen.

@gregoryyoung, was Sie zur Verfügung gestellt haben, ist für keine vernünftige Diskussion nützlich

Toll. Okay, mal sehen, was ich bereitgestellt habe:

• Ich habe mich wie viele andere über die Umstellung auf XML beschwert
• Ich habe mich wie viele andere über den Wechsel zu MSBuild beschwert
• Ich habe versucht, die Gründe und Beweise für die Entscheidung zu verstehen, die abgesehen von einigen sehr handgewellten Sachen nicht wirklich vorgelegt wurden
• Ich habe versucht, auf das zugrunde liegende _Denken_ hinter der Entscheidung zu kommen, das _auch_ nicht wirklich bereitgestellt wurde
• Ich habe die Community nach ihrer Meinung gefragt, was MS überhaupt nicht gemacht hat
• Ich habe versucht, Alternativen zu finden, die die von den Leuten angegebenen Ergebnisse ermöglichen, aber auch der Community ermöglichen, ihren einfachen Build-Prozess beizubehalten, der ihnen Spaß macht
• Ich habe angeboten, die erforderliche Arbeit zu leisten, um diese Alternativen zu unterstützen

Darf ich aus Interesse fragen, was das Wahnsinnige daran ist? Das Denken von jemandem zu hinterfragen ist heutzutage nicht rational? Oder habe ich etwas da draußen gelassen?

Ich meine, ich bin wütend , versteh mich nicht falsch. Ich habe viel Arbeit, Zeit und Geld damit verschwendet, ein Kernversprechen des Frameworks aufzubauen, das in letzter Minute in einem scheinbar überstürzten und schlecht durchdachten Schritt weggerissen wurde. Habe ich kein _recht_, wütend zu sein?

PS. Ah, du bist _that_ Greg Young. Respektieren. Liebe deine Arbeit. Ich wirklich.

@bzbetty da stimme ich dir

Wenn Sie also einen Build-Prozess zu project.json hinzufügen, würden Sie genau den gleichen Fehler machen, den MSBuild/VS gemacht hat.

Die Projektdefinition sollte vom Buildprozess getrennt stehen und in den Buildprozess eingespeist werden.

Und dann muss man sich fragen: Wenn Ihr Projekt einfach ist und nur die Projektdefinition erstellen muss, brauchen Sie dann wirklich ein schweres, erweiterbares, anpassbares, flexibles und kontra intuitives Build-System, nur um einen einfachen Build durchzuführen?

Sag es anders. Wenn Sie eine so einfache Projektdefinition _hätten_ und ein sehr einfaches Build-Tool, das nichts weiter tun könnte, als die Projektdefinition zu erstellen, würden Sie sich dann dafür entscheiden, ein MSBuild oder ein NAnt oder ähnliches zu installieren und zu verwenden?

Nein, wahrscheinlich nicht, oder? Ich meine, warum die Komplexität unnötig erhöhen. Ein Kernelement effektiver Software-Engineering-Praxis ist es, die Dinge einfach zu halten.

Aber wenn Sie einmal auf ein Szenario stoßen, das das einfache Tool zum Erstellen der Definition nicht bewältigen kann? Sicher, _dann_ würden Sie.

Ich sage, installieren Sie beide Tools nebeneinander, damit wir das für unsere Bedürfnisse am besten auswählen können. MS sagen: Nein, Sie brauchen immer nur das komplexe und nicht intuitive Tool, aber wir entfernen die ungeheuerlichsten Funktionen.

Seifenschale

Ich möchte nur ein wenig Forschung teilen, die ich gemacht habe. Ich habe mir Twitter, Slack, Github, Gitter und Jabbr angesehen.

Ich habe sehr wenig Unterstützung für den Wechsel außerhalb des Kernteams gesehen. Ich meine, es gab einige, aber nicht viel. Die meisten Leute sind ziemlich verärgert über den Umzug.

Ich war auch ziemlich bestürzt über die Tendenz vieler im Lager der MSBuild-Befürworter, zu schlussfolgern, dass ihre Gegner falsch informiert oder, noch häufiger, unqualifiziert sind. Dies geht einher mit der Tendenz im pro-project.json-Lager, auf schlechte Motive zu schließen (mich eingeschlossen, mea culpa).

Ich möchte folgendes fragen:

• Menschen, die davon ausgehen, dass die Menschen, die eine andere Meinung haben als ihre eigenen, diese aus guten Gründen vertreten. Sie sind nicht verblendet, inkompetent, mitschuldig oder verrückt
• Menschen, die Argumente und Beweise angreifen und nicht Menschen
• Alle vorgelegten Beweise sollten nicht ohne triftige Gründe von der Hand gewiesen werden

Argumente für
Die Hauptgründe, die ich für den Wechsel zu MSBuild gesehen habe, sind:

• Tooling-Unterstützung - Um Roundtrips zwischen verschiedenen Tools zu ermöglichen, z. B. VS, VSCode, Xamarin usw.
• Bestehende Investitionen – Große Kunden haben bestehende Gebäude, die es sich nicht leisten können, weggeworfen zu werden
• "Muskelgedächtnis" - Die Leute sind an MSBuild gewöhnt

Argumente gegen

• Bestehende Investitionen – Investitionen in .NET Core-Tools: nach RC. RC _sollte_ keine größeren Breaking Changes bedeuten
• CSProj/MSBuild fies - bisherige negative Erfahrungen im Umgang mit csproj und MSBuild
• Schritt zurück – Der Wechsel zu project.json war der Wechsel zu einer neuen Arbeitsweise, teilweise um eine neue Generation von Entwicklern anzuziehen. Das wird rückgängig gemacht

Meinung
Ich habe für ein vollständiges SurveyMonkey-Abonnement bezahlt, damit ich auf die vollständigen Ergebnisse zugreifen kann (und nicht auf die ersten Hundert). Es sind 321 Antworten, was normalerweise einer Fehlerquote von ± 5,5 % und einer Konfidenz von 95 % für eine 9 Millionen Bevölkerung entsprechen würde.

Die häufigsten Argumente, die ich gegen diese Umfrage gehört habe, sind:

• Die Fragen/Antworten sind voreingenommen: Das glaube ich nicht, und selbst wenn, sind sie es nicht. Es gibt ein breites Spektrum an Antworten.
• Die Umfrage wurde einem voreingenommenen Publikum zugänglich gemacht: Twitter? An die Follower der verschiedenen Zeitleisten der Teammitglieder. Ich bin mir nicht sicher, wie das ein voreingenommenes Publikum ist.
• Nicht wissenschaftlich relevant: Okay, hab mich auf diesen Punkt gebracht. Ich habe kein vollständiges Forschungsprotokoll erstellt, daher würde es die Peer-Review nicht bestehen. Ist dies das Maß an Sicherheit, das erforderlich ist, um die Unterstützung für einen Vorschlag einzuschätzen?

Hier sind sie:

Mein Appell an alle, die das .NET-Framework lieben, ist, die Angst vor diesen Änderungen nicht zu unterschätzen und das Feedback zu berücksichtigen und mit der Community auf der Grundlage zu kommunizieren, dass ihre Bedenken berechtigt sind und aus fundierter Erfahrung stammen .

Und wenn die Entscheidung trotzdem getroffen werden soll, sollten bessere Argumente und Beweise als bisher vorgelegt werden.

Man @shederman erinnert mich an mich (und viele andere), als Silverlight es gegessen hat , außer x10 und konzentrierter / erfahrener. Wahrscheinlich unterstütze ich ihn deshalb :100:%! Haha.

Eines der größten Probleme mit MSBuild in seiner aktuellen Form besteht darin, dass eine Projektdefinition mit einem Buildprozess verschmolzen wird.

Wenn Sie also einen Build-Prozess zu project.json hinzufügen, würden Sie genau den gleichen Fehler machen, den MSBuild/VS gemacht hat.

Die Projektdefinition sollte vom Buildprozess getrennt stehen und in den Buildprozess eingespeist werden.

:+1: :+1: :+1: ... Hervorragende Art, das Problem einzugrenzen!!! Weißt du, ich habe so lange meine Nase darin, dass mir das nie wirklich in den Sinn gekommen ist. Aber Sie sind (wieder) 100 % auf dem Punkt.

Ich hasse es, eine csproj-Datei zu öffnen, um ein Problem zu beheben, da es sich um eine Wand aus schwer zu analysierendem Text handelt.

Das muss irgendwo eingerahmt werden, @nbarbettini! Fängt auch mein Gefühl perfekt ein.

Und es sollte eigentlich keine Rolle spielen, ob das Dateiformat JSON, XML oder was auch immer ist.

Ja, ich hasse es, die Leute daran zu erinnern, aber es scheint, dass einige Entwickler an der Vorstellung von Formaten festhalten, und das ist irreführend. Das "JSON"-Projektparadigma ist nicht wirklich ein "JSON-Ding", sondern verwendet JSON als Serialisierungswahl, um sein "Modell" zu beschreiben. Die Tatsache, dass JSON knapp und weniger gesprächig ist als XML, machte es (für die meisten) noch attraktiver.

Dementsprechend ist MSBuild nicht per se in XML verwurzelt, sondern wurde so konzipiert, dass sein "Modell" in diesem Format beschrieben wird. Ich sage "Modell", weil beide Systeme an einem (was ich für einen) Konstruktionsfehler halte, ein Dokumentmodell vor dem eigentlichen Modell/API zu platzieren, das letztendlich in den Speicher deserialisiert wird. Das bedeutet, dass mehr Artefakte und Konzepte verwaltet werden müssen, als wirklich notwendig sind, und verkompliziert letztendlich das System. Eine harte Codierung, um nur ein bestimmtes Format (XML oder JSON) zu akzeptieren, macht es nur noch schlimmer, und wir sollten auch hier nach Möglichkeiten suchen, diese Einschränkung zu mildern.

Wie auch immer, lahmer Sonntagmorgen PSA für alle. :stuck_out_tongue:

Ich konnte dies nirgendwo in diesem Thread sehen, also hier geht es ... https://youtu.be/N9MteJH-HsQ. Hoffentlich erklärt es ein bisschen mehr darüber, warum die Änderung vorgenommen wird.

@shederman

„Darf ich aus Interesse fragen, was das Wahnsinnige daran ist? Jemandes Denken zu befragen ist heutzutage nicht rational?

Ich bezog mich auf die Umfrageergebnisse und versuchte, auf die allgemeine Entwicklerpopulation zu extrapolieren. Wie ich bereits erwähnt habe, entspricht dies in etwa der Durchführung einer Umfrage, bei der es um bessere Hunde vs. Katzen auf einer Katzenspielzeug-Convention geht, und wenn man davon ausgeht, dass dies auf die Gesamtpopulation zutrifft, gibt es eine große und offensichtliche Stichprobenverzerrung.

GitHub auf meinem Handy lässt mich @gregoryyoung nicht +1, aber +1.

Das Team hat erklärt, dass ein Grund für die Änderung die Übernahme von Xamarin ist, was eine große Sache ist. Das Potenzial zur gemeinsamen Nutzung von Bibliotheken zwischen .NET-, ASP.NET- und Xamarin Mobile/x-plat-Projekten ist immens, und wenn dies bedeutet, dass das Projekt-/Build-Dateiformat beeinträchtigt wird, ist dies IMHO ein lohnender Tausch.

Ich werde abwarten, wie die Werkzeuge und die endgültige Dateieinrichtung aussehen, bevor ich mir eine endgültige Meinung bilde.

@gregoryyoung Ich

Welcher Stichprobenbias wäre das? Diejenige, in der es hauptsächlich auf Twitter-Feeds von Leuten gepostet wurde, die die Änderungen _liken_? Diejenige, bei der es auf Slack-Kanälen war, die das Entwicklerteam verwendet?

Die Hauptverzerrung der Stichprobe, die ich sehe, ist, dass die Befragten wahrscheinlich engagiert, informiert und leidenschaftlich sind. Sicher, das ist wahrscheinlich keine repräsentative Stichprobe, aber ich würde argumentieren, dass es eine wichtige ist. Und bedeutet das selbst bei Stichprobenverzerrung, dass die Ergebnisse verworfen werden müssen? Dass die Standpunkte der Befragten keine Rolle spielen?

322 professionelle .NET-Entwickler haben ihre Meinung geäußert. Werden Sie ihren Beitrag völlig ignorieren, weil Sie (ohne Beweise für Sie) glauben, dass er nicht repräsentativ ist?

Anscheinend kommt nächste Woche ein Blogbeitrag, dann werden wir konkretere Dinge besprechen.

Jeez Leute müssen sich zum Teufel beruhigen :)

Ich stimme zu, dass diese Veränderung groß erscheint, aber ich denke, sie wird die Menschen viel weniger beeinflussen, als es den Anschein hat. Denken Sie daran, wenn das Team über "Werkzeuge" spricht, beinhaltet dies auch die cli. Jede erforderliche Konvertierung wird auch von der cli durchgeführt, "Tools" zum Hinzufügen von Referenzen, die meiner Meinung nach sogar besser sind, als sie entweder in json oder xml einzugeben, befinden sich in der cli. Globbing wird bereits in msbuild unterstützt. Msbuild wird natürlich im Don't SDK enthalten sein, so dass es keine zusätzlichen Installationen geben wird, die neue Projektgeschichte wird auch dieselbe sein, die dotnet-Befehle werden nur andere Dinge unter der Haube tun. (Ich bin kein Microsoftie, aber das scheint sehr wahrscheinlich)

Das Team sind keine Idioten, sie nehmen diese Änderung nicht leichtfertig vor. Sie haben Gründe angegeben, hauptsächlich Kompatibilität und Kohärenz mit dem Rest der Plattform über Sprachen, native Referenzen und Projekttypen, Granularität von Nuget-Paketen und so weiter. Es ist erst eine Woche her und sie haben gesagt, dass sie die Änderungen und ihre Gründe sehr bald detailliert beschreiben werden.

Ich wünschte, die Leute würden zumindest darauf warten und was ihre tatsächlichen Pläne sind, bevor sie den Umzug komplett verurteilen.

Und ja, ich habe csproj/tfproj-Dateien von Hand debuggt und gegen bedingte Regeln für die Dateieinbindung und all das Zeug gekämpft. Verdammt, ich habe sogar benutzerdefinierte Build-Aufgaben geschrieben. Aber am Ende des Tages ist es viel einfacher, ein komplexes System mit einfachen Werkzeugen (Cli enthalten) zu abstrahieren, als dass das relativ einfache project.json-System alle komplexen Szenarien unterstützt, die es unterstützen muss.

Anders ausgedrückt, die Einfachheit, die die Leute in project.json liebten, war bereits weg, es musste die komplexe Realität einer verallgemeinerten Dotnet-Umgebung mit allen Arten von Projekten und Szenarien unterstützen. Hätten sie das alles in project.json implementiert, hätten Sie im Grunde wieder msbuild. Ich bevorzuge es viel, dass sie einen Schritt zurücktreten und das Build-System als Ganzes betrachten, anstatt Feature für Feature an project.json zu heften, bis es zu einem großen Knäuel wird

Lass uns einfach sehen, was sie vorschlagen, und dann spezifische Probleme ansprechen, wenn wir daran Fehler finden :)

@aL3891

Wenn das Team seine Argumentation und die in Betracht gezogenen Alternativen klar darlegt und warum sie abgelehnt wurden, und auch die hier vorgeschlagenen Vorschläge in Betracht zieht und sich darauf einlässt, dann bin ich daneben und werde jede gut begründete Lösung unterstützen, die kommt aus einem solchen Prozess.

Tatsächlich habe ich seit drei Tagen genau danach gefragt. Einblick in den Entscheidungsprozess und die Beweise, die ihn untermauern. Die diesbezüglichen Informationen waren bestenfalls überwältigend.

Wenn wir es bekommen, +10 von mir.

@aL3891 Kurze Frage. Einige Leute sagten, wir sollten am Mittwochsstand teilnehmen, um diese Probleme anzusprechen. Wollen Sie damit sagen, wir sollten lieber auf den Blogbeitrag warten?

Jeder sollte sich auch daran erinnern, dass dies alles Open Source ist. Wenn Sie der Meinung sind, dass Nicht-msbuild besser ist, teilen Sie einfach die vorhandenen Tools mit und halten Sie sie am Laufen. Wie bei allen interessanten Software-Design-Entscheidungen gibt es Vor- und Nachteile für alle Seiten des Arguments. Microsoft muss auf seine großen zahlenden Kunden eingehen, aber zu ihrer Ehre haben sie all diese Dinge Open Source gemacht. Wenn etwas anderes für Sie funktioniert, tun Sie es.

Ich habe mir das Youtube-Video angesehen, das @khellang gepostet hat - Die Änderungen von ASP.NET waren _revolutionär_, aber es sieht so aus, als ob es am Ende zu revolutionär war, und jetzt mit Xamarin im Mix wird _revolutionär_ es nicht schaffen.

Darüber hinaus schien die Idee, das Rad neu zu erfinden, nicht attraktiv, obwohl es anscheinend das Richtige war ... aber schon wieder ein Vermächtnis.

Ich habe eine neue Kritik an der Verwendung von MSBuild, die auf dem .NET-Standup basiert – während wir an einigen Stellen eine gute Trennung der Bedenken haben, ist dies bei MSBuild nicht der Fall. Im Großen und Ganzen, so das Standup, muss es irgendwie alles wissen, um effektiv zu sein, und nur verschiedene Stücke zu orchestrieren, reicht nicht aus.

In der Zwischenzeit, und ich denke, dies sollte in einem anderen Thread behandelt werden - es scheint, als ob es "interne Engineering-Entscheidungen" gibt, die später mit der Community geteilt werden. Dies lässt mich denken, dass MS nicht vollständig Open Source wird - hätten sie diese Diskussionen offen geführt (und die Leute darauf aufmerksam gemacht), wäre es weniger überraschend gewesen und wir hätten vielleicht bereits Antworten, und viele Interessengruppen (und ich meine die Kunden, die von einer Abkehr von MSBuild negativ betroffen wären) hätten ihre Positionen früher deutlich machen können und die Community hätte rechtzeitiger auf Probleme/Anliegen und sogar Lösungen reagieren können auftretende Probleme ... Stattdessen "war es unsere einzige Option", ist der Grund, warum Sie nicht nur die Software, sondern auch den Entwicklungsprozess als Open Source öffnen. So soll die Maxime "bei genügend Augäpfeln sind alle Käfer flach" funktionieren. Ich weiß nicht, wie groß das Engineering-Team bei MS ist, aber es ist kleiner als die gesamte Community, und es gibt einige wirklich gute Talente in der Community, die sich einer Herausforderung stellen könnten, wie sie das Engineering-Team für nicht machbar hielt ...und wahrscheinlich für sie, aber nicht für die gesamte Community. Bei Open Source geht es darum, ungenutzte Ressourcen und Talente zu nutzen, die es da draußen gibt.

Andererseits habe ich vielleicht irgendwo etwas übersehen?

@shederman Ich würde vorschlagen, dass diejenigen mit einem begründeten Interesse sowohl am Standup teilnehmen als auch nach dem Blogbeitrag

Für diejenigen, die sich des Standups nicht bewusst sind, gehen Sie hier: https://live.asp.net/

Sie können es zu Ihrem Kalender hinzufügen und es ist eine lohnende Beobachtung, auch wenn Sie sich nicht für die Änderung der Projektdefinition interessieren.

@shederman Ich habe nicht das Gefühl, wirklich befugt zu sein, jemandem zu sagen, was zu tun ist, aber ich kann Ihnen sagen, was ich tun werde. Verdammt, ich bin nur ein Außenseiter wie der Rest, ich _weiß_ gar nichts :) Ich denke, die Standups und on.net-Shows sind eine großartige Informationsquelle, besonders frühe Hinweise auf das, was kommt, also werde ich es auf jeden Fall beobachten jene. Wenn sie sagen, dass mein Blog-Post kommt, werde ich ihnen zumindest den Vorteil eines Zweifels geben und sehen, was sie zu sagen haben. Aber ich werde wahrscheinlich Kommentare hinterlassen / Fragen zu beiden stellen.

Die neueste on.net-Episode , die oben verlinkt wurde, lieferte jedoch einige gute Einblicke

Es gibt auch das Roslyn Project System Repo , das in den kommenden Monaten höchstwahrscheinlich viel Action

Hat jemand eine TL;DR in der on.net-Episode?

Ich glaube, ich _hasse_ sehr selten, mir Videos über das Programmieren anzuschauen. Gib mir jederzeit eine SMS 😄

Verdammtes Höllenfeuer! Ich bin sogar Nicht-IDE in meinen Lernmethoden 😱

Ich glaube, ich hasse es sehr, Videos über das Programmieren zu sehen. Gib mir jederzeit eine SMS :smile:

Was ist das Problem? Es ist _nur_ eine Stunde Ihrer Zeit. :Grinsen:

@rhires

Geck. Das ist wahrscheinlich einer der besten Beiträge, die ich in den letzten 3 Tagen zu diesem Thema gesehen habe!

Kleiner Preis, um auf dem neuesten Stand zu bleiben, aber jedem das Seine ;)

Basic tl;dr:
Das Team begann, sowohl von internen Kunden wie xamarin als auch von externen Kunden Feedback zu erhalten, dass die Migration bestehender Projekte zu project.json schwierig war und dass project.json mit bestehenden Projekten sowie anderen Toolchains wie nativen und anderen für andere zusammenarbeitet Plattformen wie Android würden bedeuten, eine erhebliche Menge an Code (oder Konzepten) von msbuild einzubringen. Dies würde viel Zeit und Mühe kosten und die Veröffentlichung um einen inakzeptablen Zeitraum verzögern sowie zukünftige Arbeiten verlangsamen (einschließlich für andere Produkte wie xamarin Studio und Mono Develop, sowie Visual Studio-Plugin-Entwickler).

Also entschieden sie sich stattdessen dafür, das Build-System stattdessen auf msbuild zu basieren, aber die Dinge, die die Leute mochten, aus dem neuen System zu integrieren. Was das Timing angeht, war die Übernahme von xamarin nicht einmal bekannt, als RC1 erstellt wurde, aber jetzt, da es abgeschlossen ist, hat sich einiges geändert.

Sie erkennen auch, dass die Leute project.json sehr mögen, und sie sind es auch, und dass sie so viel von dem Guten behalten möchten, vielleicht sogar, um msbuild zu ermöglichen, auch project.json-Dateien über ein Ziel zu lesen. Cli- und VS-lose Szenarien werden auch als Kernszenario angesehen. Sie sprechen auch ein bisschen über andere Build-Systeme und das Ziel ist es, den Leuten zu ermöglichen, andere Dinge als msbuild zu verwenden, wenn sie wollen

Dann reden sie ein wenig über RC2 und was da drin ist und sie überlegen auch, was sie bei der Projektsystemmigration anders hätten machen können, früher offener sein und mehr Gespräche auf GitHub führen und so weiter.

Ich empfehle es anzuschauen, mir fehlen hier wahrscheinlich einige Feinheiten.

@aL3891 - danke für die tolle Zusammenfassung. Es war eine Qual, das Video durchzugehen. Ich bin damit einverstanden, dass sie eine Textzusammenfassung verfassen. Mir ist aufgefallen, dass sie "lernen" und es ihnen immer noch unangenehm ist, ihren Prozess zu öffnen, auch wenn sie sagen, dass es eine gute Sache ist. Hoffentlich wird dies eine gute Lernerfahrung für sie sein und wir werden die Veränderungen sehen und die Nutznießer davon sein.

@aL3891 Danke für die Zusammenfassung!

Kleiner Preis, um auf dem neuesten Stand zu bleiben, aber jedem das Seine ;)

Ah, aber ich bin nicht am Rande der Blutung , ich bleibe da ein bisschen zurück. Gerade weit hinten genug, um mich nicht zu schneiden, dachte ich zumindest, als ich .NET Core nach RC1 einführte 😢

@shederman Angesichts der mögen Sie Ihr Steak?

@neoKushan Ich meinte, dass wir nur ".NET Core _nach_ RC1 übernommen" haben. Wir sind immer noch auf Vanilla RC1.

Also, wir mögen unser Steak medium rare. Aber wir schneiden nur ein wirklich ungekochtes Stück ab und schreien nach dem Kellner.

Aber es ist in Ordnung, ich habe aufgehört, nach dem Kellner zu rufen, und habe jetzt den Maitre'd (unseren Microsoft-Partnervertreter) angerufen, um mich zu besuchen, und wir können die Entscheidungsfindung, die Verbreitung von Informationen und die Ausrichtung der Plattform besprechen.

Wir wissen nichts!

Wir haben in dieser Ausgabe zu wenig Informationen, zu viel Theorie und Vermutungen. Kurze Zusammenfassung für die Faulen, die diesen Thread nicht lesen wollen:

Was wir wissen

1. xproj wird in csproj konvertiert.
2. Wir „könnten“ eine Datei nuget.json haben.
3. Wir verwenden msbuild .
4. Dies wird alles in Etappen passieren.
5. Die Bibliotheken ändern sich nicht.
6. Sie müssen nicht jede Datei in csproj angeben.

Was wir noch nicht wissen

1. Wird csproj in .nupkg's kompiliert?
2. Wird csproj auf mehrere Architekturen und Ziele gleichzeitig kompiliert x86/x64 dotnet/dotnetcore?
3. Wird es eine separate nuget.config-Datei geben.
4. Wie werden Befehle behandelt, um npm/gulp/bower/etc. auszuführen?
5. Können wir sowohl dotnet build als auch msbuild ? Ich bin total bereit für das 'one .net', das
6. Wird intellisense für Projektreferenzen bleiben oder verschwinden?
7. Sind die VS-Tools oder die Befehlszeile gut genug, dass wir die csproj.
8. Bekommen wir dotnet add reference MyAssembly Werkzeuge?

Ich denke, dieses Thema sollte geschlossen werden, bis wir mehr Informationen haben.

Ich bin total bereit für das 'one .net', das

Dieser ? :lächeln: :+1: :+1: :+1:

Ich denke, dieses Thema sollte geschlossen werden, bis wir mehr Informationen haben.

aber aber aber... was soll ich dann mit meinem Leben anfangen??? :weinen: :grins:

@RehanSaeed

Und wenn ich Probleme mit der "What We Know"-Liste habe?

Muss ich auf Klarheit in der Liste „Was wir noch nicht wissen“ warten, bevor ich meine Bedenken äußern kann?

Oder muss ich einfach die Klappe halten und es aufsaugen?

Wie ich weiß, möchten sehr viele Menschen... 😉

Von allem, was ich gesehen habe, ist die Entscheidung zu 100% unveränderlich:

Was brauche ich mehr von "Was wir noch nicht wissen"?

@shederman Vielleicht möchten Sie sich das On.Net-Video wirklich ansehen. Es liefert eine Reihe von Gründen für die Entscheidung.

Zur Info: Normalerweise ändere ich die Geschwindigkeit auf 1,5, um es schneller zu sehen. https://www.youtube.com/watch?v=N9MteJH-HsQ

Wenn wir bei einer XML-basierten Projektdatei bleiben möchten, dann können Sie bitte BITTE vorschlagen/anregen/verlangen, dass Tools den Dateiinhalt in eine gewisse Reihenfolge bringen. Und "chronologisch" ist KEINE akzeptable Reihenfolge. Der größte Schmerz, den ich bei den proj-Dateien gefunden habe, ist die Schwierigkeit, sie zusammenzuführen. Einfach alphabetisch sortieren. Ja, wir werden immer noch das gelegentliche Zusammenführungsproblem haben, aber ich werde jeden Tag "gelegentlich" über "allgegenwärtig" setzen.

@MelGrubb Das einzige, was wir wissen, ist, dass das neue Projektlayout NICHT alle vorhandenen Dateien

Für alles, was von Hand verwaltet werden soll, bitte TOML.

JSON macht für die Konfiguration überhaupt keinen Sinn. Es macht noch weniger Sinn als XML.

Für alle Interessierten, es sieht so aus, als ob die RC2-Bits verfügbar sind (Noch kein Blogbeitrag, den ich sehen kann)

https://www.microsoft.com/net/core#windows

und https://www.microsoft.com/net/download#core

Meine zwei Cent, fwiw:

Ich habe die Einfachheit von project.json geliebt. Folgendes möchte ich (und nicht gerne) in MSBuild-basierten Tools sehen:

• MSBuild sollte nicht an VS oder andere IDE/Editoren gebunden sein. Es sollte ein eigenständiges Tool sein, das eigenständig installiert werden kann. (Oder als Teil der dotnet-cli-Installation enthalten.) Ich sage dies, weil ich eine vollständige VS-Instanz auf Build-Agents installieren musste, nur um MSBuild zu erhalten. Das hat für mich nie Sinn gemacht.
• MSBuild (oder dotnet cli, das MSBuild enthält) selbst sollte mit einer Befehlszeile installierbar sein – egal ob apt-get, chocolately, homebrew, powershell oder bash/curl. Wenn ich dies nicht als Teil eines vollautomatischen Setups eines Build-Agenten installieren kann (zB in circle.yml oder Dockerfile), ist das ein Hindernis und eine Quelle von Schmerzen.
• MSBuild sollte sehr befehlszeilenfreundlich sein. Ich sollte in der Lage sein, alles von der Befehlszeile aus zu tun – und daher alles in einem Build-Prozess automatisieren können – in einer circle.yml-, Bash- oder anderen Skriptdatei. Und ich würde gerne eine gute Verwendung von stdin und stdout sehen, damit ich MSBuild-Befehle ein- und ausleiten kann.
• Die Arbeit an einem .NET Core-Projekt in VS Code (oder einem anderen Nicht-VS-Editor) sollte keine VS-spezifischen Informationen in einer csproj-Datei oder anderswo erfordern. Projektinformationen, Nuget-Paketabhängigkeiten, Plattformziele, Compiler-Direktiven usw. sollten von Entwicklern geteilt werden können, die unterschiedliche IDEs/Editoren verwenden. Diese machen in einer Projektdatei Sinn. Aber Leute, die VS nicht verwenden, sollten die VS-Tooling-Einstellungen nicht sehen müssen - diese gehören in eine separate Datei.
• Die Projektdatei(en) müssen leicht verständlich und leicht von Hand zu bearbeiten sein. Tools sind großartig, aber ich sollte in der Lage sein, die Datei zu öffnen und zu verstehen, was die Tools für mich tun. Und nehmen Sie Änderungen einfach vor.
• Obwohl ich weiß, dass es keinen Unterschied in Bezug auf Funktionalität/Fähigkeit gibt, habe ich eine starke persönliche Vorliebe für json gegenüber XML. Ich denke auch, dass die Verwendung von json dazu beitragen wird, Entwickler anzuziehen, die aus anderen Stacks kommen. Es ist schon schwer genug, Leute für .NET zu gewinnen, ohne als erstes eine große, schwer zu entziffernde XML-Datei zu sehen. (Das ist eher emotional als logisch, aber ich denke, es ist wichtig.) Bitte machen Sie zumindest json zu einer Option und verwenden Sie diese Option in Yeoman-Generatoren und anderen neuen Projektvorlagen. Im schlimmsten Fall akzeptieren Sie bitte schnell den unvermeidlichen Pull-Request, der ein einfaches Json-Format im MSBuild-Repository implementiert.
• Es wäre schön, die "Skripte" im npm-Stil beizubehalten, damit ich die Befehle für dev, test, debug, build, run, docker build/run usw. problemlos mit meinem Team teilen kann. Diese könnten in ihren eigenen Skriptdateien stehen, aber sie machen (für mich) Sinn als Teil der Projektdatei.

@jtbennett

"Aber Leute, die VS nicht verwenden, sollten die VS-Tooling-Einstellungen nicht sehen müssen - diese gehören in eine separate Datei."

Nur um es hinzuzufügen, gibt es jetzt auch eine Menge Zeug in anderen Dateien, das wahrscheinlich in die msbuild-Datei eingefügt werden sollte. Ignorierte Dinge sind ein gutes Beispiel dafür, sofern Projektdateien noch unterstützt werden. Ich kann Ihnen nicht sagen, wie viele Projekte ich gesehen habe, die in VS integriert sind, aber nicht über die Befehlszeile

@jtbennett

MSBuild sollte nicht an VS oder andere IDE/Editoren gebunden sein.

Es wird überhaupt nicht an VS gebunden, es wird über Nuget geliefert, ist also an nichts gebunden.

MSBuild (oder dotnet cli, das MSBuild enthält) selbst sollte mit einer Befehlszeile installierbar sein

Dies ändert sich ab heute nicht, Sie können dotnet cli weiterhin über die üblichen Paketquellen installieren.

MSBuild sollte sehr befehlszeilenfreundlich sein.

_MSBuild_ wird effektiv Teil des Builds selbst sein, daher glaube ich nicht, dass Sie Befehlszeilenoptionen übergeben müssen. Donet (CLI) ist jedoch offensichtlich kommandozeilenfreundlich und ich denke, das ist alles, was Sie wollen / brauchen.

Die Arbeit an einem .NET Core-Projekt in VS Code (oder einem anderen Nicht-VS-Editor) sollte keine VS-spezifischen Informationen in einer csproj-Datei oder anderswo erfordern.

Dem stimme ich voll und ganz zu. In der Hoffnung, dass das "neue" Projektformat viel einfacher wird.

Die Projektdatei(en) müssen leicht verständlich und leicht von Hand zu bearbeiten sein.

Sie haben gesagt, dass dies auch für sie eine Priorität ist.

Obwohl ich weiß, dass es keinen Unterschied in Bezug auf Funktionalität/Fähigkeit gibt, habe ich eine starke persönliche Vorliebe für json gegenüber XML. Ich denke auch, dass die Verwendung von json dazu beitragen wird, Entwickler anzuziehen, die aus anderen Stacks kommen. Es ist schon schwer genug, Leute für .NET zu gewinnen, ohne als erstes eine große, schwer zu entziffernde XML-Datei zu sehen.

Ich finde das interessant, ich persönlich finde, dass XML viel einfacher zu entschlüsseln ist als JSON, aber ich denke, vieles davon hängt davon ab, wie gut das Schema (für beide) gestaltet ist. Ich musste in der Vergangenheit einiges fürchterliches XML mit wirklich schrecklichen Elementnamen (wie "Element") entziffern und obwohl MSBuild in dieser Hinsicht keineswegs der schlimmste Übeltäter ist, lässt es sicherlich zu wünschen übrig. Bei JSON kann der Schlüsselname die gleichen Probleme haben.

Anekdotisch musste ich vor kurzem an einem Projekt arbeiten, bei dem jemand versucht hat, JSON in XML-Elemente einzubetten :(

RC2-Blog-Post jetzt verfügbar: https://blogs.msdn.microsoft.com/webdev/2016/05/16/announcing-asp-net-core-rc2/

.net-Core-Post ist ebenfalls verfügbar https://blogs.msdn.microsoft.com/dotnet/2016/05/16/announcing-net-core-rc2/

Danke @neoKushan !

@michaelvolz Ich glaube nicht, dass die Datei bleiben wird, wenn man das glauben darf: https://github.com/dotnet/cli/blob/rel/1.0.0/Documentation/specs/runtime-configuration-file .md

System.GC.Server (alt: gcServer) - Boolescher Wert, der angibt, ob der Server-GC verwendet werden soll (Standard: true).

und

Wir könnten ein anderes Format für die deps-Datei verwenden, aber wenn wir bereits einen JSON-Parser in den Host integrieren, erscheint es am besten, dieses hier wiederzuverwenden.

Scheint ein bisschen seltsam zu sein, dass sie XML für die _Projektkonfiguration_ haben, aber .json für die _Laufzeitkonfiguration_?

Scheint ein bisschen seltsam für sie, XML für das Projekt zu haben, aber .json für die Laufzeit?

Tut es jetzt? :Lachen:

@Mike-EEE Guter Punkt! Ich habe aktualisiert, um hoffentlich zu verdeutlichen, was ich meinte :küssen:

@neoKushan nein du

Aber ja... 100-prozentige Übereinstimmung, dass unterschiedliche Formate innerhalb einer Lösung irrsinnig sind. Ein einheitliches Format auf der ganzen Linie reduziert die Komplexität, den Kontextwechsel und damit die _Verwirrung_. Dies ist einer der Gründe, warum ich sehen möchte, dass MSBuild verschiedene Formate aktiviert und formatagnostisch wird . Ups, Warnung, schamloser Stecker. :Grinsen:

Ich denke, ich werde ein Anhänger deines heiligen Kreuzzugs @Mike-EEE sein, da wir bei msbuild stecken bleiben, machen wir es besser.

Hey danke @sandorfr ...

@Mike-EEE Ich habe einen Teil des Threads gelesen, ich bin jetzt so deprimiert ... Du bist in die alte Welt der alten Köpfe eingetreten :D.

Hoffen wir, dass die Leute bei Microsoft offener für Ihre Ideen sind, denn mit msbuild komme ich eigentlich nur zurecht, wenn die Sache einfacher und unkomplizierter ist und ich keinen Gui brauche, um mein Projekt zu bearbeiten (ja, json intellisense war viel besser) als übliche Visual Studio-Projektregisterkarten).

Du bist in die Legacy-Welt der Legacy-Minds eingetreten :D.

Wellllll-sagte @sandorfr ...wellllll-sagte.

Für diejenigen, die sich des Standups nicht bewusst sind, gehen Sie hier: https://live.asp.net/

OK, ich bin ein totaler Faulpelz und habe das jetzt endlich überprüft. Sieht so aus, als wäre das nächste Standup nächste Woche? Überspringt das Team diese Woche?

@Mike-EEE Interessant, es war definitiv irgendwann für heute Abend geplant, aber ich frage mich, ob sich das geändert hat. Ich habe @shanselman getwittert, hoffentlich ist es nur ein Fehler, aber da RC2 erst gestern herauskam, möchten sie es vielleicht diese Woche überspringen.

OK cool @neoKushan ... nur dafür zu sorgen, dass mein Verstand für einmal auf dem Kopf steht. Natürlich möchte ich auch nicht so schnell mit all unseren Fragen und Unzufriedenheit umgehen. :zwinkern:

von Slack:

jongalloway [9:31 AM] Ich bin mir ziemlich sicher, dass ASP.NET Community Standup morgen abgesagt wird - sowohl shanselman als auch damianedwards sind auf der OSCON.
...
Davidfowl [9:34 AM] damianedwards: ist zurück ... aber Shanselman ist in Oscon
...
jongalloway [9:46 AM] Ja, ASP.NET Community Standup ist definitiv für den 17.05. abgesagt. Ich habe die Seite aktualisiert.

@Mike-EEE kümmert sich um all unsere ... Unzufriedenheit

😆

Falls noch Zweifel bestehen: https://twitter.com/shanselman/status/732585321775267842

überspringen müssen. Ich bin bei #vslive und OSCON

Eine Sache macht mir bei project.json sehr viel Spaß: Alle Dateien werden standardmäßig in das Projekt eingebunden, ohne dass jede dieser Dateien explizit eingebunden werden muss. Bei großen Projekten (ich meine Tausende von Dateien) war der Zusammenführungsprozess wegen XML wirklich mühsam, aber auch weil jede Datei im csproj aufgelistet wurde.

Wissen wir, ob es auf dieser Seite Verbesserungen geben wird?

@pierrus Es wurde erwähnt, dass sie nicht zu den Tagen zurückkehren möchten, in denen alle Dateien im csproj aufgelistet waren.

@MaximRouiller OK, das wusste ich nicht,

@MaximRouiller aber sie wollen zu den Tagen zurück zu gehen , wo MSBuild der Ein Ring ™ war, ich meine Build - Tool. 😉

_Ash nudertog vegal durbatulûk, Ash nudertog vegal gimbatul,
Esche nudertog vegal thrakatulûk agh burzum-ishi krimpatul._

@shederman Ich habe meinen Standpunkt seit meiner ersten Reaktion auf die Nachrichten moderiert.

Ich denke, dass sie ursprünglich das Format project.json ausliefern wollten, aber die Normalisierung des Modells mit csproj/Xamarin würde sie nur erfordern, das Framework noch länger zu pushen. Der schnellere Gewinn war die Rückverschmelzung mit csproj. Sie könnten den neuen Weg in einer separaten Datei aufbewahren, während die reinen "nur Daten" im csproj aufbewahrt werden. Das erklärt für mich die massive Arbeit von RC2.

Wenn Sie Eigenschaften verschieben, die sich kaum ändern, und die coolen neuen Funktionen in einer separaten Datei aufbewahren? Wir verlieren nicht wirklich etwas. Ja, wir gehen zurück zum Monster... aber wir sind nicht allzu weit davon entfernt.

Dazu habe ich kein Insiderwissen. Das ist reine Spekulation meinerseits.

Wie auch immer... wir landen nicht mehr in einem jährlichen Release-Zyklus. Wenn sie bereit sind, nach RTM von project.json zu csproj zu wechseln, gehe ich davon aus, dass auch nach RTM größere Änderungen veröffentlicht werden könnten.

Änderungen, von denen niemand außer dem MS-Team Kenntnis hat.

@MaximRouiller Ich kann "mögliche" Änderungen, die _möglicherweise_ kommen, nicht abarbeiten.

Ich arbeite nur die angekündigten Änderungen ab, die vom Lightweight-Build weggehen, um MSBuild und xproj für alles zu verwenden.

Ja, wir gehen zurück zum Monster... aber wir sind nicht allzu weit davon entfernt.

Ähm, wenn wir etwas _deprecated_ haben, das für 90% der Anwendungsfälle funktioniert, um _zurück_ zu etwas zu verschieben, das für diese Anwendungsfälle zu kompliziert ist, habe ich nur eine Frage:

Wieso den?

Warum ruft dotnet build MSBuild auf, wenn msbuild bereits recht gut macht. Warum einfachen Build verwerfen? Warum zusätzliche Arbeit? Der einzige Grund ist einfach, die Entscheidung wurde getroffen, dass wir alle MSBuild die ganze Zeit für alles und für immer verwenden müssen.

etwas, das für 90% der Anwendungsfälle funktioniert

[Zitat erforderlich]

Selbst unter der Annahme, dass es sich um 90 % der Anwendungsfälle handelt, würden Sie mit allem arbeiten, das in 1/10 der Fälle fehlgeschlagen ist?

gehe zurück zu etwas, das zu kompliziert ist

Nochmal, [Zitat erforderlich], das einzige, was wir bisher wissen, ist, dass es das XML-csproj ist und keine Dateiliste enthält. Wir wissen nichts anderes darüber, wie das System funktionieren wird, und ich bin nicht überzeugt, dass wir es überhaupt wissen müssen, weil alle hier nur "dotnet build" nennen und unabhängig davon, wie der Build erreicht wird, wird sich daran nichts ändern.

Warum ruft dotnet build MSBuild auf, wenn msbuild dies bereits recht gut macht.

Sind wir von der Aussage, dass MSBuild "zu kompliziert" ist, zu "MSbuild macht dies bereits ganz gut" übergegangen? Derzeit ist dotnet build nur _scheinbar_ einfach, weil alles, was im Hintergrund passiert, vor Ihnen verborgen ist. Der Wechsel zu MSbuild ändert daran nichts, für Sie ist es immer noch nur dotnet build .

Für jemanden, der immer wieder sagt, dass zwischen dem Projektsystem und dem Build-System unterschieden werden muss, wollen Sie nicht akzeptieren, dass es tatsächlich einen Unterschied zwischen MSBuild-XML-Dateien als Projektsystem und MSBuild als Build-System gibt - da ist schon eine trennung.

Arbeitet für 90% der Anwendungsfälle

@shederman Bitte

@shederman Der Grund, warum Sie ein Shim über etwas bauen, ist, wenn Sie es ersetzen möchten. Abstrahieren Sie es, damit Sie die Implementierung ändern können. Wir tun es jeden Tag. Es heißt Refactoring.

Ich hoffe, dass es ersetzt wird. Abgesehen von XML denke ich, dass es im Vergleich zu anderen Dingen auch langsam ist, wenn ich mich richtig erinnere.

Wenn es wie dotnet build die Frage, wie schwer es sein wird, den Unterstreichungsprozess zu ändern? Ist es möglich, msbuild durch etwas anderes zu ersetzen? Wie viel Klebebänder werden benötigt?

Wenn wir eine solche Änderung in 1 oder 2 Strängen Klebeband vornehmen könnten, ist das akzeptabel.

@neoKushan Sind wir von der Aussage, dass MSBuild "übermäßig kompliziert" ist, zu "MSbuild macht dies bereits recht gut" übergegangen?

Ähm, nein. Ich glaube, ich habe gesagt, dass der Befehl msbuild MSBuild recht gut ausführt. Ich habe MSBuild als Tool nicht bewertet. War das nicht klar?

@neoKushan Selbst unter der Annahme, dass es sich um 90% der Anwendungsfälle handelt, würden Sie mit allem arbeiten, das

Niemand sagt etwas über etwas, das versagt . Einige Tools sind für einige Zwecke besser geeignet als andere. Ich würde sagen, dass die Leistungsfähigkeit und Komplexität von MSBuild für etwa 10 % der Builds geeignet ist. Über die genauen Prozentsätze kann man streiten, aber es sind definitiv weniger als 100 %.

@neoKushan Der Wechsel zu MSbuild ändert daran nichts

Ähm, es ändert nichts am Build- Prozess Nr. Es _ändert_ jedoch, was für das Funktionieren des Build-Prozesses benötigt wird (zB die csproj-Datei) und die Geschwindigkeit, mit der er ausgeführt wird.

@neoKushan Sie wollen nicht akzeptieren, dass es tatsächlich einen Unterschied zwischen MSBuild-XML-Dateien als Projektsystem und MSBuild als Build-System gibt - es gibt bereits eine Trennung.

Tut mir leid, aber ich verstehe nicht, dass es eine Trennung ist, wenn ein Tool zwei Dinge tut.

@poke Bitte hör auf, davon

Ich bin nicht. Ich sage, dass die vorgeschlagene Lösung für einfache Builds nicht so gut funktioniert. Einige davon sind ASP.NET-Builds. Ich persönlich sehe auch nicht, warum ich etwas so Mächtiges wie MSBuild für eine einfache Konsolen-App brauche.

@poke Du absichtlich ignorant ab.

Ich hoffe es, ja. Denn was ich bewusst nicht kenne, sind die wunderbaren Vorteile, die Benutzern von MSBuild erwachsen.

@poke Ich schlage Ihnen vor, sich

Alter, ich bin ruhig, das verspreche ich dir.

Ich lasse einfach nicht zu, dass Standpunkte, mit denen ich nicht einverstanden bin, nicht unangefochten bleiben. Ich verspreche Ihnen, dass es kein Zeichen von Aufregung ist. Um Himmels willen, ich war nicht einmal von einem kleinen Trottel aufgeregt, der mich als ignorant bezeichnete

Was irgendwie ironisch ist, wenn dieser selbe kleine Trottel mich auffordert, mich zu beruhigen.

Komisch wirklich.

@MaximRouiller @shederman Der Grund, warum Sie ein Shim über etwas bauen, ist, wenn Sie es ersetzen möchten. Abstrahieren Sie es, damit Sie die Implementierung ändern können

Ah ja, und das wäre ein guter Grund, es zu tun, außer nach dem, was ich gehört habe, gibt es keine Absicht, MSBuild zu ersetzen. Es ist das ausgewählte Build-System für die absehbare Zukunft. Ich würde es begrüßen, wenn wir Projekte ohne MSBuild-spezifische Elemente stehen lassen und dotnet build entweder den bestehenden Lite-Build ausführen oder ein Build-Tool basierend auf etwas auswählen würden, zB config. Wenn Sie MSBuild verwenden möchten, erstellen Sie auf jeden Fall eine msbuild-Datei und führen Sie msbuild .

Ähm, nein. Ich glaube, ich habe gesagt, dass der Befehl msbuild MSBuild recht gut ausführt.

Um dies in den Kontext zu setzen:

Warum ruft dotnet build MSBuild auf?

dotnet build macht weit mehr als "nur" den Compiler aufzurufen, werfen Sie einen Blick auf die aktuelle CLI-Implementierung von dotnet build . Das Erstellen eines Projekts ist nur ein Teil des dotnet build Prozesses. Schließlich wird ein _Teil_ dieses Prozesses darin bestehen, msbuild aufzurufen, aber das ist nicht Ihre Aufgabe, sondern die Aufgabe der CLI.

Ich habe MSBuild als Tool nicht bewertet.

Alles, was Sie in diesem Thread getan haben, ist MSBuild als Werkzeug zu beurteilen. Zu behaupten, dass Sie so etwas nicht tun, ist ehrlich gesagt lächerlich.

War das nicht klar?

Sehr wenig von dem, was Sie sagen, ist klar oder zumindest gut durchdacht.

Niemand sagt etwas über etwas, das versagt. Einige Tools sind für einige Zwecke besser geeignet als andere.

Daher sind einige Tools nicht für ihren Zweck geeignet.

Ich würde sagen, dass die Leistungsfähigkeit und Komplexität von MSBuild für etwa 10 % der Builds geeignet ist.

Nun, das ist interessant, weil jeder einzelne Visual Studio .net-Entwickler da draußen anderer Meinung sein müsste. Sie sagen effektiv, dass MSBuild für 90 % der Benutzer nicht gut ist (wenn Sie die Tatsache ignorieren, dass Sie Zahlen aus dem Arsch ziehen), was - wieder - lächerlich ist.

Ähm, es ändert nichts am Build-Prozess Nr.

Wenn der Prozess unverändert ist, dann ist Ihr einziges Argument, dass Ihnen die Struktur des Projekts nicht gefällt - die Tatsache, dass es sich um MSbuild oder was auch immer hinter der Haube handelt, ist daher völlig irrelevant .

Es ändert jedoch, was für den Build-Prozess erforderlich ist (z. B. csproj-Datei).

Das ist buchstäblich das einzige, was sich tatsächlich ändert, soweit die Leute sehen können.

und die Geschwindigkeit, mit der es ausgeführt wird.

[Zitat erforderlich]

Bitte zeigen Sie mir, wie der neue Prozess schneller oder langsamer ist, da er derzeit nicht existiert .

Tut mir leid, aber ich verstehe nicht, dass es eine Trennung ist, wenn ein Tool zwei Dinge tut.

Da ein Tool nicht zwei Dinge tut, kann MSBuild das Buildsystem sein, aber die Änderung hat mit dem Projektsystem zu tun. Es gibt absolut nichts, was Sie davon abhält, ein anderes Build-System zu verwenden, wenn Sie möchten, es ist einfach nicht trivial.

Ich bin nicht. Ich sage, dass die vorgeschlagene Lösung für einfache Builds nicht so gut funktioniert

dotnet new
dotnet restore
dotnet build

Bitte zeigen Sie mir, wie die vorgeschlagene Lösung etwas am Szenario "einfacher Build" ändert

Einige davon sind ASP.NET-Builds.

yo asp-net web
dotnet restore
dotnet build

Ich persönlich sehe auch nicht, warum ich etwas so Mächtiges wie MSBuild für eine einfache Konsolen-App brauche.

Sie nicht. Sie brauchen nur dotnet build . Die du noch haben wirst. Da ändert sich nichts.

Ich bin ruhig, das verspreche ich dir.

kleiner Trottel

:-1:

@neoKushan Es wäre wirklich nett, wenn Sie das Konzept zwischen einer Antwort auf einen zitierten Auszug und einem Kommentar zur gesamten Diskussion

Ich finde auch, dass man auf jeden Fall eine Chill-Pille nehmen sollte. Wir diskutieren nur, was unserer Meinung nach das Beste für das Framework ist, wir versuchen nicht, uns gegenseitig zu _kämpfen_. Greifen Sie das Argument an, nicht die Person. Nun, das _versuche_ ich nun schon seit einigen Tagen (außer in einem Fall vor kurzem, siehe unten).

Nun, das ist interessant, weil jeder einzelne Visual Studio .net-Entwickler da draußen anderer Meinung sein müsste.

Komisch, ich habe Beweise gesammelt, die etwas anderes sagen. Wo hast du deine her?

Da ein Tool nicht zwei Dinge tut, kann MSBuild das Buildsystem sein, aber die Änderung hat mit dem Projektsystem zu tun. Es gibt absolut nichts, was Sie davon abhält, ein anderes Build-System zu verwenden, wenn Sie möchten, es ist einfach nicht trivial .

Ja. Wir sind uns also einig. Ich würde nur wirklich, wirklich , wie es , wenn es trivial war.

Ist das wirklich eine so unvernünftige Bitte? Wirklich?

Sie nicht. Sie brauchen nur Dotnet-Build. Die du noch haben wirst. Da ändert sich nichts.

Und dotnet build wird was genau tun? An msbuild ausgeben? Warum können wir nicht einfach msbuild wenn wir MSBuild verwenden möchten? Was genau ist der Zweck von dotnet build in dieser Situation? Was fügt es dem Werkzeug hinzu?

kleiner Trottel 👎

Ein Versuch, lustig zu sein, aber du hast wahrscheinlich recht.

@poke Ich entschuldige mich vorbehaltlos.

Es wäre wirklich nett, wenn Sie das Konzept zwischen einer Antwort auf einen zitierten Auszug und einem Kommentar zur gesamten Diskussion verstehen könnten. Ich gehe davon aus, dass Sie dazu in der Lage sind, daher ist die einzige Schlussfolgerung, dass es beabsichtigt ist. Wenn ja, lassen Sie Sie einfach wissen, dass dies eine intellektuell unehrliche Taktik ist. Ich würde hoffen, dass Sie das wussten, aber ich gebe hier den Vorteil des Zweifels.

Buchstäblich keine Ahnung was du meinst.

Ich finde auch, dass man auf jeden Fall eine Chill-Pille nehmen sollte.

...

Greifen Sie das Argument an, nicht die Person.

:RolleyEyeEmoticon hier einfügen:

Komisch, ich habe Beweise gesammelt, die etwas anderes sagen. Wo hast du deine her?

Okay, cool, woher kommt die Zahl von 10 %/90 %?

Ja. Wir sind uns also einig. Ich würde es wirklich sehr, sehr mögen, wenn es trivial wäre.

Was nichts damit zu tun hat, dass sie zu msbuild wechseln, werden Sie bereits Probleme haben, das aktuelle Build-System von dotnet build weg zu ändern.

Und was genau macht dotnet build? Shell out zu msbuild?

Was ist anders, als dotnet build msbuild anstelle von dnx oder roslyn aufzurufen?

Warum können wir nicht einfach msbuild verwenden, wenn wir MSBuild verwenden möchten?

Sie möchten MSBuild jetzt verwenden? Nichts hält Sie auf, es ist heutzutage ein Nuget-Paket. Verrückt werden. Ich bin überrascht, dass du überhaupt fragst, wenn man bedenkt, wie sehr du msbuild hasst.

Was genau ist der Zweck von dotnet build in dieser Situation? Was fügt es dem Werkzeug hinzu?

Diskutieren wir tatsächlich über die Vorzüge von dotnet build ? Du magst dotnet build ? Sie verstehen den Zweck von dotnet build ? Das scheint nicht wahrscheinlich. Was versuchst du zu fragen?

@neoKushan bitte hör auf ihn zu

Okay, cool, woher kommt die Zahl von 10 %/90 %?

Das kam aus meinen persönlichen Erfahrungen. Ich habe festgestellt, dass etwa 90% der Builds, die mein Team und ich in den letzten Jahren erstellt haben, nichts Komplexeres erfordern als das, was der RC1 dotnet build tut.

Was nichts damit zu tun hat, dass sie zu msbuild wechseln, werden Sie bereits Probleme haben, das aktuelle Build-System weg von dotnet build zu ändern.

Bitte klären Sie, ich bin mir nicht sicher, was Sie hier meinen.

Sie möchten MSBuild jetzt verwenden? Nichts hält Sie auf, es ist heutzutage ein Nuget-Paket. Verrückt werden. Ich bin überrascht, dass du überhaupt fragst, wenn man bedenkt, wie sehr du msbuild hasst.

_Seufzen_. Meine Frage ist: Warum sollte dotnet build an MSBuild ausgeben, wenn msbuild das bereits wirklich gut macht? Warum haben zwei Befehle eine Sache?

Ich habe das bisher ungefähr dreimal gefragt, und jedes Mal haben Sie es entweder falsch verstanden oder falsch interpretiert.

Ich frage nach den Aktionen von zwei verschiedenen Befehlszeilenbefehlen
Ich frage, warum beide dasselbe tun werden
Ich frage, wenn beide dasselbe tun, warum nicht einen Befehl haben?
Ich frage, was der zweite Befehl zur Situation beiträgt, wenn beide dasselbe tun
Ich gebe in diesem Zusammenhang kein Urteil über die Qualität der zugrunde liegenden Tools ab, obwohl ich dies möglicherweise an anderer Stelle getan habe
Dieses Urteil an anderer Stelle hat keinen Einfluss auf die gestellte Frage, da es sich bei der gestellten Frage um die Befehlszeilenbefehle und ihre Aktionen handelt, nicht um die zugrunde liegenden Tools
Ich versuche nicht zu diskutieren, was andere Tools in der Vergangenheit möglicherweise getan haben oder nicht, sondern nur, was sie in Zukunft tun sollen

Entschuldigung für die langwierige Erläuterung, die eine Frage mit einem Satz erklärt, aber es ist anscheinend notwendig.

Ein Artikel zu InfoQ :
"Microsoft ist zu dem Schluss gekommen, dass das Projekt project.json gescheitert ist und wieder auf die Verwendung von .csproj-Dateien übergehen wird." :enttäuscht:

Wie gesagt, die Wahrnehmung ist wichtig.

Meine Frage ist: Warum sollte dotnet build auf MSBuild umsteigen, wenn msbuild das bereits wirklich gut macht? Warum haben zwei Befehle eine Sache?

Weil sie nicht nur eines tun?

Warum sollte MSBuild in csc ausgeben, wenn csc bereits gute Arbeit beim Erstellen von Dingen leistet? Warum haben zwei Befehle eine Sache?

Warum sollte dotnet test an den xUnit-Testläufer zahlen, wenn er selbst schon gute Arbeit beim Ausführen von Tests leistet. Warum haben zwei Befehle eine Sache?

Warum sollte dotnet restore an NuGet senden, wenn NuGet bereits gute Arbeit bei der Installation von Paketen leistet. Warum haben zwei Befehle eine Sache?

Du verstehst die Idee... (hoffe ich :wink:)

@sandorfr

@neoKushan bitte hör auf ihn zu

Ich verteidige niemanden absichtlich, ich dekonstruiere Punkt für Punkt das Argument von erwartet :

Greifen Sie das Argument an, nicht die Person.

An diesem Punkt bin ich mir jedoch nicht einmal ganz sicher, was @shedermans Argument ist, da wir anscheinend irgendwie von einem schlechten XML zu einem schlechten MSBuild zu jetzt dotnet build übergegangen sind.

Machen wir weiter.

Das kam aus meinen persönlichen Erfahrungen.

Ist das Ihr "Beweis"? Was, denken Sie daran, Sie fett geschrieben haben:

Komisch, ich habe Beweise gesammelt, die etwas anderes sagen. Wo hast du deine her?

Und jetzt heißt es "Persönliche Erfahrung". Das nennen wir _anekdotische_ Beweise.

Ich habe festgestellt, dass etwa 90% der Builds, die mein Team und ich in den letzten Jahren erstellt haben, nichts Komplexeres erfordern als das, was der RC1-Dotnet-Build tut.

Und was erwarten Sie vom RC2 dotnet build oder dem RTM dotnet build oder dem Post-RTM dotnet build in dieser Hinsicht?

Bitte klären Sie, ich bin mir nicht sicher, was Sie hier meinen.

Ihr Argument scheint (und korrigiert mich, wenn ich falsch liege) etwas in der Art von "Es ist nicht trivial, dotnet build zu bringen, etwas anderes zu tun, als Microsoft es programmiert hat". Was in den Tagen von DNX in Ordnung war, weil wir alle DNX mochten, aber jetzt möchte Microsoft MSBuild unter der Haube verwenden und Sie mögen MSBuild nicht, Sie möchten die Option, MSbuild durch etwas anderes zu ersetzen - mein Punkt war, dass dies ist nichts Neues, wenn Sie ein Problem mit DNX hatten, könnten Sie das auch nicht ändern. Was auch immer Ihr "Problem" mit dotnet build ist, ist nichts Neues und daher denke ich nicht, dass es relevant ist zur _tatsächlichen_ Diskussion hier, die die Struktur von project.json , die in . csproj

Seufzen. Meine Frage ist: Warum sollte dotnet build auf MSBuild umsteigen, wenn msbuild das bereits wirklich gut macht? Warum haben zwei Befehle eine Sache?

@khellang hat dies bereits beantwortet, daher möchte ich mich nicht besonders wiederholen, aber das liegt auch daran, dass ich den Unterschied bereits ziemlich prägnant

dotnet build macht weit mehr als "nur" den Compiler aufzurufen, werfen Sie einen Blick auf die aktuelle CLI-Implementierung von dotnet build . Das Erstellen eines Projekts ist nur ein Teil des dotnet build Prozesses. Schließlich wird ein _Teil_ dieses Prozesses darin bestehen, msbuild aufzurufen, aber das ist nicht Ihre Aufgabe, sondern die Aufgabe der CLI.

Also noch einmal, mindestens zum dritten Mal: dotnet build ist nicht gleichbedeutend mit msbuild . Es ist nicht, wie du es ausdrückst, "zwei Befehle tun eine Sache" und war es auch nie. Das war noch nicht einmal Gegenstand dieser ganzen Diskussion, aber irgendwie bist du dort gelandet.

Die eigentliche Diskussion, die wirklich zählt, ist die Struktur von project.json und wie diese in .csproj zusammengeführt werden soll. Das zugrunde liegende Build-System ist weitgehend irrelevant, wenn Sie nur etwas Einfaches wollen, da Sie immer nur dotnet build .

Wie können wir also unterscheiden, was msbuild und was dotnet build jetzt macht? Was sind die Unterschiede in ihrer Funktionsweise? Das fehlt meiner Meinung nach in dieser Diskussion. Jeder weiß es wahrscheinlich schon, aber ich denke, es könnte vielleicht etwas Klarheit schaffen, wenn man es auf den Tisch legt.

@khellang Ich mag die Art und Weise, wie Sie es ausgedrückt haben, aber von dort aus kann ich konfigurieren, was dotnet test tut. Ich kann einen anderen Test-Runner als den von xunit in die project.json einfügen, und dotnet test ruft diesen Test-Runner auf.

Aber nach allem, was ich über die bevorstehenden Änderungen gehört habe, wird es mit dotnet build keine ähnliche Funktion geben. Es wird immer MSBuild verwenden, um seine Builds auszuführen. Ist dieses Verständnis nicht richtig?

@neoKushan Ich @shedermans Argument

Zumindest wissen wir jetzt, was Sie _denken_, was Sie tun. Was Sie _tatsächlich_ tun, ist, falsche Darstellungen zu machen, Positionen zu vermischen, Dinge absichtlich falsch zu verstehen und im Allgemeinen ein bisschen ein Arsch zu sein. Ihr Ton ist kämpferisch und Sie sind absichtlich stumpf. So sehr, dass ich versuchen musste, die Dinge in einen Gedanken nach dem anderen zu zerlegen. Was Sie komischerweise als Positionswechsel missverstanden haben.

@neoKushan Zu diesem Zeitpunkt bin ich mir jedoch nicht einmal ganz sicher, was @shedermans Argument ist, da wir anscheinend irgendwie von einem schlechten XML zu einem schlechten MSBuild zu einem schlechten Dotnet-Build übergegangen sind.

XML ist schlecht. MSBuild ist schlecht. Wenn dotnet build nur MSBuild verwendet, ist es auch schlecht. Bitte versuchen Sie es und halten Sie Schritt. Es ist nicht so kompliziert. Wenn Sie nicht so mutwillig stumpf wären, hätten Sie es schon vor langer Zeit begriffen und konnten tatsächlich konstruktiven Beitrag leisten.

@neoKushan Das ist dein "Beweis"? Was, denken Sie daran, Sie fett geschrieben haben:

Ähm nein, das war meine persönliche Erfahrung, nicht der Beweis. Mein Beweis sind die 281 von 383 Befragten, die der Meinung waren, dass die Umstellung von .NET Core zurück auf MSBuild eine schlechte Idee ist. Und die 85 der Befragten, die glaubten, dass MSBuild grundlegend kaputt ist. DAS ist mein Beweis. Wo ist deine genau?

Wissen Sie, um Ihre Aussage zu untermauern, dass "... _jeder einzelne_ Visual Studio .net-Entwickler da draußen widersprechen müsste"? [Betonung hinzugefügt]

@neoKushan Die eigentliche Diskussion, die wirklich zählt, ist die Struktur von project.json und wie diese in .csproj zusammengeführt werden soll

Ich stimme dir tatsächlich zu. ABER der Hintergrund ist von entscheidender Bedeutung. Der von MS zum Ausdruck gebrachte Plan sieht vor, dass MSBuild das Zentrum des Build-Universums sein wird. Ich mag das nicht, aber lass uns weitermachen. Da stellt sich dann eine einfache Frage:

"Wird MSBuild für immer das wichtigste Buildsystem für das .NET Framework sein ?"

Wenn ja, brauchen wir nur einen msbuild Befehl und keinen dotnet build Befehl, er ist völlig überflüssig.

Wenn wir jedoch akzeptieren, dass MSBuild irgendwann nicht mehr das _One True Build System_ ist, befinden wir uns auf einem interessanteren Gebiet. Dann macht es Sinn, ein dotnet build . ABER es ist dann von entscheidender Bedeutung, dass wir diese Zukunft im Auge behalten

Was ich versucht habe (vielleicht schlecht) hervorzuheben, ist, dass eine (meiner Meinung nach) bessere Option darin besteht, eine klare Trennung zwischen den _Projektdefinitionsdateien_ und den _Builddefinitionsdateien_ zu halten. Dies würde uns besser für ein dotnet build einrichten, das mehrere Build-Engines unterstützen kann. Wenn wir stattdessen alles in csproj verschieben, sperren wir uns in eine MSBuild-Welt ein.

Und ja, ich verstehe, dass diese "nur ein echter Build"-Situation in DNX existierte. Aber ich habe das damals nicht abgefragt, weil mir der Build _gefiel_, den wir hatten. Ah, die Situationen, in die wir uns begeben, wenn wir Ungerechtigkeiten unbekümmert hinnehmen, _gefällt uns_ 😉.

Stellen Sie sich also eine Situation vor, in der dotnet build je nach Konfiguration eines von mehreren Build-Tools verwenden können. Genauso wie dotnet test einen von mehreren Testläufern verwenden kann. Nun, wie eine imaginäre Welt, jetzt gegeben , wie würden Sie csproj und project.json fusionieren? Das ist die Diskussion, die ich führen möchte.

@rhires Von einem sehr hohen Niveau dotnet build :

1. Sammelt die Projektdateien
2. Bestimmt, ob die Vorbedingungen für einen inkrementellen Build erfüllt sind
3. Liest die project.json
4. Bestimmt die Zielframeworks
5. Für jedes Projekt:
   
   
   
   1. Builds Abhängigkeiten
   
   
   2. Wenn inkrementell, prüft, ob ein Neuaufbau erforderlich ist
   
   
   3. Bestimmt Ausgabeverzeichnisse
   
   
   4. Sammelt die Quelldateien
   
   
   5. Bestimmt die Kompilierungsoptionen
   
   
   6. Führt vorkompilierte Skripte aus
   
   
   7. Führt den Compiler mit den Quelldateien und Optionen aus
   
   
   8. Führt die Postcompile-Skripte aus
   
   
   9. Berichtsausgabe
   
   

@shederman Danke! Was würde msbuild von diesem Punkt an hinzufügen/subtrahieren/ersetzen zu/von/in diesem Prozess?

Zumindest wissen wir jetzt, was Sie denken, was Sie tun. Was Sie tatsächlich tun, ist, Positionen falsch darzustellen, Positionen zu vermischen, Dinge absichtlich falsch zu verstehen und im Allgemeinen ein bisschen ein Arsch zu sein. Ihr Ton ist kämpferisch und Sie sind absichtlich stumpf. So sehr, dass ich versuchen musste, die Dinge in einen Gedanken nach dem anderen zu zerlegen. Was Sie komischerweise als Positionswechsel missverstanden haben.

Topf -> Wasserkocher

Sie haben Ihre Position so oft geändert, dass Sie nicht einmal mit sich selbst mithalten können, Sie haben buchstäblich über jeden einzelnen Aspekt der Build-Kette gestritten und gezeigt, dass Sie eindeutig nicht so gut verstehen, wie alles funktioniert zusammen, wie du _denkst_ du tust, aber _ich_ bin_ der Arsch, weil ich es wage, darauf hinzuweisen, wo deine Argumente scheitern. Ich warte immer noch darauf, dass Sie auf die Hälfte der oben angesprochenen Punkte antworten, aber Sie müssen nur einen anderen Aspekt des Build-Prozesses auswählen.

XML ist schlecht. MSBuild ist schlecht. Wenn dotnet build nur MSBuild verwendet, ist es auch schlecht.

Niemand anders als _you_ hat so etwas behauptet. Niemand. Es gibt nicht den geringsten Hinweis darauf, dass so etwas jemals passieren wird. Ich habe Ihnen wiederholt gesagt, dass dotnet build nicht _nur_ MSBuild anrufen wird, ich habe Ihnen gesagt, dass dotnet build und msbuild nicht völlig gleichbedeutend sind mit sich gegenseitig und dass dotnet build verdammt viel mehr macht, als nur den Compiler aufzurufen. Ich habe Sie sogar mit dem verdammten Quellcode verlinkt und andere sind gekommen und haben dasselbe gesagt, aber Sie bestehen immer noch darauf, dass dies in irgendeiner Weise vor sich geht?

Bitte versuchen Sie es und halten Sie Schritt.

Wie wäre es, _du_ mitzuhalten? Bitte zeigen Sie uns, woher Sie diese Idee haben, dass dotnet build nur msbuild anrufen wird. Wer hat dir das gesagt? Wo hast du es gelesen?

Mein Beweis sind die 281 von 383 Befragten, die der Meinung waren, dass die Umstellung von .NET Core zurück auf MSBuild eine schlechte Idee ist. Und die 85 der Befragten, die glaubten, dass MSBuild grundlegend kaputt ist. DAS ist mein Beweis. Wo ist deine genau?

Und Sie haben 10 % von diesen Zahlen abgezogen, oder? Denken Sie daran, dies ist Ihr Anspruch:

Ich würde sagen, dass die Leistungsfähigkeit und Komplexität von MSBuild für etwa 10 % der Builds geeignet ist.

Später hast du dann gesagt:

Komisch, ich habe Beweise gesammelt, die etwas anderes sagen.

Wo ist dieser Beweis? Ich würde gerne wissen, wie Sie diese Zahl aus Ihren "Beweisen" gezogen haben.

Wissen Sie, um Ihre Aussage zu untermauern, dass "... jeder einzelne Visual Studio .net-Entwickler da draußen widersprechen müsste"?

Einfach: https://msdn.microsoft.com/en-us/library/ms171468.aspx

Visual Studio hostet MSBuild, um verwaltete Projekte zu laden und zu erstellen.

Wenn Sie Visual Studio zum Erstellen Ihrer Projekte verwenden, verwenden Sie MSBuild. Auch wenn man heute mit .net Core arbeitet, sogar mit RC1 VS verwendet MSbuild unter der Haube. Sie mögen MSbuild vielleicht nicht, aber wie gesagt, fast jeder VS-Entwickler verwendet es, ob er es merkt oder nicht.

Der von MS zum Ausdruck gebrachte Plan sieht vor, dass MSBuild das Zentrum des Build-Universums sein wird.

Ich bin damit nicht einverstanden. Sie haben nie gesagt, dass es das Zentrum sein würde, sie haben nur gesagt, dass einige Teile von project.json am Ende wieder in .csproj zurückkehren würden - darüber hinaus haben sie kein Wort darüber gesagt, inwieweit dies die dotnet build ändert

"Wird MSBuild für immer das wichtigste Build-System für das .NET Framework sein?"

Wenn ja, brauchen wir nur einen msbuild-Befehl, und wir brauchen keinen dotnet build-Befehl, er ist völlig überflüssig.

Wie schon oft gesagt, sind dotnet build und msbuild zwei völlig unterschiedliche Dinge. dotnet build ruft mehr als nur die Compiler-Toolchain auf. Der Zweck von dotnet build besteht darin, den Build-Prozess für die Menschen einfach zu halten. Wiedersehen:

dotnet new
dotnet restore
dotnet build

Auch wenn msbuild eine Kernkomponente der dotnet-CLI wird, ändert das nichts an der Tatsache, dass dotnet build der saubere, einfache Wrapper um ein ziemlich komplexes System ist (und immer sein wird). Verdammt, der halbe Grund, warum die dotnet-CLI (und DNX davor) existiert, besteht darin, der Befehlszeilenargument-Hölle zu entkommen, die MSBuild letztendlich ist. Ihr Argument ist ein bisschen so, als ob Sie sagen würden: "Warum brauchen wir einen npm install Befehl, wenn ich das Paket nur curl ?". Klar, man kann das alles manuell machen, wenn man es wirklich will, aber man hat fast nichts davon. Was also, wenn dotnet build msbuild unter der Haube verwendet? Sie werden es mit ziemlicher Sicherheit nie sehen oder wissen müssen.

Sie können Ihre alte Erfahrung nicht mit MSBuild vergleichen, sie ist völlig anders. Wir alle sind (scheinbar) von diesem gebrannt worden, weil wir es gewohnt sind, VS zu öffnen, ein Projekt zu erstellen und es einfach bauen zu lassen, aber dann, wenn Sie dasselbe Projekt auf einem Build-Server erstellen lassen, beschwert es sich plötzlich über Scheiße das sollte _einfach funktionieren_. Wahrscheinlich eines der besten Dinge, die Microsoft mit TFS 2015 gemacht hat, war die Erstellung einer Build-Definition, die sich an _Visual Studio_ und nicht an _MSBuild_ anlehnt, weil Sie wieder "nur arbeiten". Genau das ist diese Build-Toolchain - dotnet build soll nicht Ihr gesamtes Build-System ersetzen, es geht nur darum, Ihre Projekte zu erstellen, auch wenn es MSBuild unter der Haube verwendet. Wenn Sie etwas wie TeamCity oder Jenkins verwenden möchten, müssen Sie ihnen nur dotnet build sagen, dass sie anrufen sollen und dotnet erledigt den Rest. _Wie_ das geht, interessiert Sie nicht.

Das einzige - und ich meine das ganz, das einzige, was sich für Sie tatsächlich ändert, ist die Datei project.json/csproj. Das ist es_. Deshalb ist dieses ganze Streiten darüber, was dotnet build wirklich tut und wofür MSBuild gut und schlecht ist, absolut _sinnlos_.

@neoKushan hör einfach auf ...

@neoKushan hör einfach auf...

Ein Teil von mir stellt sich gerne vor, dass das ASP.NET-Team den Standup absichtlich absagt, weil ihnen die Show gefallen hat, und die Bereitstellung von Antworten würde alles zu einem Ende bringen. :Lächeln:

Von meiner (jetzt entschieden) agnostischen Position aus scheinen beide Seiten seit einiger Zeit bewusst stumpf gegenüber den Punkten des anderen zu sein. Es gelingt Ihnen, mein mentales Bild von der .NET Core-Community als nicht konstruktiv und schlimmer zu definieren. Sprechen Sie über Wahrnehmung...

Die meisten Dinge, die nicht von NuGet stammen, werden mit csproj zusammengeführt. Was passiert mit NuGet-Sachen, wenn es kein project.json (nuget.json?) gibt?

Bieten Sie Benutzern eine Möglichkeit, ihre Abhängigkeiten nach Belieben zu verwalten, und stellen Sie möglicherweise standardmäßig ein dotnet nuget bereit, da NuGet in der .net-Community gut etabliert ist.

aber koppeln Sie nicht all das Dotnet-Kernmaterial hart an diese einzige Möglichkeit, Abhängigkeiten zu verwalten ( dotnet restore sollte nicht gleich dotnet nuget restore ), für viele Leute ist nuget nur ein Paket-Repository, aber kein Abhängigkeitsmanager haben die Leute andere Wahlmöglichkeiten, die sie für den Anwendungsfall "Abhängigkeitsmanager" produktiver / geeigneter finden könnten.

Werden wir IntelliSense für das Abhängigkeitsmanagement beibehalten? Dies ist im Grunde eine der besten Demofunktionen, die wir für project.json haben.

Sie können die Logik umfunktionieren, ich sehe das nicht als große Sache an, zum Beispiel gehe ich auf nuget.org und suche nach einem Paket und kopiere die ID aus der URL, es ist effizient.

Vielleicht möchten Sie auch eine Shell-Vervollständigung anbieten, die Ihnen viel Bewunderung von Leuten einbringt, die bash oder zsh :

dotnet nuget add S[tab] bietet eine Abschlussliste für Projektkennungen, die mit S

Intellisense in msbuild zu haben *proj-Dateien sollten auch machbar sein, wenn Sie dort ein <NuGet> Tag backen möchten, aber genauso, nicht hart an das gesamte Ökosystem koppeln, dh <Package>NuGetPackageId</Package> sollte nicht t gleich <NuGet>NuGetPackageId</NuGet> ODER es sollte einen sehr einfachen (und extrem gut dokumentierten und unterstützten) Weg geben, dies zu überschreiben.

Paket Visual Studio-Plugin hat Autovervollständigung auf nuget, es funktioniert, ist aber sowieso etwas langsam, weil ich annehme, dass es einige Zeit dauert, bis die Antwort von nuget.org zurückgegeben wird.

Behalten wir das JSON-Format für die Abhängigkeitsverwaltung bei? XML ist für solche Dinge schrecklich (siehe Maven). JSON ist zweifellos einfacher, diese Abhängigkeiten darzustellen.

Wenn Sie nach Ideen für das Format suchen, können Sie sich paket.dependencies ansehen, ansonsten denke ich, dass es nicht viel ausmacht, das Bearbeiten von project.json war ungefähr so ​​​​gut wie das Bearbeiten von packages.config in Bezug auf den Umgang mit NuGet, tun Sie alles, was für Benutzer geeignet ist, die NuGet als Paketabhängigkeitsmanager wählen (was nicht 100% der Benutzer ist und nicht muss)

Als Randnotiz, wenn Sie immer noch eine lock Datei benötigen, könnten Sie sie für den Benutzer lesbar machen, etwas, das im Repository überprüft wird und leicht zu unterscheiden ist?

@rhires Von diesem Punkt an, was würde msbuild in diesem Prozess hinzufügen/subtrahieren/ersetzen?

Nun, das hängt davon ab, wie sie es integrieren. Wenn sie eine "harte Sperre" durchführen und msbuild tief in dotnet build integrieren, was die öffentlichen Informationen als ihren bevorzugten Ansatz zu bezeichnen scheinen, würde sie vollständig durch msbuild ersetzt.

Wenn sie jedoch dotnet build konfigurierbar machen, gehe ich davon aus, dass es in etwa so funktioniert:

1. Sammelt die Projektdateien
2. Liest die project.json
3. Bestimmt die Zielframeworks
4. Bestimmen Sie das zu verwendende Build-Tool
5. Rufen Sie das Build-Tool auf
6. Berichtsausgabe

@neoKushan Deshalb ist all das Streiten darüber, was Dotnet Build wirklich macht und wofür MSBuild gut und schlecht ist, absolut sinnlos.

👍

Was ich _diskutieren_ möchte, ist, wie project.json und csproj in einer Welt aussehen sollten, in der dotnet build als eines von _vielen möglichen Build-Tools_ an MSBuild ausgeben kann. Ist das in Ordnung? Können wir darüber sprechen, was in project.json und was in csproj enthalten wäre, angesichts dessen?

Denn wenn wir das _können_, kann dieser Thread meiner Meinung nach tatsächlich konstruktiv werden.

@jmm Es

Das tut mir leid. Wenn Sie jedoch die Zeit haben, würde ich vorschlagen, einige der Chat-Archive einiger anderer großer Open-Source-Projekte durchzulesen.

Argumente sind eigentlich ein Zeichen für eine gesunde Gemeinschaft, genau wie im Leben. Wenn jeder blindlings einer Reihe von Anführern folgt, dann läuft es normalerweise nicht so gut. Entscheidungen, Beweise und Entscheidungsfindung sollten verhörbar sein.

@shederman Im Interesse einer produktiven Diskussion möchte ich auch einen

Ich denke, dass die Kerndiskussion hier das Layout und das Format der "neuen" .csproj und was mit der project.json passiert (oder genauer gesagt der "Projekt" -Struktur als Ganzes) sein sollte. Ich glaube nicht, dass das Build-System, ob es msbuild ist oder nicht, wie Dotnet-Build funktioniert usw., in den Bereich _dieses_ Problems fällt. Das soll nicht heißen, dass Diskussionen darüber unerwünscht oder ungültig sind, nur dass sie nicht in dieses _spezifische_ Thema gehören, sondern vielmehr separate Themen sein sollten. Wie jeder erfahrene Entwickler bestätigen kann, ist es sehr frustrierend, wenn ein Fehlerbericht mehrere separate Fehler enthält und normalerweise das erste, was Sie tun würden, sie in mehrere Probleme aufzuteilen, um sie zu verfolgen - ich denke, das ist wirklich das, was hier fehlt.

Aus meiner eigenen _persönlichen_ Perspektive ist es mir egal, was das Build-System ist oder wie es funktioniert. Das soll nicht ignorant oder abweisend für diejenigen klingen, die dies tun, ich meine, aus Entwicklersicht möchte ich nur wissen, dass "dotnet build" meine Assembly ausspuckt, solange die Projektstruktur stimmt - also soweit Was mich betrifft, dotnet build -> Projekt ->-> Montage. Das einzige, was mir wirklich wichtig ist und was der Umfang dieser Diskussion sein sollte (und ich denke, wir sind uns hier endlich einig), ist, wie dieses Projekt aussieht und was es für meinen täglichen Arbeitsablauf bedeutet.

Ich möchte mich nicht mit der Merge-Hölle befassen, nur weil ich eine .cs-Datei hinzugefügt habe, noch möchte ich mich mit einer tausendzeiligen XML-Datei befassen, nur weil ein System, das mir egal ist, davon abhängt - ich tue es nicht Ich glaube nicht, dass das irgendjemand von uns tut, und das ist seit Jahren ein Schreckgespenst der VS-Entwicklung. Wir hatten einen Hoffnungsschimmer mit dem project.json-Format, wie es heute ist, weil es _so viel besser_ war als das, was zuvor kam. Ich verstehe also völlig und verstehe, warum die Gemüter so schnell ausgefranst sind, wenn der bloße Hinweis darauf, dass wir zurückkehren würden die "schlechte alte Zeit", aber gleichzeitig ist es erwähnenswert, dass wir uns nichts vormachen sollten - project.json ist heute keineswegs _perfekt_, es hat seine eigenen Probleme und auch wenn sie im Vergleich zu den geringfügig sein können Fragen des "alten" csproj, lohnt es sich, objektiv zu bleiben und zu diskutieren, wo etwas verbessert werden könnte und was besser sein könnte.

Es gibt definitiv eine _das Beste aus beiden Welten_ Möglichkeit.

Ich denke, dass die Kerndiskussion hier das Layout und das Format der "neuen" .csproj und was mit der project.json passiert (oder genauer gesagt der "Projekt" -Struktur als Ganzes) sein sollte.

Weißt du, es wurde in diesem Thread ein paar Mal erwähnt, aber ich dachte, ich würde es noch einmal erwähnen, nur um mein eigenes "persönliches Aha" heute Morgen zu teilen, aber es gibt noch ganz andere Bemühungen mit dem Roslyn-basierten Projektsystem -- oder genauer gesagt aus der Readme-Datei des Central Project System (CPS) . Beim Durchsuchen der Dokumentation scheint es eher ein Projektdefinitionsaufwand als ein Prozess zu sein. Vielleicht wird hier die ganze Magie zwischen .json und .csproj konsolidiert? Und dann wird MSBuild als Prozessendpunkt degradiert? Wäre _das_ nicht schön. :Lächeln:

Wie auch immer, ich habe dieses Repo gestartet/beobachtet, um Updates darüber zu erhalten, was dort passiert. :+1:

(Ich frage mich auch halbwegs, ob wir diese Diskussion dort auf ein neues Thema verschieben sollten.)

@neoKushan Auf

Was mich beunruhigt, sind Argumente wie "msbuild ist kampferprobt", normales msbuild ist es aber das aktuelle xplat scheint es nicht zu sein. Wenn wir uns die Probleme im zugehörigen Github-Repository ansehen, ist es noch nicht ganz da. Darüber hinaus sagte das msbuild-Team bereits, dass die Unterstützung eines neuen/verbesserten Serialisierungsformats kein Ziel von msbuild sein wird, sondern eher für ein neues Build-System (was in absehbarer Zeit nicht passieren wird).

Ich mache mir auch Sorgen, wenn Leute davon ausgehen, dass wir nur das Entfernen von Abhängigkeiten hinzufügen. Vielleicht tun sie das, weil sie nur "Hallo Welten"-Apps machen. Aber andere Optionen wie buildOptions und Überschreibungen von Moniker sind extrem mächtig und praktisch. Ganz zu schweigen davon, dass die aktuelle Erfahrung mit json-Schema-basierten Editoren einfach großartig ist.

Ein Weg könnte darin bestehen, eine msbuild-Aufgabe zu haben, die als Alternative project.json lädt. Lassen Sie den Entwickler dann in den Projekteinstellungen auswählen, ob er project.json aktivieren möchte, wodurch diese Aufgabe zum csproj hinzugefügt wird.

@Mike-EEE Ja, es gibt Hoffnung :)

Ich bin mir ziemlich sicher, dass die aktuelle Tendenz darin besteht, aus project.json nuget.json zu machen – was hoffentlich das Abhängigkeitsproblem lösen und den Großteil der vorhandenen project.json-Funktionalität intakt lassen würde.

Das einzige, was ich nicht herausfinden kann, ist, wie sich dies auf das Multi-Targeting auswirkt. Müssen csproj und nuget.json sich dessen bewusst sein und verstehen, worauf sie jeweils abzielen? Haben wir am Ende ein csproj für jedes Ziel (igitt!), oder können sie .csproj genug erweitern, um dies zu berücksichtigen?

project.json wird zu nuget.json

Nur neugierig hier... wo findet _diese_ Unterhaltung statt? Ich bin schon früher in das Nuget-Team gekommen, weil ich mich mit einem bestimmten Format festgefahren habe. In Bezug auf project.json gaben sie an, dass dies ein Problem mit Visual Studio-Tools sei und etwas, das sie nicht angehen konnten. Jetzt scheint sich die Dynamik geändert zu haben und mehr von der gleichen Art von Problem kopiert / eingefügt zu haben. :stuck_out_tongue:

Um meine Bedenken zu verdeutlichen, mischen wir jetzt JSON und XML zusammen, was zumindest zu Ineffizienz führt.

Nur neugierig hier... wo findet dieses Gespräch statt?

Nun, es wurde ursprünglich hier angegeben: https://blogs.msdn.microsoft.com/webdev/2016/05/11/notes-from-the-asp-net-community-standup-may-10-2016/

Es ist möglich, dass die Datei project.json erhalten bleibt und alle Paketverweise für NuGet enthält und in nuget.json umbenannt wird.

Und ich denke, darum geht es in der Diskussion hier wirklich, wie viel nimmt man aus project.json heraus und steckt es in ein .csproj? In meinen Projekten waren die meisten project.json Paketreferenzen, insbesondere wenn ich auf mehrere Frameworks abziele. Das Obige legt nahe, dass all dies bestehen bleibt und nur die "anderen" Bits herausgenommen werden. Nach meiner (wieder: persönlichen) Erfahrung ändern sich diese "anderen" Bits während der Lebensdauer eines Projekts nicht wirklich viel, also selbst wenn es in XML ist, ist es nicht viel XML und es sollte ziemlich statisch sein ... .

Ich stimme zu, dass das Mischen und Abgleichen von XML und JSON für verschiedene Konfigurationen ein bisschen unangenehm ist, aber andererseits bin ich etwas voreingenommen gegen JSON, da ich kein großer Fan davon bin, wie es verwendet wird. Das ist aber definitiv eine persönliche Präferenz.

Nun, es war ursprünglich hier angegeben...

Ach ja... natürlich! OK. Nur um sicher zu gehen. Hoffentlich ist morgen der Tag, an dem wir endlich Klarheit (zum Guten oder zum Schlechten!) haben.

Ich stimme zu, dass das Mischen und Abgleichen von XML und JSON für verschiedene Konfigurationen ein bisschen stinkt

Ich bin wirklich froh, dass ich nicht der einzige bin, der das so sieht und fühlt. :) Es schien eine Weile einsam dort zu sein, als ich zum ersten Mal mit dem Kummer kämpfte, zu sehen, wie sich .JSON in Projekte einschleicht. Völlig sinnvoll aus einem Web-Appdev-Hintergrund, aber das native Appdev ist nicht beliebt und umgekehrt, wenn es um XML geht.

Haha... Apropos, das Schreiben des oben Gesagten hat mich dazu gebracht, die alten Archive herauszuziehen. Hier bin ich im Jahr 2014 und plädiere für (ja, du hast es erraten!) Xaml statt JSON hahaha oh schau, wie jung und völlig naiv ich war! So süß und unscheinbar! Junge, hatte ich die Welt zu lernen. :stuck_out_tongue: Aber ich muss sagen, dass es einige Fortschritte gegeben hat. Wir haben die .ini, die für die Webserver-Konfiguration verwendet wird , immerhin entfernt. :Lächeln:

@neoKushan Es gibt definitiv das Beste aus beiden Welten.

👯 👯 👯

@neoKushan Ich bin mir ziemlich sicher, dass die aktuelle Tendenz darin besteht, aus project.json nuget.json zu machen ... Das einzige, was ich nicht herausfinden kann, ist, wie sich dies auf Multitargeting auswirkt, müssten csproj und nuget.json sich dessen bewusst sein verstehen und verstehen, worauf sie jeweils abzielen?

Wenn ich das Schema project.json als Ausgangspunkt verwende, sollten aus meiner Sicht die folgenden Elemente wahrscheinlich _nicht_ in der Build-Definitionsdatei enthalten sein:

• Liste der Quelldateien
• Projektabhängigkeiten
• Zielrahmen
• Projektbefehle (z. B. Web, Test usw.)
• Webroot
• Metadaten
• Sprachversion

Folgendes sollte meiner Meinung nach nicht in der Build-Definitionsdatei stehen, aber ich wäre _meh_ darüber, wenn sie es wären:

• Konfigurationsdefinitionen
• Skripte, vor und nach

Folgendes _sollte_ wahrscheinlich in der Build-Definitionsdatei stehen:

• Zusammenstellungsoptionen (ohne Sprachversion)

Das oben Gesagte soll nur eine Diskussion provozieren. Gerne diskutieren Sie einzelne Punkte. Schlagen Sie vor, den Namen und das Format der Dateien zu ignorieren.

@shederman Müssen wir klären, was Sie mit "Build-Definition" meinen? Vielleicht ist meine Terminologie nicht gültig, aber ich würde die aktuelle project.json nicht als _Build-Definitionsdatei, sondern als _Projektdefinitionsdatei bezeichnen (und das Gleiche würde für die neue csproj-Datei gelten). Möglicherweise Semantik, aber für mich legt eine Build-Definition nahe, dass sie definiert, _wie Dinge gebaut werden_, während eine Projektdefinition definiert, was ein Projekt ausmacht und Build-Schritte etwas anderem überlässt.

_Das ist mein Projekt, es besteht aus diesen Elementen und hat diese Abhängigkeiten. Wie Sie es bauen, geht mich nichts an._

Ein Großteil des Projekts kann nur durch Konventionen bestimmt werden, beispielsweise wie der Assemblyname aus dem Ordner der obersten Ebene stammt. Wenn man dieser Denkweise folgt, hätte _nuget.json_ einfach alles, was mit Nuget zu tun hat - also würden Pakete/Abhängigkeiten dort reinkommen und ich denke, wir sind alle damit zufrieden.

Worauf ich mich nicht ganz entscheiden kann, sind Zielframeworks. Wenn Nuget.json nur mit der Auflösung von Abhängigkeiten befasst ist, dann, obwohl es beim Zielen auf verschiedene Frameworks eine gewisse Trennung für Referenzen geben könnte, bin ich mir nicht ganz sicher, ob es diejenige sein sollte, die entscheiden sollte, auf welche Frameworks tatsächlich abgezielt wird, das scheint mehr für das _Projekt zu sein definition_ (Was auch immer das am Ende ist).

Andererseits gibt es bei Nuget mehr als nur Paketreferenzen, es enthält auch das Paket _definition_ und die Version für den Fall, dass Ihre Bibliothek zu einem Nuget-Paket _wird_. Es scheint, als würde nuget.json dann mindestens zwei verschiedene Dinge tun und das fängt an, ein bisschen zu riechen. Vielleicht (hier nur spucken) würde das csproj die Details des Pakets, der Zielframeworks usw. definieren und jedes Zielframework könnte auf eine .json-Datei verweisen, die im Grunde die Nuget-Pakete sind. Mit anderen Worten, statt einer nuget.json hätten Sie für jedes Framework eine separate .json-Datei. Das mag eine schreckliche Idee sein, ich habe sie nicht besonders durchdacht.

https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/ :

Wir hatten zwei Möglichkeiten. Eine bestand darin, alle .NET-Projekte zu verschieben, um project.json zu verwenden. Dies würde erfordern, dass wir Tooling-Arbeiten durchführen, die alle Projekttypen in Visual Studio, Xamarin und unseren Partnern wie Unity berühren. Wir müssten project.json erweitern, um alle von diesen Projekttypen benötigten Build-Szenarien zu unterstützen und eine Migrationsgeschichte bereitzustellen. Eine andere Möglichkeit bestand darin, Brücken zu erstellen, damit ein XPROJ-Projekt auf ein CSPROJ-Projekt und ein CSPROJ-Projekt auf ein XProj-Projekt in Visual Studio und Xamarin Studio verweisen kann. Die Brücke birgt auch Herausforderungen, zum Beispiel wenn ein Kunde ein Projekt erstellt, müsste er sich jetzt für eine .xproj oder eine .csproj entscheiden, was nur mehr Auswahl und Komplexität hinzufügt.

Und

Nachdem wir uns unsere Auswahl angesehen hatten, war klar, dass es einfacher wäre, .NET Core-Projekte in .csproj/MSBuild zu verschieben, sodass alle .NET-Projekte dieselben Tools und dasselbe Buildsystem verwenden.

Wir planen, .csproj zu erweitern, um die fehlende Funktionalität zu unterstützen:

• Keine Auflistung von Dateien im Projektsystem
• CLI-Tool zum Ausführen von Operationen an der Projektdatei. In den meisten Szenarien würden Sie die Datei nicht bearbeiten
• Pakete direkt aus dem Projekt erstellen
• Multi-Targeting

Und da alle .NET die gleichen Tools verwenden, können wir uns dann mit der Verbesserung von MSBuild befassen. Wir werden Feedback von Kunden und der Community zur Unterstützung von JSON anstelle von XML einholen, damit unsere Tools keine übermäßig ausführlichen Dateien generieren und mehr. Und da alles die gleichen Tools verwendet, könnten diese Verbesserungen bei allen .NET-Projekten funktionieren.

https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/#comment -71485:

Vorausgesetzt, dass .csproj immer noch C#-Projekt bedeutet, wird es natürlich andere Ziele für Nicht-C#-Projekte geben, richtig? [Ben]

Ja. [Scott H]

Ich habe ein bisschen Angst, dass .net mit einem komplexen Legacy-JustForTooling-Build-System als msbuild stecken bleibt. Vielleicht sollten wir damit beginnen, um dotNetCore zum Laufen zu bringen, und dann ein neues modernes Build-System planen?
Um jedem Körper Hoffnung zu geben und Dinge ohne Eile zu tun, .netcore zu versenden.

Ich muss msbuild-Dateien nicht oft bearbeiten, aber wenn ich es brauche, ist es sehr schwierig, der deklarative Ansatz lässt Sie sich im Fluss verlieren, ich bringe mein Beispiel, niemand scheint in der Lage zu sein, ein einfaches Problem wie dieses zu lösen https://github .com/madskristensen/BundlerMinifier/issues/89
Wenn nach 6 Monaten niemand eine Aufgabe (zwei verschiedene Aufgaben, die jede nicht kennen) nacheinander ausführen konnte, ohne schmutzige Hackings oder additiv, gibt es vielleicht da drüben etwas zu reparieren.

Danke

CLI-Tool zum Ausführen von Operationen an der Projektdatei. In den meisten Szenarien würden Sie die Datei nicht bearbeiten

:-1:

Ich bin ganz dafür, dass CLI-Tools Ihnen bei Ihrer Arbeit helfen, aber wenn ich ein CLI-Tool verwenden muss, um Referenzen und Pakete zu verwalten, werde ich sauer sein. Install-package ist großartig, aber in der Lage zu sein, einfach die Hälfte des Paketnamens einzugeben und eine Liste von Möglichkeiten mit all ihren Versionen anzuzeigen, war erstaunlich.

cli-Tools eignen sich hervorragend für die Automatisierung, sind jedoch eine schlechte Möglichkeit, Aufgaben auszuführen, mit Ausnahme von grundlegenden Aufgaben wie npm install oder dotnet restore . Wenn wir Dinge wie dotnet buildoptions define add --framework net451 SOME_DEFINE lernen müssen, ist es definitiv scheiße. Dies ist ein großer Verlust.

Eine gute Entwicklungsgeschichte ist:

• Leicht bearbeitbare Projekt- und Build-Dateien
• Konfigurierbares Build-System
• Einfache, gut gestaltete und vollständige CLI-Tools
• Tolle GUI, IDE-Tools

Einen von denen arm zu machen (was vorher eigentlich großartig war), um einen anderen akzeptabel zu machen, ist einfach dumm.

Das Argument Einheit und xamarin ist eigentlich ziemlich schlecht. Ich glaube nicht, dass sie so bald zum .net-Kern wechseln werden, und aus Bequemlichkeitsgründen rückwärts zu gehen, ist einfach lahm, wenn man für die Zukunft von .net entwirft.

Und da alle .NET die gleichen Tools verwenden, können wir uns dann mit der Verbesserung von MSBuild befassen

Kein MSBuild wird verbessert, bevor wir dazu gezwungen werden...

Dieser Artikel ist wirklich nicht der Blog-Beitrag, auf den wir gewartet haben, und er bestätigt, dass .net Core dort fehlgeleitet wird.

cli-Tools eignen sich hervorragend für die Automatisierung, sind jedoch eine schlechte Möglichkeit, Aufgaben auszuführen, mit Ausnahme von grundlegenden Aufgaben wie npm install oder dotnet restore.

Auch hier habe ich das Gefühl, dass dieses Thema ein Zusammenprall von Kulturen/Präferenzen/Philosophie ist. Irgendwann wurde CLI zu einer guten Idee, um die GUI zu ersetzen, wenn Sie wirklich beides benötigen, da Sie feststellen werden, dass Entwickler (wieder einmal) ihre bevorzugten Ansätze haben. In diesem Bereich sind sicherlich einige Innovationen erforderlich, da es anscheinend ständig ein Problem ist: CLI wird erstellt, GUI jedoch nicht und umgekehrt.

Für mich scheint eine Art Framework erforderlich zu sein, um die API zu erstellen, und dann werden die CLI- und GUI-Versionen automatisch für Sie erstellt.

Wir könnten es... CLIGUIAPI nennen! :+1: :+1: :+1: #problemlos

Dieses Thema ist ein Zusammenprall von Kulturen/Präferenzen/Philosophie

Definitiv und das ist eine, die Sie nicht lösen können, außer wenn Sie jeden Ansatz mit dem bestmöglichen Ansatz angehen. node.js und ich bin nicht der größte Fan dieses Stacks, das mit dem großartigen CLI-Tool npm und package.json großartige Arbeit geleistet hat. Der Gui-Teil wird von verschiedenen Anbietern angesprochen (Webstorm, vs Code, Visual Studio). Ausgefallene Bausysteme wie gulp sind hundertprozentig optional.

vielleicht bin ich in dieser Hinsicht eine Minderheit und vielleicht auch nicht, aber obwohl ich project.json mag, werden die Gründe hier erklärt https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project -json/ macht für mich sehr viel Sinn. Ich bin ziemlich zuversichtlich, dass wir am Ende eine gute Erfahrung machen werden, also mache ich mir darüber wirklich keine Sorgen und es schmälert in keiner Weise meine Begeisterung für diese neuen Frameworks. Die Leute scheinen sehr schnell aus den Pitchgabeln zu kommen und tun so, als ob die Welt untergeht, bevor sie überhaupt sehen, was das letzte Erlebnis sein wird

Ich habe vor einiger Zeit aufgehört zu lesen, aber ich werde dieses Thema schließen, sobald wir eine endgültige Antwort zu project.json .

Wie wäre es, sowohl project.json als auch .csproj beizubehalten, wobei .csproj durch den Befehl dotnet restore generiert und standardmäßig nicht in der Versionskontrolle synchronisiert wird? Der Unterschied besteht darin, dass dotnet restore „project.lock.json“ generiert (und andere Dinge tut), sondern die Datei „.csproj“ generiert (oder aktualisiert). Sogar "project.lock.json" und ".csproj" können bleiben, da beide automatisch generiert werden. Flags können in dotnet restore zum Generieren von .csproj verwendet werden. In der Ankündigung sagt Microsoft bereits: „CLI-Tool zum Ausführen von Operationen an der Projektdatei, für die meisten Szenarien würden Sie die Datei nicht bearbeiten“. IMHO, dotnet restore ist am besten geeignet, um DIESES CLI-Tool zu sein, das project.json als Eingabe verwendet. Die Vorteile werden sein-

• Beide Formate von project.json und .csproj können unverändert bleiben. Das bedeutet, dass neu generierte .csproj-Dateien mit früheren Versionen von Visual Studio und anderen Tools kompatibel sind. dotnet restore kann eine explizite "include"-Liste von Projektdateien in die .csproj-Datei einfügen.
• Da .csproj automatisch generiert wird und nicht der Versionskontrolle unterliegt, müssen sich Entwickler nicht mit der manuellen Bearbeitung und Zusammenführung von .csproj befassen.

Yeah Nein.

Schließen. Es wurde alles gesagt, was gesagt werden konnte.

Wenn Sie herausfinden möchten, wie es gemacht werden sollte, und in dem Designteam sein möchten, das darüber spricht ... bitte tun Sie es .

Ansonsten ist es verschwendeter Platz und vor allem... es füllt Posteingänge.

@MaximRouiller hoffe, Sie sammeln die Kommentare, die sich trotz des Lärms auf die Beantwortung Ihrer ersten Fragen konzentrieren.

Gestern gepostet:

https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/

@neoKushan Müssen wir klären, was Sie mit "Build-Definition" meinen? Vielleicht ist meine Terminologie falsch, aber ich würde die aktuelle project.json nicht als Build-Definitionsdatei bezeichnen, sondern eher als Projektdefinitionsdatei (und das Gleiche würde für die neue csproj-Datei gelten). Möglicherweise Semantik, aber für mich legt eine Build-Definition nahe, dass sie definiert, wie Dinge gebaut werden, während eine Projektdefinition definiert, was ein Projekt ausmacht, und Build-Schritte etwas anderem überlässt.

Ziemlich genau in meinem Denken. Die Projektdefinition wäre eine rein deklarative Beschreibung des Projekts. Metadaten, Versionen, Dateispezifikationen usw. Build-Definition sind die Schritte, die ausgeführt werden, um das Projekt in ausführbaren Code zu konvertieren. Build-Definition würde mit ziemlicher Sicherheit etwas ziemlich Reichhaltiges brauchen, um sie auszudrücken, mein Favorit ist Code.

Aber es scheint alles strittig :

Insgesamt war die ganze Sache mit csproj -> project.json -> csproj eine Reihe von schlechten Entscheidungen, die MS bei der .NET-Einführung IMHO heimsuchen werden. Der Trend, dass Entwickler .NET zugunsten grünerer Weiden aufgeben, wird unvermindert anhalten.

So traurig.

@shederman Es gibt keinen Zusammenhang zwischen einem sinkenden Tiobe-Index für C# und der Entscheidung, zurück zu csproj zu wechseln. Auch ein sinkender Tiobe-Index ist kein Hinweis auf die nachlassende Gesundheit des C#-Ökosystems. Immer mehr Sprachen, die auf den Markt kommen, machen es für eine Sprache schwierig, einen großen Marktanteil zu halten.

Die Auswirkungen insgesamt sind mir nicht klar, aber ich möchte darauf hinweisen, dass hier eine getrennte Bewertung vorgenommen werden sollte. Wenn csproj bedeutet, nur weil ich eine Datei hinzufüge, meine Teamkollegen sind besorgt über andere Auswirkungen im Zusammenhang mit dem Build-Prozess, dann verpassen wir das Boot.

csproj ist etwas, das ich toleriere, nicht bevorzuge.

@jerometerry Ich habe nicht gesagt, dass dies an sich zu einem Rückgang führen wird. Viele der innovativen Änderungen in .NET Core zielten jedoch darauf ab, den Rückgang und die Verluste für AWS aufzuhalten. Diese Änderungen werden langsam nach und nach weggemeißelt, und daher wird es immer unwahrscheinlicher, dass .NET Core Entwickler auf die Plattform locken wird.

Auch die schlechte Entscheidungsfindung, die bis heute auf die Entscheidung, project.json einzuführen, zurückzuführen ist, verheißt nichts Gutes.

Wenn MS entschlossen sind, sich auf die Vergangenheit zu konzentrieren, sollten sie sich nicht wundern, wenn sie in Zukunft verlieren. Das Denken, das Sie in ein Problem gebracht hat, wird Sie wahrscheinlich nicht herausbekommen.

Immer mehr Sprachen, die auf den Markt kommen, machen es für eine Sprache schwierig, einen großen Marktanteil zu halten.

Stimmt, aber meiner Erfahrung nach wird in .NET mehr Schaden als nötig durch Friendly Fire verursacht.

Übrigens... gab es gestern überhaupt einen Standup? Ich habe mich bei live.asp.net angemeldet, aber der Countdown wurde einfach zurückgesetzt, ohne Video/Feed oder so...

@Mike-EEE Sie haben gehört, dass du kommst :stuck_out_tongue_winking_eye:

Frustrierend, dass sie das getan haben. Ich habe darüber gebloggt: http://www.brettmorrison.com/microsofts-little-decision-is-a-big-mistake

Aus dem heutigen Standup: https://youtu.be/YJsQ3tnS7Ew?t=38m45s

Hier spricht er gezielt project.json an: https://youtu.be/YJsQ3tnS7Ew?t=26m12s

Obwohl das Format project.json viel einfacher zu bearbeiten ist (es sei denn, Sie befinden sich in der Phase des .NET-Entwicklers, ein Drag-and-Drop-Dataset-Affe zu sein), besteht das größte Problem für mich darin, dass sich niemand die Mühe macht, seine Bibliotheken auf die . netcore. Bisher habe ich es geschafft, einen Zweig von Restsharp zum Laufen zu bringen, aber dieser verwendet das project.json-Format. JSON.NET, Structuremap, NUnit usw. usw. haben alle veraltete DNX-Zweige, in denen es so aussieht, als hätten die Entwickler die Hoffnung aufgegeben.

Daher ist es etwas seltsam, .NET Core RC1/2 als Release Candidate zu bezeichnen, wenn das Projektformat das Befehlszeilentool dotnet entfernt wird. Das ist für mich immer noch Beta- oder sogar Alpha-Software, da es experimentell ist.

Meine Hauptmotivation für den Wechsel zu vNext besteht darin, billiges Linux-Hosting und Docker zu verwenden. Ein Projektmigrationstool so schnell wie möglich wäre ratsam, da die meisten Benutzer durch ihre Bibliotheken über Nuget-Referenzen ohne .NET Core-Versionen vollständig behindert werden.

@yetanotherchris dnx war ein Konzept in rc1, es wurde in rc2 in dotnet cli geändert, so dass die meisten dnx-Projekte oder Branches zu diesem Zeitpunkt veraltet wären

project.json ist immer noch hier und wird für rc2 benötigt, die Diskussion darüber wird in Zukunft nach RTM wegfallen

json.net aka newtonsoft.json funktioniert und wird vom Framework selbst verwendet, ich verwende es auch in meinen Projekten
Nunit ist nicht kompatibel, jeder verwendet xunit afaik
Structuremap hat eine rc2-kompatible Bibliothek

Es gibt immer noch viele Dinge von Drittanbietern, die noch nicht auf rc2 portiert wurden, aber Microsoft kontrolliert nicht das Timing anderer Projekte und wann sie kompatible Bibliotheken erstellen

@yetanotherchris Wenn Sie in Ihrem project.json Importe verwenden, können Sie die alten, nicht zum Netzstandard gehörenden Moniker angeben und sie werden verwendet:

"frameworks": {
  "netcoreapp1.0": {
    "imports": [
      "dotnet5.6",
      "dnxcore50",
      "portable-net45+win8"
    ]
  }

Aus diesem Grund haben sich wahrscheinlich noch nicht viele Leute die Mühe gemacht, ihre Bibliotheken zu aktualisieren. Es besteht keine Notwendigkeit, vor dem eigentlichen RTM ein weiteres bewegliches Ziel zu erreichen.

@joeaudette Ich habe über den Zweignamen (DNX) gesprochen, nicht über das Befehlszeilentool dotnet . Viele Leute verwenden NUnit, es ist so ziemlich die Defacto-Testsuite außerhalb von MsTest. Ich bin mir nicht sicher, woher Sie die JSON.NET- oder Structuremap-Pakete finden, es gibt eine inoffizielle Version von Structuremap namens DNX und einen Newtonsoft-Zweig hier und eine .NET Standard 1.0-Beta auf nuget.org (.net-Standard ist jetzt redundant .) Soweit ich weiss).

@neoKushan danke, ich werde das

Ich denke, mein Hauptpunkt war, dass es ein bisschen albern ist, es einen Release Candidate zu nennen, da es sich für die endgültige Version komplett ändern wird. Vielleicht werden wir in einem Monat eine Flut von Aktivitäten bekommen, jetzt sind die Build-Systeme nicht ganz anders als die alten und neuen - obwohl ich als jemand, der hauptsächlich Webentwickler ist, viel lieber project.json .

@yetanotherchris

(.net-Standard ist jetzt meines Wissens überflüssig).

Was bringt dich dazu das zu sagen? Netstandard wird mit der Projektänderung nicht verschwinden, es ist hier, um zu bleiben. Sie können in Ihren zukünftigen csproj-Dateien auf Netstandards abzielen. Netstandard ist unbedingt erforderlich. Einer der Hauptgründe, warum sie project.json aufgeben, ist die Vereinheitlichung des gesamten .net-Ökosystems und das ist es, was netstandard auch auf den Tisch bringt.

Ich denke, mein Hauptpunkt war, dass es ein bisschen albern ist, es einen Release Candidate zu nennen, da es sich für die endgültige Version komplett ändern wird.

Ich stimme dem zu einem gewissen Grad zu, obwohl ich glaube, dass es sich nicht so stark ändert, wie die Leute denken. Für den Anfang wird project.json noch für das RTM hier sein, alle Änderungen werden danach erfolgen. Sie könnten sich dann fragen, warum Sie es "Final" nennen, wenn es sich ändern wird und es vielleicht einen Punkt gibt, aber letztendlich Ihr gesamter Code und Ihre Bibliotheken und alles, was sich nicht ändert, ist nur das Projekt _definition_. Das ist keine so große Veränderung, wie man zunächst denken mag, aber ein bisschen Migrationsspaß wird es auf jeden Fall geben.

@yetanotherchris Sie müssen daran denken, dass rc2 eine Vorschau ist und Sie daher auch nach Vorschaupaketen von Drittanbietern suchen müssen
https://www.nuget.org/packages/Newtonsoft.Json/9.0.1-beta1
https://www.nuget.org/packages/StructureMap.Dnx/0.5.1-rc2-final

Ich weiß nicht, ob NUnit später unterstützt wird, aber im Moment verwenden die Leute in .NET Core- und ASP.NET Core-Projekten xunit
https://xunit.github.io/docs/getting-started-dotnet-core.html

@yetanotherchris Ich denke, wir sind uns alle einig, dass rc1 als Beta9 hätte bezeichnet werden sollen, rc2 ist die erste echte rc-Qualitätsversion
project.json und solche Tools sind nicht Teil des Frameworks per se, die Tools bleiben eine Vorschau und können für eine Weile geändert werden, selbst wenn das Framework RTM ist

Es würde mich nicht einmal wundern, wenn wir überhaupt zurückbringen - vielleicht behalten wir ein project.json, und es funktioniert nur in begrenzten Szenarien. Wenn die Leute das wollen, werden wir diese Idee unterstützen.

Scott Hunter, dotnetConf 2016 Tag 1 Keynote 12m24s

Weiß jemand, ob Mr. Hunter auf GitHub ist? Und das Geschwätz in den Produktforen verfolgen? So wie es klingt, verpasst er hier das Feedback.

Als Programmmanager für .NET und Visual Studio bezweifle ich, dass @coolcsh ehrlich gesagt die Freizeit hat.

Ich wäre ziemlich entsetzt, wenn er die Rückmeldungen nicht kennt. Vielleicht nicht alle Details, aber sicherlich gab es erhebliche Rückschläge.

Hier ist Ihre Chance für alle:
https://blogs.msdn.microsoft.com/webdev/2016/06/08/notes-from-the-asp-net-community-standup-june-2-2016/

Ich habe sozusagen einen Dollar in das Trinkgeldglas gesteckt. :stuck_out_tongue:

tugberkugurlu könnte mit dem Kommentar "plötzlich begannen die Entwickler von Dark Matter Enterprises Feedback hinter den verschlossenen Türen zu geben" auf der Spur gewesen sein. Anders ausgedrückt: „Unsere Unternehmenskunden haben berechtigte Bedenken hinsichtlich der Kompatibilität und ihrer aktuellen Investitionen in unsere Produkte geäußert“. Während die „Community“ unglücklich scheint, nicht den Löwenanteil an allem zu haben, tragen Unternehmenskunden einen ziemlich großen Stock: Sie zahlen viel Geld für den Zugang zu Plattformen, Tools und Support. Ihre Bedenken werden nicht ignoriert und sollten es auch nicht sein. Am Ende scheint MS zu streben, die maximale Anzahl von Entwicklern zu ermöglichen, einfach zu bauen, was sie erstellen möchten, und sie möchten auch versuchen, Interoperabilität und gemeinsame Nutzung entlang fast jeder definierbaren Domäne zu ermöglichen. Sie versprechen, dass csproj viel einfacher und leistungsfähiger wird. Also, jetzt sind sie bereit, das zu liefern.

Wie ich schon oft sagte, bin ich ein Unternehmensentwickler bei einer Großbank, ein Unternehmenskunde. WIR wurden zu diesen Änderungen nicht befragt. WER genau waren also die "Entwickler von Unternehmen der dunklen Materie"? Diese Informationen sind offenbar streng, streng geheim. 007-Level-Zeug.

Es ist schön und gut zu behaupten, dass Unternehmenskunden einen großen Stock tragen, aber anscheinend sind es nur EINIGE von ihnen, die dies tun. Welche? Nach welchen Kriterien? Wie kommen wir in diese privilegierte Liste? Welche Partnerebene ist das? Welche jährlichen Ausgaben? Forscher wollen wissen, wie viel GENAU wir MS zahlen müssen, bevor sie sich unsere Meinung anhören?

@shederman sind Sie ein Enterprise Mobile Dev oder Enterprise UWP Dev? Oder Enterprise Unity Dev?

Nichts des oben Genannten. Wir schreiben Kernsysteme für die Vermögensverwaltung und Bankenintegration. Einige Online-Sachen auch.

@shederman Ich vermute, das könnte der Grund sein, warum Sie nicht gefragt wurden?

Bitte klären Sie?

Wollen Sie wirklich damit sagen, dass die einzigen Unternehmensentwickler, die MS jetzt unterstützt, diejenigen sind, die für 1 % des Marktes mobil arbeiten, UWP-Apps für ähm, die 5 % der Benutzer, die sich darum kümmern, und Spieleentwicklung? Aus dem gesamten Entwicklungsspektrum kehrt MS allem den Rücken, aber das ?

Ähm. Nein.

Ich sage, dass die Änderungen nach Gesprächen mit _diesen_ Gruppen entstanden sind, deshalb wurden Sie nicht gefragt. Microsoft muss alle seine Entwickler unterstützen, nicht nur die ASP-Entwickler.

Ja, wenn sie also alle ihre Entwickler unterstützen wollen, sollten sie vielleicht mit allen Entwicklern sprechen. Vielleicht ist es nicht gut, nur mit einer ausgewählten Untergruppe von 5 % der Unternehmensentwickler zu sprechen, um die Meinungen der Unternehmensentwickler insgesamt einzuschätzen.

Um also die Meinung einer großen Bank zu hören, müssen wir unsere gesamte Entwicklung auf UWP/Unity/Mobile umstellen?

Das ist lächerlich.

Vielleicht sollten sie mit allen Entwicklern sprechen.

Ist das nicht das, was sie in den letzten 2+ Jahren gemacht haben?

@shederman Also nur weil _Sie persönlich_ nicht gefragt wurden, implizieren Sie, dass sonst niemand beteiligt war, der Ihren Entwicklungsbereich abdeckt?

Hören Sie außerdem auf, diese Zahlen zu erfinden – _das_ ist lächerlich.

@poke Ich

Ich fand die Zahlen eigentlich recht großzügig, aber okay.

@shederman Ich denke, du buchstäblich nach Jahren . Sie müssen sich nur umschauen, um zu sehen, dass viele Leute mehr von .net core wollten.

Es gibt auch die Frage der tatsächlichen Enterprise-Support-Anfragen von großen Organisationen, die wissen möchten, wie sie ihre bestehenden Sachen plattformübergreifend portieren können - Sie wurden wahrscheinlich nicht "gefragt", weil Sie nicht verlangten, dass jemand von Microsoft Ihnen das sagte Sie versuchen zu tun, würde den Rahmen des Projekts sprengen.

Eine andere Sichtweise - und so wie ich es persönlich sehe - ist, dass Sie gefragt wurden, als die Ankündigung vor Monaten erfolgte. Trotz aller Schreie von Leuten, die sagen, dass Entscheidungen ohne Rücksprache mit jemandem getroffen wurden, hat Microsoft wiederholt erklärt, dass sie noch an Details arbeiten, dass sie noch nicht die letzten Teile zusammengefügt haben und es jetzt an der Zeit ist, Ihre Meinung zu äußern . Scott Hunter sagte sogar, dass, wenn die Leute project.json _wirklich_ als Option haben wollen, sie erwägen, es zu behalten. Schauen Sie sich die dotnetconf-Keynote an, wenn Sie mir nicht glauben.

@neoKushan Ich weiß es zu schätzen, dass Scott ein wenig zurückgetreten ist und gesagt hat, dass sie es in Betracht ziehen würden, es zu behalten, aber es muss wirklich einen einzigen, zentralen Punkt geben, an dem die Leute ausdrücken können, dass sie dies wollen, sonst wird das Problem von project.json weiterhin auftauchen Diskussionen überall. Es bedeutet auch, dass jeder, wenn es angesprochen wird, mit dem gleichen "Hey, sie werden in Betracht ziehen, es zu behalten, wenn die Entwickler es wirklich wollen, hier ist, wo Sie sie wissen lassen" antworten können.

project.json war ein guter Schritt. Aber meiner Meinung nach war es naiv. Es berücksichtigt nicht, dass die Leute hybride Projekte haben möchten, die in C++ oder F# geschrieben sind. Einige ihrer frühen Designentscheidungen wie dnx und die Verwendung von Nuget als Montageeinheit waren für das Dotnet-Ökosystem als Ganzes nicht umsetzbar. Was Sie sehen, ist, dass sie, um Harmonie in Dotnet zu bringen, diese schwierigen Entscheidungen treffen müssen.

Forking und Re-inventing werden meiner Meinung nach dem Dotnet-Ökosystem nicht helfen, es wird ihm nur schaden. Node und Go (insbesondere Go) sind für Anfänger sehr attraktiv, da sie über eine homogene und konsistente Plattform/Tools verfügen.

Ich finde das ganze Argument XML vs. JSON albern, denn in weiteren 5 Jahren wird es JSON vs. YAML sein und danach YAML vs. Groovy (zB Gradle). XML ist nicht so böse, wie Sie es alle darstellen. MSBuild ist sehr ausgereift und enthält viele Investitionen, von denen alle profitieren werden.

Das sei gesagt, eine Menge Arbeit mit MSBuild getan werden muss , um sicherzustellen, dass Sie entweder gleich oder zumindest eine weniger schmerzhafte Art und Weise der Verwendung und Bearbeitung csproj Dateien bekommen kann. Verschieben Sie dann die Nuget-Abhängigkeiten in eine Datei nuget.json. Verwenden Sie Konvention über Konfiguration, damit Ihr csproj fast leer ist, wenn Sie sich auf dem "glücklichen Pfad" befinden, ein bisschen wie heute die web.config. und dann cli-Optionen haben, die das csproj optimieren

Für mich werde ich project.json vermissen, aber nicht aus den Gründen, die Sie denken. C#-Projekte werden in Ordnung sein. Ich werde es wegen F# vermissen. Ich habe es vorgezogen, project.json für die Kompilierungsreihenfolge zu bearbeiten, anstatt msbuild zu bearbeiten. Wieder nicht, weil XML böse ist, sondern weil fsproj-Dateien eine Menge Blähungen haben, die durch msbuild verursacht werden

Mein Problem mit dieser Entscheidung war in erster Linie die Art und Weise, wie es in der csproj-Datei weniger um xml/json ging als vielmehr darum, was sie in die csproj-Datei aufnehmen wollten. Es enthielt Projektdefinitionen, es enthielt IDE-Einstellungen, es enthielt Build-Schritte, es enthielt Referenzen ...

Es gibt nicht viel, was nicht in diesem Ding gelandet ist. Dies machte es schrecklich und wird nur verschlimmert, wenn msbuild manchmal ziemlich geheimnisvoll ist. Wenn Sie ernsthaft daran interessiert sind, .NET Core gut zu machen und nicht nur zu arbeiten, machen Sie die Projektdatei agnostisch für die Erstellung von Tools. Ich sollte in der Lage sein, anzugeben, was mein Projekt ist und wovon es abhängt, unabhängig davon, wie es erstellt wird. Ganz zu schweigen davon, dass uns dies die Wahl des Werkzeugs ermöglicht, auch wenn die anfängliche Option derzeit nur von msbuild unterstützt wird.

Ich stimme dem zu. Am Ende des Tages ist das Hauptproblem bei csproj, dass
es macht alles.

Ich mag den Mittelweg, den PatriotBob vorschlägt...

Am Dienstag, den 21. Juni 2016 um 13:28 Uhr schrieb PatriotBob [email protected] :

Mein Problem mit dieser Entscheidung war in erster Linie die Art und Weise, wie die csproj-Datei weniger war
über xml/json und vieles mehr darüber, was sie in das csproj aufnehmen möchten
Datei. Es enthielt Projektdefinitionen, es enthielt IDE-Einstellungen, es
enthaltene Build-Schritte, es enthält Referenzen...

Es gibt nicht viel, was nicht in diesem Ding gelandet ist. Das hat es geschafft
schrecklich und wird nur verschlimmert, wenn man mit msbuild zu tun hat
manchmal ziemlich obskur. Wenn Sie ehrlich daran interessiert sind, .NET Core gut zu machen
und nicht nur die Arbeit macht die Projektdatei unabhängig von Build-Tools. Ich sollte
in der Lage sein zu spezifizieren, was mein Projekt ist und wovon es unabhängig von
wie man es baut. Ganz zu schweigen davon, dass uns dies die Wahl lässt
Tooling, auch wenn die anfängliche Option gerade von msbuild unterstützt wird.

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/aspnet/Home/issues/1433#issuecomment -227511911 oder stumm
der Faden
https://github.com/notifications/unsubscribe/AKh-zsedLYg_PToadpD-_ewZPci0oHGCks5qOB8rgaJpZM4IcGCt
.

Das ganze XML ist schlecht, JSON ist großartig, wurde stark gehypt. Ich mag, was PatriotBobo sagt.

as/w-Projekt komplett von npm package.json noch nie so einfach und prägnant mein Projekt deklarieren, mein Projekt aufbauen, mein Projekt upgraden (zB Greenkeeper), Daten lesen/schreiben/parsen über mein Projekt und das Veröffentlichen meines Projekts so einfach. _so einfach. wie bei vielen von uns ist meine Geschichte in c++/java/python/node, mit Spiel in anderen. Ich sehne mich jetzt nach der Erfahrung von npm in all meinen Projekten.

die project.json versprachen dieselben Eigenschaften. Ich denke, es ist ein Modell, das es wert ist, nachgeahmt zu werden und nicht die Einfachheit und Kraft zu opfern.

wenn das .net-Kernteam des Teams der Meinung ist, dass die andere Lösung ihnen diese Eigenschaften bieten kann, ausgezeichnet und leistungsstark! Bitte untergraben Sie jedoch nicht die Schönheit der Einfachheit, während Sie fortschreiten.

Außerdem verstehe ich, dass ich zu diesem Zeitpunkt in einem riesigen Thread nur Lärm bin. Vielleicht sollten die Moderatoren erwägen, es zu schließen und die Tortur kontrollierter zu behandeln. viele gute Rückmeldungen. vielleicht auch ein bisschen Trolling :$ :)