Ca c'est cool, merci 
De rien, tu bosse comme un malade sur la SFML, normal que de temps en temps des gens te rendent la pareil
J'aurais bien fait un unique package AnyCPU, mais je savais pas comment gérer les dépendances 32/64 bits. Du coup ça marche comment là ? Si tu m'expliques je me ferai un plaisir de convertir les projets, et de refaire une release.
C'est bien la difficulté, faire un package qui contient tout implique que tu build les dll .Net en AnyCPU et que tu fournisses les deux jeux de bitage pour les librairies natives.
C'est souvent source d'erreur pour l'utilisateur au final, d'où justement un template comme le miens qui va abstraire la préparation du livrable.
Je penses qu'il serait acceptable de garde les deux release pour pas perdre les gens mais d'inclure dans la partie librairie .Net uniquement celle qui seront considérer par Windows comme MSIL.
Après je peux pas te dire si c'est réellement une solution viable, parce que j'ai cru comprendre que le binding été compatible avec Mono, et du côté de Mono je ne sais pas comment ça se passe sous Linux et Mac OS X. Donc IMHO ça représente un risque.
Pour Windows le VSIX que je peux faire est une bonne solution de contournement, après quand je disais que le rebuild de mon côté est un frein c'est parce que c'est ta propriété intellectuel et que il n'y a pour moi que toi qui peut être garant du livrable final
.
Pour ta question sur le comment ça marche en fait c'est ultra simple.
Le binding est au final la couche d'abstration donc lui il ne doit pas dépendre d'un bitage. Quand tu développe ton application c'est là que tu spécifie ta plateforme, et donc ton binding est malléable parce qu'au build c'est uniquement les libs natives en bas niveau qui correspondent et qui vont se retrouver dans le livrable. Au final ça inclut que quand tu build dans VS tu choisit ta plateforme et c'est toute la hiérarchie qui s'adapter à cette plateforme choisit.
Résultat : Ton application à ses références sur les bibliothèques intermédiaires AnyCPU et du coup quand tu change de bitage tu n'a pas besoin de changer les références liées directement dans le projet d'application, MS Builder doit fait le taf pour toi.
Dans mon template ça marche comme ça, en fonction de la plateforme attaquée, MS Build envoie dans le dépôt du livrable uniquement les librairies qu'y correspondent au bitage de l'application et ta SFML en AnyCPU fait la passerelle sans bronché
Ensuite ça apporte quoi de passer en .Net 4.0 ? Ca a quelles implications exactement ? Moi j'avais dans l'idée que de rester sur une vieille version m'assurait d'avoir un maximum de compatibilité.
.Net 4.0 (et aussi 4.5) apporte énormément de trucs.
Déjà il faut savoir que la version .Net 3.0 et 3.5 sont basé sur la Common Language Runtime 2.0 qui est la même que pour .Net 2.0. Donc pas d'évolution technique mais un nombre de feature à gogo :
- Les méthodes d'extension : Cas classique, tu as une structure mais il manque des choses dedans. Tu peux pas hériter donc tu es bloqué. Et bien en fait non, avec les méthodes d'extension tu va pouvoir enrichir la classe sans soucis. Exemple, dans XNA la struct rectangle n'a pas de méthode Contains pour les Vector2 (uniquement pour les Points qui encapsulent du int) et bien osef pour moi je vais enrichir la classe avec une méthode d'extension :
public static bool Contains(this Rectangle rectangle, Vector2 vector)
{
return rectangle.Contains(new Point((int)vector.X, (int)vector.Y));
}
Du coup dans mon code je peux faire directement ça : myRectangle.Contains(new Vector(0.0f, 0.0f));
Ici l'exemple peut paraitre peu pertinent, mais dans de nombreuse circonstance tu bénis ce genre de possibilité
- Les expressions Lambda : Une autre feature qui si ma mémoire est bonne est dans le C++ maintenant.
Exemple :
MonObjectAvecIdentifiant o = monTableauObject.Where(x => x.Id == 1);
Ce qui en français veut dire que dans un tableau tu va aller chercher l'objet qui à la propriété Id strictement égale à 1.
Super pratique.
- Linq : The feature du 3.5 qui est une surcouche des lambdas au final.
En linq mon exemple du dessus ça donne ça :
MonObjectAvecIdentifiant o = (from o in monTableauObject where o.Id == 1 select o).First();
En gros requétage de liste object en simili Sql, par contre un peu gourmant en perf
Voilà pour les features principales du 3.5.
Pour le 4.0 moins de chose mais :
- Optimisation des performances mémoire avec une nouvelle Common Language Runtime
- Possibilité d'utiliser la programmation parallèle (et ça ça tue)
Pour le 4.5 c'est comme le 4.0 mais en encore plus performant.
Bref je penses qu'il y a vraiment un intérêt à débloquer tout ça.
Au niveau implication normalement pas d'impact (surtout que le Binding c'est de l'interopérabilité), mais comme tout il faut tester pour s'en assurer
L'auteur du template c'est toi, donc tu peux bien sûr mettre ton nom
;p ça marche je vais continuer ça dans mon coin et pointer le bout de mon nez quand ça aura plus avancé !
A++
RadicalEd
