Discussion :

[Graffito]

dfiad77pro : De faire en sorte qu'un code .NET windows marche sur linux sans aucun changement

Nous avons une application fonctionnant en Windows .net et Linux Mono.
Et ... le .exe généré sous Visual Studio fonctionne directement sous Linux
Le code source est à fortiori le même.

[Anything]

Blender est devenu payant ?

Je pense qu'il doit parler de http://fr.wikipedia.org/wiki/Expression_Blend. Blencer le logiciel 3D a pas grand chose à voir avec Microsoft.

[Akiren]

Je pense qu'il doit parler de http://fr.wikipedia.org/wiki/Expression_Blend. Blencer le logiciel 3D a pas grand chose à voir avec Microsoft.

Je pense que ça n'a rien à voir avec MS et qu'il parle bien de Blender. Il n'était pas gratuit au départ il me semble.

[clementmarcotte]

Bonjour,

Je n'ai pas relu les 3 pages, et j'espère qu'il n'y a pas de redondance, mais j'ai trouvé cela chez MS. Ils parlent de la différence entre Community et Express.

http://blogs.msdn.com/b/onecode/arch...-editions.aspx

[imikado]

Nous avons une application fonctionnant en Windows .net et Linux Mono.
Et ... le .exe généré sous Visual Studio fonctionne directement sous Linux
Le code source est à fortiori le même.

Moi j'ai le problème inverse: je développe sous mono (sous GNU/Linux) et mon exe ne fonctionne pas sous windows: l'application crash directement
J'ai essayé également d'exporter en projet visualstudio:
Et là je peux voir la quasi totalité de mes références en défaut (atk-sharp,gdk-sharp,glib-sharp,gtk-sharp...)

[Graffito]

mon exe ne fonctionne pas sous windows

Directement sous le framework .net, je suppose.

Qu'est-ce que ça donne sous Mono Windows ?
http://www.mono-project.com/docs/get...stall/windows/

[imikado]

J'ai bien sur également installé mono sur windows

J'ai l'impression que la version windows n'est pas à jour

Currently the latest Mono for Windows version is 3.2.3. We’re working on getting a more recent version released

[Lutarez]

J'ai bien sur également installé mono sur windows

J'ai l'impression que la version windows n'est pas à jour

Il est possible que VS est fait n'importe quoi avec les références vers les dll. Cela arrive parfois chez moi quand j'utilise des lib qui ne sont pas dans le GAC.
Dans VS, sur le projet, essayes de supprimer les références vers les lib en erreur, puis rajoutes-les ensuite à la main. C'est con, mais des fois, ça suffit à satisfaire VS

Pour la version, ça ne devrait pas poser de problèmes si la version du Framework que tu cibles est installée.


EDIT : seconde méthode, plus lourde et surtout très pénible : recréer un projet VS vide, y copier tes fichiers et rajouter les références.

[imikado]

Le truc bête, c'est que j'ai l'impression que les refs ne soient pas présente sur le pc (GTK# par exemple)

Mais j'essaierai demain

note: je suis passé par nugget pour essayer d'installer certaines refs, mais toutes n'étaient pas dispo

[Hinault Romaric]

Microsoft présente .NET Core
son « fork open source du Framework .NET » pour Windows, Linux et OS X

Le mois dernier, lors d’un événement en ligne, Microsoft a présenté l’avenir de sa plateforme de développement .NET et de ses outils, notamment Visual Studio 2015.

Le mot d’ordre était l’ouverture ! La firme avait annoncé qu’elle allait publier en open source le code du cœur du Framework .NET (.NET Core), sous licence MIT.

L’ambition de Microsoft est de rendre .NET accessible à un nombre plus important de développeurs, sous plusieurs plateformes, y compris Linux et Mac.

Dans un long billet de blog sur MSDN, Microsoft présente de façon détaillée ce qu’est « .NET Core », comment il sera publié, ce qu’il représente pour le Framework .NET et ce que cela implique pour le développement multiplateforme et open source.

Lorsque Microsoft avait publié .NET pour la première fois en 2002, il était disponible comme un Framework unique. Peu de temps après, plusieurs déclinaisons ont vu le jour, dont .NET Compact Framework, un sous-ensemble de .NET à destination des terminaux à faibles ressources, comme les terminaux mobiles.

Au fil du temps, plusieurs déclinaisons du Framework .NET ont été expédiées pour Silverlight, Windows Phone, et plus récemment pour le Windows Store. Cela a créé une fragmentation de .NET, qui était désormais disponible en plusieurs plateformes, gérées par des équipes différentes au sein de Microsoft.

Cela ne poserait pas de problème si les développeurs créaient des applications spécifiques pour chaque plateforme. Cependant, il est assez fréquent pour ceux-ci de cibler plusieurs dispositifs et plateformes à travers leurs applications. Cette diversité pourrait même être l’une des principales causes de la faible croissance du Windows Store, car les applications Windows Desktop, ne peuvent figurer sur le store, qui supporte uniquement WinRT.

Pour contourner le problème, Microsoft a développé dans un premier temps les bibliothèques de classes portables (portable class libraries), dont l’objectif était d'écrire et générer des assemblys managés qui fonctionnent sur plusieurs plateformes .NET Framework. Puis, la firme a dévoilé en avril dernier lors de sa conférence Build, Universal Apps, un moyen pour les développeurs de créer une seule application, qui fonctionne de façon fluide sous l’ensemble des plateformes Windows (Windows 8 et Windows Phone 8).

Mais, il s’agissait des solutions limitées et partielles. .NET Core a pour ambition d’aller au-delà, en offrant une implémentation unifiée de .NET. « .NET Core est essentiellement un fork du Framework .NET, dont le développement a été optimisé autour de ces préoccupations », écrit Microsoft. .NET Core est une implémentation modulaire, qui pourra être utilisé dans une grande variété de plateformes. Il sera soutenu par Microsoft sur Windows, Linux et Mac OS X.

.NET Core comprend un BCL (Base Class Library) unifié qui sera le même code pour toutes les plateformes. « Même si les scénarios pour NET Native (dispositifs tactiles) et ASP.NET 5 (développement Web côté serveur) sont très différents, nous avons pu fournir une bibliothèque de classes de base unifiée. », se réjouit Microsoft.

Actuellement, Microsoft propose deux implémentations du .NET Core BCL : l’une pour .NET Native et l’autre pour CoreCLR, utilisé par ASP.NET 5.0. Cependant, la majeure partie de BCL de .NET Core est commune aux deux plateformes.

Autre fait intéressant : .NET Core introduira un nouveau modèle de déploiement des applications. Il sera possible de déployer des applications .NET avec des copies des bibliothèques du Framework .NET. L’idée est de permettre aux développeurs d’importer uniquement les parties de .NET dont ils ont besoin, et les déployer avec leur application. Les bibliothèques de .NET Core seront livrées à travers le gestionnaire de paquets NuGet.

Les avantages de cette approche sont multiples. Une machine n’aura plus besoin d’une version complète de .NET Framework pour exécuter une application, car chaque application sera livrée avec son propre Framework. De plus, les mises de .NET Core ne briseront plus les applications existantes.

Le diagramme ci-dessus soulève cependant quelques interrogations puisqu’au-dessus, on retrouve uniquement « Windows Store App Model » pour les applications WinRT et « ASP.NET 5 App Model ». Qu’en est-il des applications desktop et ASP.NET 4 ?

.NET Core représente un sous-ensemble du Framework .NET, selon Microsoft. Le développement d’application desktop avec WPF ou Windows Forms continuera à se faire sous le Framework .NET et non .NET Core. Microsoft compte mettre à jour ce dernier chaque année. Il y’aura donc des fonctionnalités qui seront exclusives au Framework .NET.

Pour les développeurs qui souhaitent exécuter leur code à la fois sur le Framework .NET et .NET Core, Microsoft prévoit d’étendre les bibliothèques de classes portables pour couvrir ce cas, car pour la firme, .NET Core est « le fondement de toutes les futures plateformes .NET »


Source : MSDN


Et vous ?

Que pensez-vous de .NET Core ? Et de son ouverture par Microsoft ?

[Issam]

Personnellement j'attends avec impatience l'implémentation de .Net Native pour le Desktop qui est pour le moment que pour le store

[dfiad77pro]

En théorie c'est une très bonne chose,
cela permettra d'avoir des implémentations communes avec mono ( qui prévoit de reprendre le code).

Cela dit , le fait de gérer tout ses multiples package risques de devenir assez bordélique, à voir dans le futur.

Je comprend pour le moment qu'ils n'ouvrent pas WPF ,
car y'a déjà un gros travail à faire sur le Core.
Cela dit il faudra juger en pratique (bugs, performance , maintenance)


D'autre part tout n'est pas encore dispo, actuellement P-Linq et TPL Dataflow viennent d'être rajoutés, on attend le reste avec impatience.

Pour l'implémentation .NET native, je ne pense pas que ça s'appliquera à WPF pour le moment , y'a d'autres axes d'optimisations plus importants.

Pour la fragmentation, il faudra voir avec le .NET normal, depuis l'install du 4.6 (preview)sur ma machine de test (Windows 7)
j'ai beaucoup d'applications qui ne fonctionnent pas ( je pense que c'est dû à ryuJit )

[CeluiQuiCode]

Xamarin / Mono-project , prochain(s) rachat(s) de Microsoft ? Histoire d'aller encore plus vite pour son ouverture

[Issam]

Pour l'implémentation .NET native, je ne pense pas que ça s'appliquera à WPF pour le moment , y'a d'autres axes d'optimisations plus importants.

oui mais c'est dans leurs plans !

[Washmid]

Ça fait des années (depuis toujours?) qu'on peut faire ça en java, déployer les APIs avec les applis, avoir des binaires uniques pour toutes les plateformes, et ça pose pas vraiment de soucis (à ma connaissance).

Bon, java permet également de déployer le runtime carrément dans les exécutable ce qui ne semble pas être le cas ici.

Bref, très bonne nouvelle pour la portabilité, marre des moulinettes de "csproj" pour gérer plusieurs plateformes.

[dfiad77pro]

Ça fait des années (depuis toujours?) qu'on peut faire ça en java, déployer les APIs avec les applis, avoir des binaires uniques pour toutes les plateformes, et ça pose pas vraiment de soucis (à ma connaissance).

Bon, java permet également de déployer le runtime carrément dans les exécutable ce qui ne semble pas être le cas ici.

Bref, très bonne nouvelle pour la portabilité, marre des moulinettes de "csproj" pour gérer plusieurs plateformes.

ah et donc le projet Jigsaw pour JAVA 9 , c'est pas ça??

Java aura droit à son système de modules. Le projet Jigsaw prend forme après plusieurs problèmes techniques qui ont entraîné son report et sa réimplémentation.

Pour rappel, le projet Jigsaw vise essentiellement à découper la bibliothèque d’exécution de base de Java en différents modules. Cela devrait permettre à une machine virtuelle Java (JVM) de fonctionner sans le support de certains packages de base.

On parle de modularité au sein du core même du framework .NET

[Gugelhupf]

Bon, java permet également de déployer le runtime carrément dans les exécutable ce qui ne semble pas être le cas ici.

Les programmes Java n'embarquent pas de runtime (des projets hors du standard le permettent peut-être).
Un projet là-dessus est en cours (JEP 148).

[Olivier Famien]

Voilà que les choses avancent dans le bon sens. Ils ont compris que les dev d'aujourd'hui sont de gros "paresseux" qui ne veulent plus apprendre 1 langage pour 1 plateforme mais 1 langage pour x plateforme. Et puis à quoi ca sert une multitude de langages, si je peux faire tout et n'importe quoi avec le même langage et même sortir le chien ou me faire du thé pendant qu'on y est .
Vive le CODE (Code once deploy everywhere).

[frfancha]

Ça fait des années (depuis toujours?) qu'on peut faire ça en java, déployer les APIs avec les applis, avoir des binaires uniques pour toutes les plateformes, et ça pose pas vraiment de soucis (à ma connaissance).

Oui bon les produits d'entreprise c'est: seule le jdk a.b.c release x modifié par nos soins est supporté ==> donc on se retrouve avec des dizaines de versions sur le serveur, qui finissent par s'écraser les unes les autres du coup on fait une VM par produit avec SA version de java..

[Washmid]

Les programmes Java n'embarquent pas de runtime (des projets hors du standard le permettent peut-être).
Un projet là-dessus est en cours (JEP 148).

Tu copie colle n'importe quel runtime java sur la machine destination, puis tu lance ton programme avec définissant une variable d’environnement et ça marche (la licence de base t'autorise à faire ce genre de choses).

Sinon t'as eclipse qui permet de s'exécuter avec la JRE que t'as juste à coller en sous-répertoire.

Sans parler des compilateurs natifs qui te sortent un .exe très léger n'ayant aucune dépendance envers une quelconque JRE installée (pdf tool kit par exemple qui fonctionne de cette manière sauf erreur)

Et tout ça existe depuis au moins 10 ans. En .NET, actuellement, bonne chance ^^

@frfancha : oui effectivement si on s'amuse à trifouiller sur ce genre de chose ou à référencer des package sun.* effectivement ça peut virer au cauchemar