IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

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 !

Microsoft présente Blend pour la préversion de Visual Studio 2015
Pour vous permettre de créer de belles applications XAML

Le , par Stéphane le calme

637PARTAGES

1  0 
La semaine dernière, Microsoft dévoilait la préversion de Visual Studio 2015, maintenant l’entreprise a annoncé Blend pour Visual Studio 2015 avec une interface utilisateur repensée pour permettre aux développeurs de créer de plus belles applications en XAML. « Blend a un nouveau look élégant compatible avec Visual Studio pour l'amélioration de flux de travail entre les deux produits », explique Microsoft qui affirme avoir tiré parti des technologies Visual Studio pour fournir un meilleur explorateur de solution et le support du contrôle des sources dans Blend. Il faut également noter que XAML IntelliSense et des fonctions de débogage de base sont maintenant disponibles. Passons donc en revue quelques nouveautés apportées par cette mouture.

Parlons tout d’abord de XAML IntelliSense. Microsoft explique que Blend prend en charge toutes les capacités communes à IntelliSense y compris la complétion de déclaration, le support des opérations de la plupart des éditeurs comme les commentaires ou la mise en forme du code.


Cette mouture embarque également des fonctions de débogage de base : vous pouvez désormais déboguer dans Blend et même établir des points d'arrêt dans votre code afin de déboguer votre application en cours d'exécution. Pour maintenir une expérience de débogage compatible avec Visual Studio, Blend inclut les fenêtres et barres d'outils de débogage de Visual Studio.

Avec « Peek in XAML », vous pourrez désormais visualiser et modifier les contrôles et les ressources XAML dans le contexte dans lequel ils sont utilisés. Vous pouvez même naviguer à travers une série de déclarations XAML sans quitter le fichier d'origine de XAML. De plus, vous pourrez également effectuer une modification du style et des modèles directement dans le document qui les utilise en vous servant de la fonction « Peek in XAML ».


Pour modifier vos fichiers XAML, vous pouvez le faire en vous servant de Blend ou de Visual Studio et avoir vos fichiers modifiés automatiquement rechargés dès lors que vous alternez entre Blend et Visual Studio. Cependant, afin de minimiser l’interruption de votre flux de travail, vous pouvez définir vos préférences de rechargement dans une boîte de dialogue prévue à cet effet.


Notons aussi la présence de Solution Explorer qui vous fournit une vue organisée de vos projets et de leurs fichiers, ainsi que l'accès facile aux commandes qui leur sont associés. Microsoft estime qu’avec cet explorateur il est plus facile de travailler avec les grands projets de l'entreprise. En outre, toutes les capacités du projet qui manquaient dans Blend sont maintenant disponibles, y compris la capacité de modifier les configurations des builds.

Team Explorer est intégré pour vous permettre de gérer vos projets avec Git ou TFS référentiels pour faciliter la collaboration en équipe. Vous pouvez également gérer les packages NuGet dans Blend. NuGet est un gestionnaire de paquets pour le .NET Framework qui simplifie l'installation et la suppression des paquets à partir d'une solution.

Blend a été pensé pour vous fournir une meilleure accessibilité. Aussi, vous pouvez utiliser votre clavier et le logiciel de lecture d'écran pour interagir avec plusieurs zones de l'interface utilisateur de Blend, y compris les menus de niveau supérieur, explorateur de solution, et explorateur de l'équipe. « Nous travaillons activement à rendre plus accessible Blend dans les futures versions de Visual Studio 2015 », promet Microsoft.

Essayez Blend pour Visual Studio avec la préversion de Visual Studio 2015

Source : Microsoft

Et vous ?

Qu'en pensez-vous ?

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

Avatar de dfiad77pro
Membre expérimenté https://www.developpez.com
Le 01/04/2015 à 21:14
Citation Envoyé par clementmarcotte Voir le message
Bonjour,

Si je me fie à l'illustration, c'est aussi adieu aux éditions Express. Encore qu'il faut reconnaître que VS2013 Community est actuellement mieux pourvu que les VS2013 Express.
Personnellement je trouve que l'express est trop limitée car absence totale de plu-gins, genre entity framework avec oracle, c'est mort pour le tooling...

bon les 1millions de CA sont vites atteins mais pour une startup qui démarre ça peut aider.
4  0 
Avatar de I_Pnose
Membre chevronné https://www.developpez.com
Le 02/04/2015 à 14:22
Citation Envoyé par Washmid Voir le message
Pour du pur C#, je ne l'ai pas essayé personnellement mais un ami utilise SharpDevelop à son boulot, il m'a montré un peu, ça semble être un clone gratuit qui fonctionne tout aussi bien
SharpDevelop n’arrive clairement pas à la cheville (que dis-je, à la voute plantaire =P) de Visual Studio en terme de tooling. Je ne dénigre pas l’outil, mais on ne peut sérieusement pas dire qu’il est le pendant gratuit de l’IDE de Microsoft.

Nativement VS propose déjà des outils dont on a du mal à se passer en basculant sur une autre IDE (outil de profilage, débogage intra-VM, etc...) mais en plus sa notoriété fait qu’une multitude de plugins viennent étendre encore davantage ses possibilités (le piège étant de ne pas trop en installer, sinon on se retrouve réellement avec une usine à gaz).

Pour peu que vous déployiez des services dans Azure, que vous utilisiez TFS, que vous développiez des applications mobiles multiplateformes natives (via Xamarin) ou pas, alors il n’y a pas de concurrence sérieuse pour le moment.

Citation Envoyé par Washmid Voir le message
Si tu prends eclipse dans la même situation, bah... la compilation étant incrémentale, c'est instantané (avec un capacité de montée en charge assez bluffante)
Ben... même principe avec Visual Studio, si tu actives la compilation incrémentale, seules les méthodes modifiées seront recompilées (et ta solution devrait mieux s'en sortir...). De même (mais ça je pense que VS s'en sort tout seul) vérifier que dans les options de l'IDE le nombre de builds parallèles correspondent un tant soit peu au nombre de cœurs disponibles.
4  0 
Avatar de JolyLoic
Rédacteur/Modérateur https://www.developpez.com
Le 06/04/2016 à 20:40
Le problèmes des PCH, c'est qu'ils ne sont pas composables. Tu ne peux pas dire je prend le PCH lié à la lib A, et celui de la lib B, et je les fait tourner ensemble. Tu es obligé de faire un PCH spécifique qui ne marche que quand tu utilises A puis B.

Donc les PCH sont spécifiques à chaque projet, et doivent être générés dans chaque cas. Et se pose la question de savoir ce qu'on met dedans, et ce qu'on garde sous forme de #include en dehors du PCH. Si on n'en met pas assez, on est trop lent, si on en met trop, à chaque compilation incrémentale, on va devoir re-générer l'ensemble du PCH et perdre du temps.

On peut voir les modules comme des PCH mais qui sont composables, et où tu aurais un PCH par header (ou groupe de headers étroitement liés). Tu as généré le code précompilé pour A, celui pour B, tu peux les utiliser séparément ou ensemble, dans l'ordre que tu veux. Du coup, quand tu livres ta bibliothèque, tu livres le précompilé avec qui peut directement être réutilisé. Jamais tu n'auras besoin de le code client de parser les headers de cette bibliothèque. Pourquoi peut-on faire ça avec les modules, mais pas avec les PCH ? Voir ma réponse à la seconde question.

isolation from macros = en quoi les macros posent pb ?
Ce sont elles qui empêchent toute composabilité. Quand tu inclues un .h dans ton code, la manière de l'interpréter dépend de l'ensemble des macros définies au moment où tu l'inclues. Qui n'a jamais eu sous windows un problème pour inclure un header d'une bibliothèque third party après un #include <windows.h> parce ce dernier définit une macro min... L'idée de base est qu'un module ne dépende pas des macros définies avant qu'il soit importé, et qu'en retour, il ne pollue pas l'environnement avec ses propres macros. Et là, la modularité commence à apparaître.
Je dis "l'idée de base" parce que certains aimeraient bien pouvoir dire que sélectivement, telle ou telle macro définie dans un module pourrait être visible de l'extérieur. C'est en discussion.

il y a plus de problemes non resolus que de REELS problemes resolus (pas de gestion de namespace donc conflits potentiels, pas de versioning, description des fonctions non lisibles dans les fichiers binaires de 'package').
Je ne pense pas qu'il s'agisse forcément de réels problèmes, mais d'une simple description de ce que les modules ne sont pas, pour éviter les confusions :

Namespaces : Certains langages (Java par exemple) lient structure physique du code (modules, fichiers source) et structure logique (namespaces, classes). D'autres ne le font pas (C# par exemple). La proposition de module pour le C++ choisi de ne pas le faire. Ce n'est en rien une limitation, mais un choix qui fait sens en C++ (sinon, comment ajouter une spécialisation de std::hash ?).
Versionning : On a déjà tous des outils pour gérer les versions, tu as parlé de nuget par exemple, je ne vois pas trop quel rôle les modules pourraient jouer là dedans, à part éventuellement en terme de réflexion, qui peut toujours s'ajouter.
Binary distribution : C'est un problème potentiel. Mais d'un autre côté, les autres langages ont bien réussi à résoudre ce problème. Quand on distribue une assembly .NET, c'est bien un binaire qu'on distribue, et ça fait déjà 15 ans que ça dure sans problèmes. Ce qui va être plus dur est d'avoir un format compatible entre différents vendeurs (Microsoft a proposé d'open-sourcer le sien, Clang a dit qu'il était hors de question qu'ils l'utilisent). Mais la situation ne sera pas pire que ce qu'elle est aujourd'hui : On risque de devoir quand même compiler une bibliothèque pour le compilo qu'on utilise, comme on le fait aujourd'hui. C'est juste qu'on risque aussi de ne pas avoir besoin de le faire, si le mainteneur de la bibliothèque nous fourni un module compilé pour notre compilateur, chose qui était très difficile avant, à cause des multiplicités de gestions de macros. Donc la situation ne devient pas parfaite, mais elle s'améliore quand même.

Et sinon, pour avoir expliqué à pas mal de débutants, oui, les #include, c'est compliqué. Et parfois même des professionnels aguerris galèrent pendant des heures pour faire un #include dans certains contextes...
3  0 
Avatar de Kikuts
Membre éprouvé https://www.developpez.com
Le 18/12/2014 à 10:42
Mamamia !! Si ça fonctionne bien, alors là je serais heureux !
Parce que copier coller une erreur dans google (bing ou autre) et ne rien trouver de pertinent, c'est relou ^^ alors si ça me fait économiser des minutes de recherche, pourquoi pas !
2  0 
Avatar de Washmid
Membre averti https://www.developpez.com
Le 02/04/2015 à 12:35
Pour du pur C#, je ne l'ai pas essayé personnellement mais un ami utilise SharpDevelop à son boulot, il m'a montré un peu, ça semble être un clone gratuit qui fonctionne tout aussi bien

L'avantage de VS, c'est la floppée de designers et autres outils WYSIWYG liés aux diverses technos Microsoft.

Avis personnel : ces outils sont vraiment super pour les applis... simples (ou si on maîtrise pas bien les technos sous-jacentes). Il n'y a qu'à voir les tutos VS qu'on trouve sur MSDN, c'est toujours du "cliquez ici", "sélectionnez ça". Si un dev a tendance à tout faire "from scratch", ou pour les très grosses applis (pour lesquelles on a besoin d'industrialiser le code, factoriser dans tous les sens etc.), franchement VS n'a pas grand intérêt.
6  4 
Avatar de dfiad77pro
Membre expérimenté https://www.developpez.com
Le 02/04/2015 à 13:23
Citation Envoyé par Washmid Voir le message
Pour du pur C#, je ne l'ai pas essayé personnellement mais un ami utilise SharpDevelop à son boulot, il m'a montré un peu, ça semble être un clone gratuit qui fonctionne tout aussi bien

L'avantage de VS, c'est la floppée de designers et autres outils WYSIWYG liés aux diverses technos Microsoft.

Avis personnel : ces outils sont vraiment super pour les applis... simples (ou si on maîtrise pas bien les technos sous-jacentes). Il n'y a qu'à voir les tutos VS qu'on trouve sur MSDN, c'est toujours du "cliquez ici", "sélectionnez ça". Si un dev a tendance à tout faire "from scratch", ou pour les très grosses applis (pour lesquelles on a besoin d'industrialiser le code, factoriser dans tous les sens etc.), franchement VS n'a pas grand intérêt.

Comme tu le souligne, les outils de VS sont super.

Par contre sharpDevelop n'est pas au niveau (avis personnel , ne pas tapper)

Dans mon cas je travail sur des grosses applis avec VS et Eclipse , l'IDE ne remplace pas l'architecte, mais il permet d'aller très loin.
Ce que j'ai remarqué c'est que sur éclipse on travail généralement sur des projets unitairement plus petit .
Sur VS on travail plus souvent en mode "solution".

Il ne faut pas oublier que VS est, il me semble, le plus gros logiciel de Microsoft à ce jours ( certain diront "usine à gaz" , perso je serai nuancé et je dirait "achat SSD" ! ), il gère parfois de choses qu'on ne soupçonne pas et n'est pas dédié qu'a .NET .
3  1 
Avatar de dfiad77pro
Membre expérimenté https://www.developpez.com
Le 02/04/2015 à 14:26
Citation Envoyé par Washmid Voir le message
A propos de la taille des projets, si on a beaucoup de petits projets dans VS, il suffit de modifier un commentaire pour que cet abruti recompile l'intégralité des projets qui référencent le projet modifié.

Chez nous on a une "solution" à 40+ projets... Disons qu'heureusement que la fenêtre est fermée parce que l'ordi finirait sur le parking

Si tu prends eclipse dans la même situation, bah... la compilation étant incrémentale, c'est instantané (avec un capacité de montée en charge assez bluffante)

Conclusion Eclipse est une usine à gaz pour les petits "workspace" c'est vrai, Visual Studio le devient avec les grosses "solutions", et en mille fois pire.

Tu utilise quelle version de VS ( quel type de projet)?

perso 40 projets dans une seule solution ça me semble pas correct niveau conception ...
mais je suis sûr qu'on peut les faites tourner sans soucis.

c'est comme pour éclipse tu peux configurer ça...
car en effect si t'a des contrôles et qu'il recharge le designer pour tout les documents ouverts, les perfs peuvent êtres mauvaises.

Cela dit avec VS 2013 c'est asynchrone.
2  0 
Avatar de dfiad77pro
Membre expérimenté https://www.developpez.com
Le 02/04/2015 à 15:26
Citation Envoyé par Washmid Voir le message
Une grosse appli appliquant des règles métier issues de la réglementation dans notre domaine d'activité. En gros l'appli est complexe parce que la loi française l'est, tout simplement (500 000 lignes de code + 10 MO environ de données bruttes pour du paramétrage).

Et non, malheureusement, VS n'est absolument pas capable de faire tourner ça sans soucis. Il n'analyse pas le code pour la compilation, ce qui fait qu'il doit recompiler tout le code projet par projet quelque soit la nature de la modification.

Pour les designers on ne les utilise même plus, les problèmes apparaissent dès le lancement en debug de l'appli.

Si on fait le parallèle avec Eclipse :
- la compilation est classe par classe, contrairement à VS qui la fait projet par projet.
- la compilation des dépendances ne se limite qu'au strict nécessaire, quand VS recompile tout en cascade
- VS doit packager toutes les dll pour lancer en debug, Eclipse n'a besoin que des .class
- Eclipse recompile à l'enregistrement de chaque fichier source, VS recompile avant l'exécution

En somme, dans VS, si on modifie une ligne de code dans un projet "à la base" de la solution, il nous régénère des centaines de méga de binaires.

Testé avec VS2013 c'est le même délire (même comportement, performances un peu meilleures ceci dit)

Je bosse sur une solution pour le transport de 1,2 millions de lignes (16 projets)
et j'ai pas de soucis de lenteur sur un pc moyen tout en utilisant le designer...

L'erreur faut la chercher ailleurs je pense (process de l'entreprise, application ayant mal vécus, mauvaise configuration/conception).

Les seuls soucis (réels) de perf que j'ai eu c'était avec les plugins d'infragistics..
2  0 
Avatar de micka132
Expert confirmé https://www.developpez.com
Le 02/04/2015 à 15:39
Ou sinon tu peux "décharger" les 39 projets qui ne te servent pas, et recharger ceux que tu souhaites modifier.
S'agissant d'un paramètre utilisateur ca n'aura même pas d'impact sur les autres au niveau de ton gestionnaire de source.
2  0 
Avatar de kipy4
Membre du Club https://www.developpez.com
Le 30/06/2015 à 13:51
Cette monture a l'air sympa !

J'espère qu'ils ont prévu un vrai désinstalleur ce coup-ci * rêve tout haut *
2  0