Anleitung zum Bootstrap und Erstellen von .NET-Projekten

.NET-Projekt erstellen

Das Erstellen eines .NET-Projekts von Grund auf ist so einfach wie die Verwendung des Visual Studio-Assistenten. Gehen Sie zu File => New Project oder Add New Project zu einer vorhandenen Projektmappe hinzufügen. Sobald ein neues Projekt erstellt wurde, können Sie sofort mit dem Codieren beginnen. Allerdings sind die von Assistenten erzeugten Projektvoreinstellungen für professionelle Teams kaum akzeptabel, da sie die Qualitätslatte zu niedrig ansetzen. Darüber hinaus kann kein Assistent andere Setup-Schritte kennen, die Sie in Ihrer speziellen Entwicklungsumgebung ausführen müssen.

In diesem Artikel werde ich Sie durch einige wichtige Einstellungen führen, die Sie aktivieren sollten, sobald Sie ein neues Projekt erstellen, was wichtig ist, um zukünftige technische Schulden zu minimieren. Außerdem werden wir einige gängige Verfahren besprechen, die viele .NET-Entwickler anwenden, wenn sie Lösungen und neue Projekte strukturieren. Auch wenn Sie einige dieser Ideen nicht anwenden, ist es schön zu lernen und sich einen Überblick darüber zu verschaffen, was die meisten Teams tun.

Struktur

Eine klar definierte Struktur ist für komplexe Projekte von entscheidender Bedeutung. Dies verbessert das Onboarding-Erlebnis, wenn Neulinge einem Team beitreten, und erleichtert Ihnen das Leben, wenn Sie alte Projekte unterstützen. Es gibt zwei Schlüsselindikatoren für eine gute Struktur:

• Verwenden von Lösungs- und Projektordnern
• Konsequente Benennung

Ordner

Lösungsordner, manchmal auch als virtuelle Ordner bezeichnet, sind ein sehr praktisches Instrument, um Ihre Projekte zu gruppieren. Klicken Sie in der Projektmappen- Explorer -Ansicht einfach mit der rechten Maustaste und wählen Add => New Solution Folder aus, und ziehen Sie dann eines der vorhandenen Projekte per Drag-and-Drop in diesen neuen Ordner. Diese Ordner werden nicht im Dateisystem gespiegelt, sodass Sie die physische Struktur unverändert lassen können, sodass sie beim Verschieben der Projekte von einem Projektmappenordner in einen anderen nicht physisch verschoben werden.

Nummerierte Präfixe sind nicht erforderlich, aber dadurch werden die Ordner direkt im Projektmappen-Explorer- Fenster geordnet angezeigt.

Visual Studio kann mit mehreren Lösungen gleichzeitig arbeiten, indem partitionierte Einzellösungs- oder Multilösungsmodelle genutzt werden. Sie werden selten verwendet, daher werde ich sie in diesem Artikel nicht behandeln.

Im Gegensatz zu Projektmappenordnern entsprechen Projektordner der physischen Ordnerstruktur und bleiben daher als echte Ordner auf der Festplatte bestehen. Darüber hinaus sollten Projektordner, die einen C#-Code enthalten, mit dem Namespace des Projekts übereinstimmen. Dies macht die Navigation ziemlich natürlich. Sie können sogar eine ReSharper-Regel aktivieren, um bei solchen Diskrepanzen zu warnen.

Benennung

Es gibt einige empfohlene Regeln für die Benennung:

• Verwenden Sie CamelCase.
• Ein Projektname sollte mit dem Namen seiner Ausgabeassembly übereinstimmen.
• Ein Projekt, das automatisierte Tests enthält, sollte das Suffix .Tests haben.
• Alle Projektnamen sollten ein gemeinsames Präfix haben, z. B. Company.Product .

Es gibt auch wenige vernünftige Regeln. Sie sollten selbst entscheiden, wann Sie sie anwenden, basierend auf Ihrem gesunden Menschenverstand (und natürlich der englischen Grammatik):

• Verwenden Sie Subjekte im Plural, wenn ein Container (Projekt oder Ordner) mehrere Instanzen derselben Art enthält (z. B. Tests oder System.Collections ).
• Verwenden Sie die Singularform, wenn der gesamte Container Code zu einer einzigen Entität enthält (z. B. System.Collections.ObjectModel`).
• Verwenden Sie für kurze Abkürzungen Großbuchstaben wie System.IO .
• Verwenden Sie für lange Abkürzungen CamelCase wie Modules.Forex. .

Als Faustregel gilt: Eine kurze Abkürzung sollte nicht länger als drei Zeichen sein.

Lösung konfigurieren

Das Konfigurieren einer Lösung ist so einfach wie das Bereitstellen aller Infrastrukturdateien, die Sie für Ihre Umgebung benötigen. Obwohl einige von ihnen später hinzugefügt werden können (z. B. CI-Integrationsdateien), sollten Sie einige Dateien besser gleich am Anfang haben.

ReSharper-Einstellungen

Wenn Sie ein professioneller .NET-Entwickler sind, verwenden Sie höchstwahrscheinlich ReSharper. ReSharper ist sehr flexibel bei der Verwaltung seiner Einstellungen. Als Teamleiter können Sie vom Team freigegebene Einstellungen erstellen und verteilen, die von anderen Entwicklern verwendet werden. Team Shared- Einstellungen werden in einer Datei mit der Erweiterung .DotSettings . ReSharper wählt diese Einstellungen automatisch aus, wenn der Dateiname mit dem Namen der Visual Studio-Lösung übereinstimmt:

 MyCompany.MyProduct.sln MyCompany.MyProduct.sln.DotSettings

Daher sollten Sie diese Datei ganz am Anfang erstellen, wenn Sie einige Einstellungen letztendlich auf das gesamte Team anwenden möchten. Ein gutes Beispiel wäre die Regel, das Schlüsselwort var zu verwenden (oder nicht zu verwenden). Ihre Team Shared -Einstellungsdatei kann nur diese eine Regel haben, während andere die Präferenz der Entwickler sind. Es ist erwähnenswert, dass die ReSharper-Einstellungen auf die gleiche Weise auf Projektebene festgelegt werden können, da Sie möglicherweise Legacy-Code haben, den Sie nicht ändern können (z. B. Änderung zur Verwendung des Schlüsselworts var ).

Wenn Sie diese Datei korrekt benannt haben, wie im Beispiel gezeigt, wählt jede neue Instanz von Visual Studio mit einer neuen ReSharper-Einrichtung diese Datei automatisch aus und erzwingt die Regeln. Vergessen Sie nicht, diese Datei an die Quellcodeverwaltung zu übergeben.

StyleCop-Regeln

Genau wie die ReSharper-Einstellungen können Sie die StyleCop-Einstellungen teilen. Wenn Sie ReSharper verwenden, haben Sie wahrscheinlich ein Integrations-Plugin installiert, das StyleCop von ReSharper nutzt. StyleCop speichert seine Einstellungen jedoch unabhängig in Dateien mit dem Namen Settings.StyleCop . Ebenso können Sie diese Datei zusammen mit Lösungsdateien und Projektdateien haben.

Wenn Sie StyleCop verwenden, vergessen Sie nicht, das StyleCop-Konfigurationstool auszuführen und die Prüfungen zu deaktivieren, die Sie nicht durchführen möchten. Standardmäßig sind alle Prüfungen aktiviert. Speichern Sie neue Einstellungen in dieser Datei und übernehmen Sie die Quellcodeverwaltung.

Textdateien

Wenn Sie ein öffentliches Produkt erstellen und den Quellcode veröffentlichen, vergessen Sie nicht, diese Dateien ebenfalls zu erstellen und zu übertragen:

 README.md LICENSE

Ich empfehle die Verwendung des Markdown-Formats für die README.md -Datei, da es sich zu einem Industriestandard entwickelt hat und von öffentlichen Quellcodeverwaltungsdiensten wie GitHub sowie von internen Servern wie BitBucket (früher Stash) unterstützt wird.

NuGet-Spezifikationen

Wenn Sie eine Bibliothek erstellen, die in NuGet Gallery verteilt werden soll, müssen Sie sehr wahrscheinlich Paketspezifikationsdateien wie MyProject.nuspec . Ich ziehe es vor, diese Dateien manuell zu erstellen und sie der Quellcodeverwaltung zu übergeben. Pakete werden normalerweise von einem Ihrer Continuous-Integration-Jobs (kurz CI) freigegeben, aber Sie können ein Paket auch jederzeit manuell über die Konsole wie folgt erstellen und veröffentlichen:

 nuget.exe pack MyLibrary.nuspec

Vergessen Sie nur nicht, die Paketversion zu erhöhen, bevor Sie diesen Befehl ausführen.

CI-spezifische Dateien

Wir alle verwenden unterschiedliche CI-Server, und alle haben unterschiedliche Konfigurationsskripte und Einstellungen. Ich möchte nur einige der üblichen Ergänzungen erwähnen, die Sie möglicherweise hinzufügen möchten:

• NUnit -Einstellungen, die angeben, welche Assemblys Tests enthalten, die auf dem CI-Server für bestimmte Jobs ausgeführt werden sollen. Alle Tests sind praktisch in einige Kategorien aufgeteilt. Es gibt Unit-Tests , die bei jedem Build ausgeführt werden sollten, Performance-Tests , die jede Nacht ausgeführt werden, und Integrationstests , die auf Release-Basis ausgeführt werden.
• NCover- Einstellungen, die angeben, welche Testassemblys für die Testabdeckung analysiert werden sollen.
• SonarQube -Einstellungen, die Softwaremetriken bestimmen, werden erfasst.
• Jobskripte wie NAnt, PowerShell oder einfach Windows-Batchdateien.

Projekte konfigurieren

Projektdateien, nämlich .csproj oder .vbpro , enthalten alle Einstellungen, die von Visual Studio und MSBuild verwendet werden. Allerdings sind nicht alle im Fenster Projekteigenschaften verfügbar. Um diese Dateien in Visual Studio manuell zu bearbeiten, sollten Sie wie folgt vorgehen:

• Klicken Sie in der Projektmappen-Explorer-Ansicht mit der rechten Maustaste auf ein Projekt.
• Wählen Sie Projekt entladen aus .
• Klicken Sie erneut mit der rechten Maustaste, um die Aktion Edit xyz.csproj auszuwählen .
• Vollständige Bearbeitung.
• Klicken Sie erneut mit der rechten Maustaste auf das Projekt und wählen Sie Projekt neu laden .

Alternativ können Sie eine Projektdatei in Ihrem bevorzugten Texteditor öffnen, bearbeiten und speichern. Wenn Sie zurück zum Visual Studio-Fenster wechseln, werden Sie aufgefordert, das geänderte Projekt neu zu laden.

Warnungssteuerung

Um eine qualitativ hochwertige Software zu erstellen, müssen Sie Build-Warnungen niemals ignorieren. Daher sollten Sie die maximale Warnstufe aktivieren und alle Warnungen als Fehler behandeln. Beachten Sie, dass Sie dies für alle Build-Konfigurationen tun sollten, die Sie haben, z. B. Debug und Release. Dazu schreiben Sie am besten die folgenden Einstellungen in die gemeinsame Eigenschaftsgruppe:

 <WarningLevel>4</WarningLevel> <TreatWarningsAsErrors>true</TreatWarningsAsErrors>

Und stellen Sie sicher, dass Sie nicht dieselben Einstellungen in anderen Eigenschaftsgruppen haben. Andernfalls überschreiben sie die entsprechenden Eigenschaften aus der gemeinsamen Gruppe.

FxCop

Das Ausführen von FxCop ist bei jedem Build nur praktisch. Die meisten Teams ziehen es vor, FxCop von Zeit zu Zeit (normalerweise vor einer Veröffentlichung) auszuführen, um sicherzustellen, dass keine schwerwiegenden Fehler eingeführt wurden. Wenn Sie jedoch bei jedem Build eine ultimative Überprüfung durchführen möchten, fügen Sie diese Option hinzu:

 <RunCodeAnalysis>true</RunCodeAnalysis>

Beachten Sie, dass FxCop wie StyleCop über eigene Einstellungen verfügt, die im Stammordner abgelegt und der Quellcodeverwaltung hinzugefügt werden können. Diese Einstellungen werden wahrscheinlich verwendet, wenn FxCop auf CI-Servern ausgeführt wird.

Dokumentation

In diesem Teil geht es um XmlDoc. Wenn Sie eine öffentliche API erstellen, sollten Sie eine API-Dokumentation erstellen und pflegen. Die meisten Entwickler beginnen mit der API-Entwicklung (eigentliche Codierung) und aktivieren kurz vor einer Veröffentlichung die Projekteinstellung Build / XML documentation file . Natürlich erscheinen nach einem weiteren Rebuild eine Reihe von Fehlern, da jedes fehlende XmlDoc zu einem Build-Fehler führt. Um dies zu vermeiden, sollten Sie die erwähnte Option gleich zu Beginn aktivieren.

Wenn Sie zu faul sind, eine anständige Dokumentation zu schreiben, oder wenn Sie nicht gerne zu viel Text eingeben, probieren Sie Instrumente aus, die diesen Prozess automatisieren, wie z. B. GhostDoc.

Code-Verträge

Code Contracts ist ein hervorragendes Framework von Microsoft Research, mit dem Sie Vorbedingungen, Nachbedingungen und Objektinvarianten in Ihrem Code zur Laufzeitüberprüfung, statischen Analyse und Dokumentation ausdrücken können. Ich habe dies in vielen kritischen Projekten verwendet, und es hat sehr geholfen, also ermutige ich Sie, es auszuprobieren.

Wenn Sie sich für die Verwendung von Code Contracts entscheiden, ist es wichtig, Contracts gleich zu Beginn zu aktivieren, wenn Sie gerade ein neues Projekt erstellt haben. Das Hinzufügen von Verträgen mitten in der Entwicklung ist möglich, erfordert jedoch Änderungen in vielen Klassen, damit Kontakte miteinander übereinstimmen. Vergessen Sie also nicht, alle erforderlichen Einstellungen zu aktivieren (mindestens CodeContractsEnableRuntimeChecking ) und stellen Sie sicher, dass diese Einstellungen in der gemeinsamen Eigenschaftsgruppe erscheinen.

StyleCop-Durchsetzung

Zuvor haben wir über die StyleCop-Konfiguration für die Entwicklungszeit gesprochen. Wenn Ihr Projekt jedoch auf einem CI-Server erstellt wird, hat ReSharper dort keine Auswirkungen, und daher sollten wir die Ausführung der StyleCop-Validierung mit MSBuild aktivieren.

Dies geschieht normalerweise durch manuelle Modifikation der Projektdatei. Sie müssen das Projekt in Visual Studio entladen, die Projektdatei bearbeiten und das Projekt dann wieder laden:

 <PropertyGroup> <!— add this to the common property group (common to Debug/Release/etc) —> <StyleCopTreatErrorsAsWarnings>false</StyleCopTreatErrorsAsWarnings> </PropertyGroup> <!— add this Import in the very bottom —> <Import Project="$(ProgramFiles)\MSBuild\Microsoft\StyleCop\v4.3\Microsoft.StyleCop.targets">

Die Einstellung StyleCopTreatErrorsAsWarnings wird tun, was sie sagt: Sie wird Ihren Build bei jedem Verstoß gegen StyleCop-Regeln unterbrechen. Das import-Element ist für MSBuild erforderlich, um die StyleCop-Aufgabe zur Buildkette hinzuzufügen.

Möglicherweise ist Ihnen der Pfad zu Program Files aufgefallen. Da Entwickler möglicherweise verschiedene StyleCop-Versionen installiert haben, ziehen es einige Teams vor, eine private Kopie derselben StyleCop-Installation unter Quellcodeverwaltung zu halten. In diesem Fall ist der Pfad relativ. Dies erleichtert auch die Einrichtung von CI-Rechnern, da Sie StyleCop nicht lokal installieren müssen.

AssemblyInfo

Für jedes vom Visual Studio-Assistenten erstellte .NET-Projekt wird die Datei „ AssemblyInfo.cs “ automatisch ausgefüllt (siehe Unterordner „ Properties “), die einige der Assembly -Attribute enthält, aber kein Assistent kann alle Assembly -Attribute für Sie ausfüllen. Stellen Sie sicher, dass mindestens diese Attribute ausgefüllt sind:

• AssemblyTitle
• AssemblyDescription
• AssemblyCompany
• AssemblyProduct
• AssemblyCopyright
• AssemblyVersion

Dieses absolute Minimum ist für alle Assemblys erforderlich, die Sie verteilen werden. Ein praktischer Grund dafür ist NuGet: Wenn Sie die automatische NuGet-Spezifikationserstellung aus der ausgewählten Baugruppendatei verwenden, leitet dieses Tool die erforderlichen Informationen aus diesen Eigenschaften ab.

Sie können auch ganz am Anfang eine weitere Eigenschaft füllen:

 InternalsVisibleTo

Diese Eigenschaft macht interne Klassen und Schnittstellen für die angegebene Assembly sichtbar. Dies wird im Allgemeinen für automatisierte Tests verwendet, die Sie für Ihr Projekt erstellen werden.

Verbindungszeichenfolgen

Wie Verbindungszeichenfolgen verwaltet werden, ist eine sehr beliebte Frage im Stack Overflow. Das Problem besteht darin, Verbindungszeichenfolgen für jeden Entwickler oder einen CI-Job eindeutig zu machen und Verbindungsdetails nicht offenzulegen, während der Quellcode veröffentlicht wird.

Nehmen Sie in App.config (für Desktop-Anwendungen) oder Web.config (für Webanwendungen) die folgende Einstellung vor, die die user.config -Datei zur Laufzeit lädt. Halten Sie dies unter Ihrer Quellcodeverwaltung:

 <?xml version="1.0" encoding="utf-8" ?> <configuration> <connectionStrings configSource="user.config"></connectionStrings> </configuration>

Anscheinend sollte die Datei user.config von der Quellcodeverwaltung ausgeschlossen werden, und jeder Entwickler sollte eine lokale Kopie dieser Datei haben, um die Privatsphäre der Verbindungszeichenfolge zu wahren:

 <connectionStrings> <add name="test" connectionString="Server=.;Database=...;"/> </connectionStrings>

.gitignorieren

Für diejenigen, die Git als Quellcodeverwaltung verwenden, ist es wichtig, der .gitignore -Datei einige Dateimuster hinzuzufügen. Unsere intelligente Community hat jedoch bereits eine verallgemeinerte Datei erstellt, die hier zu finden ist: github.com/github/gitignore/blob/master/VisualStudio.gitignore.

Sie sollten es als .gitignore -Referenzdatei nehmen und einfach Ihre benutzerdefinierten Ausschlüsse hinzufügen, die Sie möglicherweise zusätzlich benötigen.

GitHub-Abzeichen

Vielleicht haben Sie auf der Seite des README -Projekts gut aussehende Abzeichen gesehen. Wenn Sie Ihr Projekt auf GitHub veröffentlichen, ziehen Sie in Betracht, Ihr Projekt mit öffentlichen Diensten zu verbinden, um:

• Gebäude: um anzuzeigen, dass ein Build fehlschlägt oder bestanden wird.
• Testen: um die Testabdeckung und den Testausführungsstatus anzuzeigen.
• Veröffentlichung: um die neueste NuGet-Paketversion anzuzeigen.

Eine vollständige Liste der Abzeichen und zugehörigen Dienste finden Sie auf shields.io. Möglicherweise finden Sie viele interessante Abzeichen, die sich gut für Open-Source-Projekte eignen.

Nachdem Sie Ihr Projekt bei einem ausgewählten Dienst registriert haben, erhalten Sie einen Link zum Bild und einen vollständigen Markdown-Syntax-Link, den Sie Ihrer README.md -Datei hinzufügen können. Das ist übrigens einer der Gründe, warum Sie Markdown für Readme- Dateien bevorzugen sollten.

Beispiel-Markdown-Badges aus dem Roslyn-Projekt:

[![Build Status]([http://dotnet-ci.cloudapp.net/job/roslyn_master_win_dbg_unit32/badge/icon)](http://dotnet-ci.cloudapp.net/job/roslyn_master_win_dbg_unit32/)](http://dotnet-ci.cloudapp.net/job/roslyn_master_win_dbg_unit32/badge/icon)](http://dotnet-ci.cloudapp.net/job/roslyn_master_win_dbg_unit32/)) [![Join the chat at [https://gitter.im/dotnet/roslyn](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/dotnet/roslyn?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)](https://gitter.im/dotnet/roslyn](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/dotnet/roslyn?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge))

Automatische Validierung der Lösungsstruktur

Auch wenn Sie alle Einstellungen vorgenommen haben, die wir in diesem Artikel besprochen haben, kann einer Ihrer Entwickler sie früher oder später ändern und die Änderungen an die Quellcodeverwaltung übertragen. Manchmal geschieht dies versehentlich, und oft werden diese Änderungen während der Codeüberprüfung nicht erfasst. Abgesehen von diesen Unfällen sollten wir auf die folgenden häufigen Fehler achten:

• Schlechte Referenzen : Wenn jemand auf eine lokale Assembly verweist, die andere möglicherweise nicht haben, oder wenn jemand eine Datei von der Festplatte gelöscht hat, während der Link zu dieser Datei in der .csproj -Datei verbleibt. Dies wird den Build mit Sicherheit unterbrechen, aber es kann zu spät passieren, wenn die Änderung gepusht wird und andere sie ziehen. Dies ist besonders wichtig für statische Webdateien, die Sie während des Builds nicht überprüfen können.
• Benennungskonsistenz : Die Tools wie StyleCop können den C#-Quellcode steuern, aber keine Tools können Regeln für Projektdateien oder Assembly-Eigenschaften erzwingen. Hier ein gutes Beispiel: Wir möchten Projekte so benennen, dass sie mit dem Namen der Ausgabeassembly übereinstimmen, und wir möchten, dass Projektnamen ein gemeinsames Präfix wie MyCompany.MyProduct haben.

Ich habe festgestellt, dass das Beobachten dieser Fehler in Code Reviews fehleranfällig ist und automatisiert werden sollte. Also habe ich ein einfaches Tool geschrieben, das diese und viele andere Prüfungen durchführt, um die Lösungskonsistenz zu überprüfen. Lernen Sie SolutionInspector kennen. Dies ist Open Source und wird unter MIT-Lizenz vertrieben. Sie können es aus dem Quellcode erstellen oder von NuGet installieren:

 Install-Package SolutionInspector

Das Tool durchläuft die gesamte Lösungsstruktur und wendet viele Validierungsregeln an. Die Regeln werden durch XML-Dateien konfiguriert, die zusammen mit anderen Lösungsdateien platziert werden. Um die Einstellungen auf Projektbasis zu steuern, fügen Sie einfach dieselbe Datei mit unterschiedlichen Einstellungen zum entsprechenden Projektordner hinzu.

Standardmäßig ist keine Konfigurationsdatei erforderlich. In diesem Fall wendet das Tool alle verfügbaren Regeln an und gibt alle Probleme an die Konsole weiter.

Hier ist das Beispiel der Konfigurationsdatei:

 <?xml version="1.0" encoding="utf-8"?> <Settings xmlns:xsi="[http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">](http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">) <SolutionSettings> <MinSolutionFormatVersion>12.00</MinSolutionFormatVersion> <MaxSolutionFormatVersion>12.00</MaxSolutionFormatVersion> <DetectMissingFiles>true</DetectMissingFiles> <ProjectNamePrefix>MyCompany.MyProduct.</ProjectNamePrefix> <ProjectNameIsFileName>true</ProjectNameIsFileName> <IgnoredProjects> AVerySpecialProject1; AVerySpecialProject2; </IgnoredProjects> </SolutionSettings> <ProjectSettings> <DetectMissingFiles>true</DetectMissingFiles> <AllowBuildEvents>true</AllowBuildEvents> <AssemblyNameIsProjectName>true</AssemblyNameIsProjectName> <RootNamespaceIsAssemblyName>true</RootNamespaceIsAssemblyName> <RequiredImports>StyleCop.MSBuild.Targets</RequiredImports> <Properties> <TreatWarningsAsErrors>true</TreatWarningsAsErrors> <StyleCopTreatErrorsAsWarnings>false</StyleCopTreatErrorsAsWarnings> </Properties> </ProjectSettings> </Settings>

Obwohl die Einstellungen eher beschreibend sind, werde ich einige davon erklären:

• MinSolutionFormatVersion / MaxSolutionFormatVersion verhindert, dass Ihre Entwickler die Visual Studio-Version wechseln.
• DetectMissingFiles ist sehr nützlich für statische Webinhalte oder andere Nicht-Code-Dateien, die der Projektmappe oder einem Projekt hinzugefügt werden.
• AllowBuildEvents kann verhindern, dass benutzerdefinierte Build-Ereignisse hinzugefügt werden, die möglicherweise unnötige Dinge tun.
• Properties sind das flexibelste Element: Sie können alle Eigenschaften mit den gewünschten Werten vergleichen, unabhängig davon, ob es sich um bekannte oder benutzerdefinierte Eigenschaften handelt.

Fazit

Wir haben mehrere Standardverfahren, Konfigurationsdateien und Projekteinstellungen überprüft, die Sie anwenden können, wenn Sie ein neues Projekt starten. Dies von Anfang an zu tun, würde zukünftige technische Schulden verringern und Ihren Produktquellcode schön und professionell aussehen lassen. Für Open-Source-Projekte ist dies von besonderer Bedeutung, da jeder Mitwirkende Ihre Erwartungen kennen würde, indem er Lösungskonfigurationen und Projektdateien untersucht.