Projekteigenschaften: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
LeonH (Diskussion | Beiträge) |
||
(15 dazwischenliegende Versionen von 4 Benutzern werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
{{stub}} | |||
[[VisualStudioTutorial|Microsoft Visual Studio]] erlaubt etliche Einstellungsmöglichkeiten für [[VisualStudioTutorial#Projekte|Projekte]], die die [[Compiler|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...". | |||
Im | {{BA|Dietsch|Wenn die einzelnen Reiter jetzt hier erklärt werden, könnte man eine eigene Überschrift für die alle machen und sowas sagen wie "Im Folgenden werden die einzelnen Reiter genauer erklärt."}} | ||
{{BA|Greitschus|So?}} | |||
== 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. | |||
{{BA|Dietsch|Was sind Darstellungseigenschaften? Hier werden doch so Sachen wie "Als was baue ich" und "wo kommen meine Ressourcen her" eingestellt, was hat das mit Darstellung zu tun?}} | |||
{{BA|Greitschus|Wenn ok, BA entfernen, sonst bitte nach eigenen Wünschen selbst ändern. Ich find es schwierig, das so zu formulieren, dass mit unteren Formulierungen keine Redundanz besteht und es in einem kurzen, prägnanten Satz klar ist, um was es gehen soll.}} | |||
[[Datei:project_properties_Application.jpg]] | [[Datei:project_properties_Application.jpg]] | ||
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 | 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 [[VisualStudioTutorial/Refactoring|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 <code>System.Linq</code>-Umgebung. | Ü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 <code>System.Linq</code>-Umgebung. | ||
{{BA|Dietsch|Das hier ist auch wichtig für Xbox-Deployment, bin aber nicht sicher ob wir das erwähnen sollten, den der Xbox 360 Artikel bietet auch keine gute Übersicht drüber, was man auf der Xbox darf und was nicht}} | |||
{{BA|Ruzzoli|Wuerde sowas alles in den Xbox 360 Artikel verlagern, finde den hier schon unuebersichtlich genug.}} | |||
"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. | "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. | ||
{{BA|Dietsch|Wollen wir hier eine Übersicht über die ganzen Output Types?}} | |||
{{BA|Ruzzoli|Ich wuerde sagen: Nein, nur die fuer das Sopra relevanten erwaehnen.}} | |||
{{BA|Greitschus|Dann bitte, tut euch keinen Zwang an... ^^}} | |||
"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 | "Startup object" legt fest, in welcher [[Klasse]] sich die Main-Methode befindet. Es ist möglich, innerhalb eines [[Projekt|Projektes]] mehrere Main-Methoden in unterschiedlichen [[Klasse|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. | ||
[[Datei:assembly_information.jpg|thumb|Assembly Information]] | [[Datei:assembly_information.jpg|thumb|Assembly Information]] | ||
Zeile 25: | Zeile 37: | ||
Professionelle Anwendungen sollten diese Informationen grundsätzlich enthalten. | 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 | 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 <code>.exe</code>-Version der Anwendung. | ||
=== Build === | |||
Der "Build"-Reiter der [[Projekteigenschaften]] ist der wichtigste Reiter, da sich über ihn grundsätzliche Eigenschaften der [[Compiler|kompilierten]] Versionen der Anwendung einstellen lassen. | |||
[[Datei:project_properties_build.jpg]] | |||
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 [[Compiler|kompilieren]]. | |||
{{BA|Dietsch|Vielleicht müsste man Konfiguration noch irgendwo erklären bzw. auf etwas entsprechendes verlinken; ausserdem ist die Architektur im Sopra fix, das könnte man auch noch erwähnen}} | |||
Grundsätzlich sind in [[CSharp|C#]] zwei Konfigurationen voreingerichtet: "Debug" und "Release". "Debug" dient zur [[Compiler|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: | |||
{{BA|Dietsch|Uhh, oh, Symbole, Präprozessordirektiven, ... das sollte man alles erklären und/oder verlinken}} | |||
{{BA|Greitschus|Letzter Satz dieses Abschnittes. So lassen? Früher bringen? Ganz rausschmeißen? Ändern?}} | |||
<source lang="csharp"> | <source lang="csharp"> | ||
static void Main(string[] args) | static void Main(string[] args) | ||
{ | { | ||
# | #if SHOW_INTRO | ||
Show_Intro(); | Show_Intro(); | ||
#endif | #endif | ||
Zeile 51: | Zeile 66: | ||
</source> | </source> | ||
Hierbei wird der der Code zwischen <code>#ifdef</code> und <code>#endif</code> 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 (<code>,</code>) getrennt angegeben. | Hierbei wird der der Code zwischen <code>#ifdef</code> und <code>#endif</code> 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 (<code>,</code>) 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. | [[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 | "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}} | |||
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 | Mit "Allow unsafe code" kann ausgewählt werden, ob der [[Compiler]] unsicheren [[CSharp|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. | {{BA|Dietsch|Hier dann auf die Unsafe-Sektion des CSharp Artikels linken}} | ||
"Optimize code" sorgt dafür, dass der [[Compiler]] während des [[Compiler|Kompilierens]] eine Codeoptimierung vornimmt, die die Ausführungszeit und die Geschwindigkeit von großen Programmen enorm verbessern kann. Da das [[Compiler|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. | Die restlichen Einstellungen dieses Reiters sind selbst-erklärend bzw. nicht sonderlich wichtig. Es kann nützlich sein, das eine oder andere auszuprobieren. | ||
{{BA|Dietsch|Dann hier auch gerne auf detailiertere Infos in der MSDN oder sonstwo linken}} | |||
{{BA|Greitschus|S.u.}} | |||
[[Kategorie:Code-Beispiele]] | |||
== Resources == | === 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. | 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. | ||
{{BA|Dietsch|Was ist eine Ressource für ein XNA-Game? Wie hängt das mit Assets zusammen?}} | |||
{{BA|Greitschus|Eine Ressource kann alles sein. Ein eingebundenes Bild, eine Stringliste für unterschiedliche Sprachen, Icons, die verwendet werden, usw. Das hat erstmal nichts mit XNA zu tun, sondern primär nur mit VisualStudio und C#}} | |||
[[Datei:project_properties_resources.jpg]] | |||
=== Ü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. | |||
{{BA|Dietsch|Entweder das mit dem Publish rauslassen (für das Sopra ohnehin etwas schwierig, denk nur an Copyright ;p - oder auch hier Link auf ausführlichere Infos}} | |||
== | == Siehe auch == | ||
# [http://msdn.microsoft.com/en-us/library/bb1aa8f1.aspx MSDN-Seite zum Projekteigenschaftsdialog] | |||
[[Kategorie:Code-Beispiele]] | [[Kategorie:Code-Beispiele]] | ||
[[Kategorie:VisualStudio]] | [[Kategorie:VisualStudio]] |
Aktuelle Version vom 12. Oktober 2020, 12: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.
Ü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.