Häufig gestellte Fragen zu Microsoft .NET Native

Werden F#, Visual Basic oder die von mir bevorzugte Sprache unterstützt?

Diese Vorschauversion unterstützt lediglich C#-Code, da dies die .NET-Sprache ist, die von den meisten Store-Apps verwendet wird. Es hindert uns jedoch nichts daran, alle .NET-Sprachen zu unterstützen, wenn wir unseren Fokus erweitern.

Geht es hier nur um die Leistungsfähigkeit, oder ermöglicht dies auch die Entwicklung von C#-Code (z. B.), der systemeigen zu Win32/64 kompiliert wird und für den keine Installation des .NET Framework auf dem Zielcomputer erforderlich ist?

Das ist richtig: Bei .NET Native geht es nicht nur um die Leistung, sondern auch um Produktivität und eine konsistente Geräteumgebung. Mit .NET Native können Sie Code mittels verwalteter Sprachen schreiben und wie gewohnt MSIL-Pakete hochladen. Die Apps werden auf den Geräten der Endbenutzer jedoch als völlig eigenständiger, systemeigen kompilierter Code bereitgestellt (wenn .NET Native die Produktionsphase erreicht) und sind nicht davon abhängig, ob .NET Framework auf dem Zielgerät/-computer installiert ist. Wie Sie wissen, decken .NET-Anwendungen ein breites Spektrum ab. Daher investieren wir außerdem erheblich in das gesamte .NET Framework (beispielsweise haben wir gerade eine CTP von RyuJIT veröffentlicht).

Welche Szenarien wurden während des Entwurfs berücksichtigt?

Die Entwurfsarbeiten fanden unter Berücksichtigung von Store-Apps für Geräte statt. Ziel war es, Entwicklern weiterhin die Nutzung der Produktivitätsvorteile von .NET und MSIL und das Hochladen von MSIL-Paketen in den Store zu ermöglichen und gleichzeitig Endbenutzern eine Leistung wie bei systemeigenem Code (C++) bereitzustellen (wobei die Kompilierung, ähnlich wie im Fall von Windows Phone 8, in der Cloud durchgeführt wird).

Wird .NET Native das .NET Micro Framework ersetzen, und wird C#/.NET vollständig für kleine Geräte verfügbar sein?

.NET Native konzentriert sich zurzeit auf Windows Store-Apps. Das Micro Framework wird vom Windows Embedded-Team bereitgestellt, und das .NET-Team arbeitet mit diesem zusammen, um zu ermitteln, wie Kunden am besten bedient werden können.

Kann die Entwicklervorschau für die Erstellung von Windows Phone-Apps und -Bibliotheken verwendet werden?

Es können universelle Klassenbibliotheken erstellt werden, die mit .NET Native kompatibel sind. In dieser Vorschau können lediglich Windows Store-Apps mittels .NET Native erstellt werden. Die Unterstützung von Windows Phone-Apps durch .NET Native ist noch in der Entwicklung.

Ermöglicht dies C#-Entwicklern eine bessere Erfahrung bei der Entwicklung von grafisch komplexen Apps und/oder Spielen?

Ja. Der .NET Native-Compiler hat Teile der Codebasis mit dem Microsoft C++-Optimierungstool gemeinsam.

Werden Server-/Desktop-Apps von .NET Native und/oder vom Compiler in der Cloud profitieren?

Desktop-Apps bilden einen sehr wichtigen Teil unserer Strategie. Anfangs werden wir uns mit .NET Native jedoch auf Windows Store-Apps konzentrieren. Längerfristig werden wir die systemeigene Kompilierung für alle .NET-Anwendungen kontinuierlich verbessern.

Wie funktionieren Verknüpfungen? Wird Framework-Code in die Anwendung kompiliert? Wie wirkt sich dies auf die Größe von Paketen/Binärdateien aus?

Ja, Framework-Code wird in die Anwendung kompiliert. Da die Mehrzahl der Store-Apps über einen hohen Anteil von Multimediakomponenten verfügt, ist der Unterschied bei den Paketgrößen nicht erheblich.  Der Codeumfang verändert sich zwar, es werden jedoch nur die Abschnitte des Frameworks verknüpft, die von der App verwendet werden. Im Endergebnis befinden sich Binärdateien, die mit .NET Native kompiliert werden, in der gleichen Kategorie wie mit NGEN kompilierte Binärdateien, was die Größe angeht.  Wir untersuchen weiterhin Strategien, mit denen wir den Unterschied in der Größe weiter reduzieren können.

Die Kompilierung mit .NET Native ist langsamer als mit MSIL. Warum?

Die normale App-Entwicklung verwendet die MSIL/JIT-Standardentwicklungsumgebung in Visual Studio. Der .NET Native-Compiler wird erst aufgerufen, wenn die Anwendung auf dem Gerät bereitgestellt wird – wenn der Entwicklungsprozess zum größten Teil abgeschlossen ist und sich der Schwerpunkt hin zur Optimierung der App verlagert. Zu diesem Zeitpunkt sind die Kompilierungszeiten denen von optimierten C++ mit Link-Zeitcodegenerierung vergleichbar.

Was geschieht mit P/Invokes? Werden sie zu DLL-Standardaufrufen optimiert?

Auch wenn die Binärdateien systemeigen kompiliert werden, werden die Sicherheitsvorteile durch verwalteten Code (und damit Garbage Collection) und das vollständige C#-Ausnahmemodell beibehalten. Wir haben mit .NET Native außerdem die Interop-Pfade deutlich optimiert. Auch wenn P/Invokes nicht zu DLL-Standardaufrufen optimiert werden, ist der Aufwand für GC-Synchronisierung und möglicherweise erforderliches Marshalling minimal.

Welche Einschränkungen gibt es? Werden offene Generika und Reflektion unterstützt?

.NET Native wird alle Features unterstützen, die von der Zielplattform unterstützt werden, wenn es die Produktionsphase erreicht. Da es sich um eine Vorschauversion handelt, in der sich zahlreiche Features noch in der Entwicklung befinden, gibt es zum aktuellen Zeitpunkt einige Einschränkungen. Es werden jedoch sowohl offene Generika als auch Reflektion in dieser Vorschaufunktion unterstützt (auch mit statischer Kompilierung). In dieser Vorschaufunktion verfügt der Compiler über integrierte Heuristiken, die zu ermitteln versuchen, welche generischen Instanziierungen und Metadaten zur Laufzeit benötigt werden. Daher wird voraussichtlich eine große Zahl von Apps einfach funktionieren, ohne dass die Quelle zugunsten des Compilers vereinfacht wird.

Wie können für diese Apps Patches bereitgestellt werden, und wie werden diese Apps gewartet?

Das Wartungsmodell für Apps bleibt das gleiche. Im Fall des Frameworks werden nach dem aktuellen .NET-Modell Bibliotheksupdates automatisch bereitgestellt. Wir untersuchen nach wie vor verschiedene Optionen und würden uns über Ihre Vorschläge und Kommentare freuen.

Da die nicht verwendeten Methoden entfernt werden: Kann angegeben werden, dass eine Methode (oder eine ganze Klasse) verwendet wird, auch wenn sie niemals direkt aufgerufen wird?

Ja, in der Vorschau werden Anweisungen des Entwicklers zur Verwendung einer Methode (oder eines Typs) unterstützt, auch wenn sie (oder er) nicht direkt aufgerufen wird. (Weitere Informationen finden Sie in der Dokumentation zu den Laufzeitdirektiven).