Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Pourquoi adopter le compilateur .Net Native pour la plateforme Universelle Windows?
Pour gagner en performance et bien plus encore, estime Microsoft

Le , par Olivier Famien

42PARTAGES

2  0 
Depuis l’introduction de la compilation .NET Native dans Visual Studio 2013 update 2, les applications ont gagné en performance. Côté utilisateurs, les logiciels s’exécutent plus rapidement avec un temps de démarrage réduit. Par ailleurs, l’usage de la mémoire par ces applications a été réduit.

Tous ces avantages dénotent de la nécessité d’utiliser la compilation .Net Native qui compile le code source des applications en code natif lors de la génération du package tandis que le compilateur à la volée lui compile le code intermédiaire en code natif avant l’exécution d’une méthode par exemple.

Vu les avantages du premier, Microsoft a fait le choix du compilateur .Net Native et recommande celui-ci pour la compilation des applications destinées à tourner sur sa Plateforme Universelle Windows.

Comme avantages résultant de l’adoption de ce compilateur pour les applications Windows Universelles, Microsoft indique que les applications gagnent en performance à cause du temps de démarrage qui est réduit. Pour vous faire également une d’idée de ces gains, Microsoft avance que ces performances sont de l’ordre de celles enregistrées à travers les applications conçues avec C++.

En outre, avec ce compilateur, les applications universelles consomment moins d’énergie lorsqu’elles sont compilées nativement. La seule contrainte observée est que le compilateur met plus de temps à générer les binaires par rapport au compilateur classique. Si le temps de compilation n’est pas un souci pour vous, alors .Net Native sera votre mode de compilation privilégiée.

En plus des gains de performance et l’usage réduit de la mémoire, il faut lui ajouter également, un délestage des bibliothèques du framework après compilation des binaires. Vous pouvez utiliser vos binaires sans vous soucier de l’importation des bibliothèques associées. Seul élément requis pour le fonctionnement de ces applications, c’est le runtime .Net Native. Microsoft précise que le runtime sur le terminal sera toujours compatible avec le package de l’application.

En outre, lorsque vous aurez besoin de créer le package de votre application dans Visual Studio, vous constaterez que la configuration AnyCPU permettant de cibler plusieurs architectures a disparu. Pour créer les différents packages des applications, vous n’aurez besoin que de sélectionner les trois plateformes x86, x64 et ARM et de vous laisser guider par Visual Studio.

Enfin en dernier point, il faut savoir que le compilateur .Net Native est également utilisé sur le Cloud. En effet, lorsque vous créez vos applications, deux packages sont générés. Un avec l’extension .appx et un autre avec l’extension .appxuload. Le premier est utilisé pour des tests en local tandis que le second est chargé en ligne pour être hébergé sur le store.


Et compte tenu du fait que .Net Native est également hébergé en ligne, c’est lui qui va compiler ce fichier pour vous directement sur le Cloud. Il ne faut donc pas uploader le binaire .app sur le store, mais plutôt celui le fichier avec l’extension .Appxuload.

De même, le compilateur en ligne prendra en charge le nommage des versions. Toutefois, une certaine marge est donnée au développeur afin qu’il puisse garder le contrôle sur cet aspect. Lors du développement avec Visual Studio, il est donc recommandé de laisser le numéro du package à « 0 » lors de la création du package.

Source : Blog Microsoft

Et vous ?

Que pensez-vous de ce compilateur ?

Que pensez-vous des changements apportés avec ce compilateur pour la Plateforme Universelle ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de octal
Membre éclairé https://www.developpez.com
Le 26/08/2015 à 11:12
Qu'en est-il de la décompilation des binaires générés? sont ils vraiment mieux protégés contre la décompilation? parce que avec les assembly c'est vraiment la cata (même en utilisant les obfuscateurs).
0  0 
Avatar de lunatix
Rédacteur https://www.developpez.com
Le 26/08/2015 à 11:40
hum, ils poussent quand même a abandonner la "VM" .net la non ?
0  0 
Avatar de DonQuiche
Expert confirmé https://www.developpez.com
Le 26/08/2015 à 12:49
Citation Envoyé par lunatix Voir le message
hum, ils poussent quand même a abandonner la "VM" .net la non ?
De toute façon le concept de VM veut tout et rien dire selon l'interlocuteur. D'ailleurs MS ne l'utilise pas.

L'important est qu'il n'y a que des avantages. Meilleures performances, sécurité et robustesse inchangées, rien à changer au code (au pire une ou deux annotations pour embarquer les métadonnées).
0  0 
Avatar de goldbergg
Membre actif https://www.developpez.com
Le 26/08/2015 à 17:07
Sait-on si c'est possible de faire du code natif pour autre chose que les universelle Apps?

Sinon on lisant vite fait la doc, il semblerai que la réflexion et la sérialisation risque de devenir tous de suite bien plus chiant a utiliser... (mais bon sa parait logique).
0  0 
Avatar de dfiad77pro
Membre expérimenté https://www.developpez.com
Le 26/08/2015 à 17:56
Citation Envoyé par goldbergg Voir le message
Sait-on si c'est possible de faire du code natif pour autre chose que les universelle Apps?

Sinon on lisant vite fait la doc, il semblerai que la réflexion et la sérialisation risque de devenir tous de suite bien plus chiant a utiliser... (mais bon sa parait logique).
Non tout appli Utilisant WPF/Winforms ne peut actuellement être compilée avec .NET native.
0  0