FAQ sur Microsoft .NET Native

F#, VB ou mon langage préféré seront-ils pris en charge ?

Cette version préliminaire prend en charge uniquement le code C#, car c'est langage .NET utilisé par la plupart des applications du Windows Store. Mais rien ne nous empêche de prendre en charge n'importe quel langage .NET si nous élargissons notre champ.

S'agit-il uniquement de performances, ou est-il également possible de créer du code C# (par exemple) compilé en mode natif en Win32/64 et de ne pas avoir besoin d'installer le .NET Framework sur l'ordinateur cible ?

C'est exact : .NET Native ne se limite pas aux performances, mais intègre aussi la productivité et une expérience cohérente des périphériques. Il vous permet d'écrire du code avec des langages managés et de télécharger les packages MSIL comme d'habitude. Toutefois, les applications seront déployées sur les périphériques d'utilisateur final en tant que code compilé en mode natif totalement autonome (lorsque .NET Native entre en production) et n'auront aucune dépendance sur le .NET Framework du périphérique/de l'ordinateur cible. Comme vous le savez, les applications .NET couvrent un large éventail. Par conséquent, nous investissons également beaucoup dans le .NET Framework (par exemple, nous venons de sortir une version CTP de RyuJIT).

Quels scénarios ont été pris en compte lors de la conception de cette version ?

Voici les scénarios que nous avions en tête : applications du Windows Store pour les périphériques afin de permettre aux développeurs de conserver les gains de productivité de .NET et MSIL et de charger les packages MSIL sur le Windows Store, et de fournir aux utilisateurs finaux du code natif (C++) en bénéficiant des performances (et la compilation ayant lieu sur le cloud de la même façon qu'avec Windows Phone 8).

.NET Native remplacera-t-il .NET Micro Framework et C#/.NET seront-ils totalement disponibles pour les petits périphériques ?

.NET Native se concentre actuellement sur les applications du Windows Store. Micro Framework est fourni par l'équipe Windows Embedded, et l'équipe .NET travaille avec cette dernière sur la meilleure façon de satisfaire les clients.

La version préliminaire pour les développeurs permet-elle de créer des applications et des bibliothèques Windows Phone ?

Les bibliothèques de classes universelles peuvent être créées et fonctionner avec .NET Native. Dans cette version préliminaire, seules les applications du Windows Store peuvent être créées à l'aide de .NET Native. Nous travaillons sur un futur développement possible des applications Windows Phone avec .NET Native.

Cela offrira-t-il aux développeurs C# une meilleure expérience en matière de développement d'applications et/ou de jeux d'une grande qualité graphique ?

Oui. Le compilateur .NET Native partage des parties de la base de code avec l'optimiseur Microsoft C++.

Les applications serveur/de bureau tireront-elles parti de .NET Native et/ou du compilateur sur le cloud ?

Les applications de bureau constituent une partie très importante de notre stratégie. Au départ, nous nous concentrons sur les applications du Windows Store avec .NET Native. À long terme, nous continuerons d'améliorer la compilation en mode natif de toutes les applications .NET.

Comment fonctionne la liaison ? Le code d'infrastructure est-il compilé dans l'application ? Comment cela affecte-t-il les tailles de package/binaire ?

Oui, le code d'infrastructure sera compilé dans l'application. Quant aux tailles de package, comme la plupart des applications du Windows Store comportent une grande quantité de multimédia, la différence n'est pas importante.  Par conséquent, la taille du code ne change pas. Toutefois, seules les portions de l'infrastructure utilisées par l'application y sont liées. Au final, les binaires compilés avec .NET Native sont du même ordre que ceux compilés avec NGEN.  Nous sommes toujours à la recherche de stratégies qui nous permettront de réduire davantage la différence de taille.

La compilation avec NET Native est plus lente qu'avec MSIL. Pourquoi ?

Le développement normal d'applications utilise une expérience de développement MSIL/JIT standard dans Visual Studio. Le compilateur .NET Native n'est pas appelé tant que l'application n'est pas déployée sur le périphérique, que la majeure partie du processus de développement n'est pas finie et que la priorité n'est pas mise sur l'optimisation de l'application. À ce stade, les temps de compilation sont similaires à ceux de C++ optimisé avec la génération du code durant l'édition de liens.

Que deviennent les P/Invoke ? Sont-ils optimisés pour les appels DLL standard ?

Même si les binaires sont compilés en mode natif, nous conservons les avantages de la cohérence managée des types de code (et par conséquent du nettoyage de la mémoire) et du modèle d'exception C# complet. Avec .NET Native, nous avons également fortement optimisé les chemins d'accès d'interopérabilité. Ainsi, alors que les P/Invoke n'optimisent pas immédiatement les appels DLL standard, une charge minimale est nécessaire pour effectuer une synchronisation du nettoyage de la mémoire et tout marshaling nécessaire.

Quelles sont les limites ? Les génériques ouverts et la réflexion sont-ils pris en charge ?

.NET Native prendra en charge toutes les fonctionnalités prises en charge par la plateforme cible lors de sa mise en production. Comme il s'agit d'une version préliminaire avec beaucoup de fonctionnalités en cours de développement, certaines limites existent aujourd'hui. Ceci dit, les génériques ouverts et la réflexion y sont pris en charge (et même avec une compilation statique !). Dans cette version préliminaire, le compilateur comporte une méthode heuristique qui essaie de déterminer les instanciations et les métadonnées génériques requises au moment de l'exécution. Ainsi, un grand nombre d'applications doivent tout simplement fonctionner sans avoir à simplifier la source au profit du compilateur.

Comment ces applications peuvent-elles être corrigées ou faire l'objet d'une maintenance ?

Le service de maintenance des applications reste inchangé. Pour l'infrastructure, le modèle actuel de .NET consiste en des mises à jour automatiques des bibliothèques. Nous efforçons d'étudier les différentes possibilités envisageables et nous sommes impatients de lire vos suggestions et vos commentaires.

Si les méthodes non utilisées sont supprimées, existe-t-il une façon de dire qu'une méthode (ou une classe entière) est utilisée, même si elle n'a jamais été appelée directement ?

Oui. Dans la version préliminaire, le développeur peut indiquer qu'une méthode est utilisée même si elle n'a pas été appelée directement, même chose pour un type (consultez la documentation sur les directives relatives au runtime).