Projekteigenschaften: Unterschied zwischen den Versionen
LeonH (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
LeonH (Diskussion | Beiträge) |
||
Zeile 70: | Zeile 70: | ||
[[CSharp|C#]] besitzt die Möglichkeit, zwei dieser Symbole automatisch einer Anwendung hinzuzufügen. Diese Symbole heißen "DEBUG" und "TRACE". Wie im obigen Beispiel können diese Symbole innerhalb des Codes abgefragt und so das Verhalten der Anwendung in der Debug- bzw. der Release-Umgebung gesteuert werden. Eine detailliertere Übersicht über Präprozessordirektiven befindet sich im dazugehörigen [[Präprozessor-Anweisungen|Artikel]]. | [[CSharp|C#]] besitzt die Möglichkeit, zwei dieser Symbole automatisch einer Anwendung hinzuzufügen. Diese Symbole heißen "DEBUG" und "TRACE". Wie im obigen Beispiel können diese Symbole innerhalb des Codes abgefragt und so das Verhalten der Anwendung in der Debug- bzw. der Release-Umgebung gesteuert werden. Eine detailliertere Übersicht über Präprozessordirektiven befindet sich im dazugehörigen [[Präprozessor-Anweisungen|Artikel]]. | ||
"Platform Target" erlaubt es, die Architektur, auf der die Anwendung später laufen soll, auszuwählen. Die beiden gängigen Werte hier sind "x86" für gewöhnliche | "Platform Target" erlaubt es, die Architektur, auf der die Anwendung später laufen soll, auszuwählen. Die beiden gängigen Werte hier sind "x86" für gewöhnliche 32-Bit-Systeme und "X64" für 64-Bit-Systeme. Grundsätzlich muss bei dieser Einstellung vorsichtig vorgegangen werden. Wird zum Beispiel eine C++-[https://de.wikipedia.org/wiki/Dynamic_Link_Library DLL] aus der Anwendung heraus angesprochen, die für ein 64-Bit System [[Compiler|kompiliert]] wurde, könnte es sein, dass die Anwendung bei Verwendung der 32-Bit Architektur als Target abstürzt. | ||
{{BA|Dietsch|Unterschied zwischen Platform target und Platform? Außerdem: 32 und 64bit sind beide x86 instruction set, x64 meint also x86-64bit}} | {{BA|Dietsch|Unterschied zwischen Platform target und Platform? Außerdem: 32 und 64bit sind beide x86 instruction set, x64 meint also x86-64bit}} | ||
Aktuelle Version vom 12. Oktober 2020, 13:19 Uhr
Microsoft Visual Studio erlaubt etliche Einstellungsmöglichkeiten für Projekte, die die Kompilierungsergebnisse verändern. In diesem Artikel soll ein kurzer Überblick über die wichtigsten und sinnvollsten Einstellungen gegeben werden.
Die Projekteigenschaften sind erreichbar über einen Rechtsklick auf ein Projekt -> Properties im Solution-Explorer, oder über das Hauptmenü mit den Menüpunkten "Project" -> "<Name> Properties...".
Der Eigenschaftendialog
Im Folgenden werden die wichtigsten Unterpunkte des Eigenschaftendialogs für ein Projekt erläutert.
Application
Im Application-Reiter der Projekteigenschaften können die wichtigsten Einstellungen zur Darstellung (Programmsymbol, ...) und den Assembly-Informationen zur Anwendung geändert werden. Ebenfalls wichtig sind die Einstellungen zur Zielarchitektur und Projekttyp.
Grundsätzlich sollten die Einstellungen für "Assembly name" und "Default namespace" nicht verändert werden, da sich diese negativ auf das Programmverhalten auswirken können und unter Umständen dazu führen, dass die gesamte Anwendung neu refactored werden muss. Ändert man den "Assembly name", hat dies Einfluss darauf, wie andere Projekte innerhalb einer Solution das aktuelle Projekt sehen. Dies dient vor allem der Referenz des Projektes in anderen Projekten. "Default namespace" legt fest, in welchem Namensraum neu hinzugefügte Klassen automatisch angelegt werden sollen.
Über "Target Framework" lässt sich auswählen, für welche Version des .NET-Frameworks die Anwendung gebaut werden soll. Hier gilt zu beachten, dass unter Umständen ältere Versionen des .NET-Frameworks bestimmte Features nicht unterstützen. Beispielsweise bieten die .NET-Versionen unter 3.5 noch nicht die System.Linq
-Umgebung.
"Output type" gibt den Ausgabetyp der Anwendung an. Hier kann unter anderem auch DLL ausgewählt werden. Nützlich kann dies sein, wenn an einer Anwendung gearbeitet wird und später entschieden wird, dass das Projekt doch besser eine DLL werden soll und keine Konsolenanwendung.
"Startup object" legt fest, in welcher Klasse sich die Main-Methode befindet. Es ist möglich, innerhalb eines Projektes mehrere Main-Methoden in unterschiedlichen Klassen zu haben. Man kann sich vorstellen, dass eine Klasse mit Main-Methode zum Testen bestimmter Programmeigenschaften gestartet wird, während eine andere Klasse mit Main-Methode gebraucht wird, um die Anwendung normal zu starten. Mit dieser Option lässt sich die entsprechende Klasse auswählen. In den meisten Programmiersprachen wird dies auch als "Entry Point" der Anwendung bezeichnet.
![](/images/thumb/2/2c/Assembly_information.jpg/300px-Assembly_information.jpg)
Über den Button "Assembly Information" öffnet sich ein Fenster, in dem Metainformationen zur Anwendung eingetragen werden können. Diese Informationen werden zum Beispiel im Windows-Explorer angezeigt, wenn die Eigenschaften einer ausführbaren Datei abgerufen werden.
Professionelle Anwendungen sollten diese Informationen grundsätzlich enthalten.
Im unteren Teil des "Application"-Reiters können noch weitere Informationen hinzugefügt werden. Hier ist vermutlich nur das Icon wichtig, da es viel über eine Anwendung aussagen kann. Ein Icon bietet einen zusätzlichen Übersichtlichkeitsgewinn. Eine Anwendung kann über ein markantes Icon schneller gefunden werden, als über ihren Text. Außerdem verstärkt die Benutzung eines eigenen Programmsymbols den Eindruck von Professionalität. Dabei ist das Icon hier ein anderes, als beispielsweise das in der Main-Form gesetzte. Setzt man das Icon im Eigenschaftsdialog für eine Form, hat die Programm-Executable immernoch das Standard-Icon. Damit auch die Anwendung ein anderes Icon erhält, kann man hier eines auswählen. So erhält es automatisch die ausführbare .exe
-Version der Anwendung.
Build
Der "Build"-Reiter der Projekteigenschaften ist der wichtigste Reiter, da sich über ihn grundsätzliche Eigenschaften der kompilierten Versionen der Anwendung einstellen lassen.
Zunächst lässt sich am oberen Rand einstellen, für welche Konfiguration und welche Architektur die Einstellungen vorgenommen werden sollen. Die hier ausgewählte Konfiguration entspricht der Konfiguration, die der Compiler verwendet, wenn er den Auftrag bekommt, die Anwendung zu kompilieren.
Grundsätzlich sind in C# zwei Konfigurationen voreingerichtet: "Debug" und "Release". "Debug" dient zur Kompilierung von Code unter Testbedingungen, während es sich bei mit "Release" generiertem Code um auslieferbaren Code handelt. Es lassen sich weitere Konfigurationen hinzufügen, die eine granularere Unterteilung der Umgebungen zulassen.
Über das Feld "Conditional compilation symbols" lassen sich weitere Symbole hinzufügen. Zum Beispiel kann es sein, dass eine Anwendung ein Intro besitzen soll, welches aber nur nach Fertigstellung angezeigt werden soll. Man könnte an dieser Stelle ein Symbol "SHOW_INTRO" definieren. Im Code selbst ist es dann möglich, mittels Präprozessordirektiven dieses Symbol abzufragen:
static void Main(string[] args)
{
#if SHOW_INTRO
Show_Intro();
#endif
Show_MainWindow();
}
Hierbei wird der der Code zwischen #ifdef
und #endif
nur dann ausgeführt (und sogar nur dann kompiliert), wenn in den Projekteigenschaften "SHOW_INTRO" als "Conditional compilation symbol" definiert wurde. Die Symbole dort werden durch Komma (,
) getrennt angegeben.
C# besitzt die Möglichkeit, zwei dieser Symbole automatisch einer Anwendung hinzuzufügen. Diese Symbole heißen "DEBUG" und "TRACE". Wie im obigen Beispiel können diese Symbole innerhalb des Codes abgefragt und so das Verhalten der Anwendung in der Debug- bzw. der Release-Umgebung gesteuert werden. Eine detailliertere Übersicht über Präprozessordirektiven befindet sich im dazugehörigen Artikel.
"Platform Target" erlaubt es, die Architektur, auf der die Anwendung später laufen soll, auszuwählen. Die beiden gängigen Werte hier sind "x86" für gewöhnliche 32-Bit-Systeme und "X64" für 64-Bit-Systeme. Grundsätzlich muss bei dieser Einstellung vorsichtig vorgegangen werden. Wird zum Beispiel eine C++-DLL aus der Anwendung heraus angesprochen, die für ein 64-Bit System kompiliert wurde, könnte es sein, dass die Anwendung bei Verwendung der 32-Bit Architektur als Target abstürzt.
Mit "Allow unsafe code" kann ausgewählt werden, ob der Compiler unsicheren C#-Code zulassen soll, oder nicht. In als unsicher deklariertem Code ist es unter anderem Möglich, mit Zeigern auf dem Speicher zu arbeiten. Allerdings sollte unsicherer Code nur mit Bedacht verwendet werden.
"Optimize code" sorgt dafür, dass der Compiler während des Kompilierens eine Codeoptimierung vornimmt, die die Ausführungszeit und die Geschwindigkeit von großen Programmen enorm verbessern kann. Da das Kompilieren einer Anwendung mit Codeoptimierung allerdings länger dauert, als ohne, sollte diese Funktion nur im Release-Modus verwendet werden.
Die restlichen Einstellungen dieses Reiters sind selbst-erklärend bzw. nicht sonderlich wichtig. Es kann nützlich sein, das eine oder andere auszuprobieren.
Resources
In "Resources" können alle Ressourcen, die in der Anwendung vorhanden sind - also Bilder, Icons, Audiodateien, usw. - verwaltet und angesehen werden. Es gibt auch die Möglichkeit, neue Ressourcen für die Anwendung hinzuzufügen.
Übrige Einstellungen
Die sonstigen Einstellungsmöglichkeiten der Projekteigenschaften können vernachlässigt werden. Neben vielen Einstellungen zu Sicherheit und Referenzen, bietet sich hier unter anderem noch die Möglichkeit, über den "Publish"-Reiter die Anwendung an ein Webverzeichnis zu verteilen, von dem sich Kunden das Programm und neuere Versionen herunterladen können. Der Vorteil dieser Methode besteht in der Notifizierungsfunktion bei einem Update der Anwendung. Die Anwendung überprüft dann automatisch, ob neuere Versionen vorliegen.