Reprise du message précédent :
Après le rachat de Xamarin par Microsoft, on va bientôt avoir une stack Microsoft complète sous Linux: http://arstechnica.com/information [...] -mid-2017/

Ah non, ça sera complet que quand ils auront aussi sorti Visual Studio for Linux . Mais super nouvelle sinon pour SQL Server

C'est vrai, je pensais plus au framework .net qu'aux outils de dev

Oui j'avais bien compris t'inquiète . Non mais c'est clair que c'est déjà beaucoup ! Et merci d'avoir posté la news !

A propos, ça évolue encore monodevelop ou c'est la même bouse qu'en 2010 qui sert juste à dire "mais si, on a un IDE !" ?
Parce qu'après 40 clics depuis le site officiel (sans rien télécharger) je ne suis pas avancé :
http://www.monodevelop.com/archive [...] s/roadmap/ : dernière version de 2010
Oui mais :
http://www.monodevelop.com/documentation/
Qui te renvoie sur github :
https://github.com/mono/md-website
sauf que c'est le github du site web et pas de l'ide, super, des fois que je voudrai contribuer au site web
Cela dit, tout près il y a :
https://github.com/mono/monodevelop haha !!
et donc : https://github.com/mono/monodevelop/releases
Et puis aussi, en m'interrogeant sur ces versions 5 et 6 : http://wiki.dlang.org/Mono-D_Release_Notes ?
Mais pourquoi rien de tout ça n'est sur le site officiel alors ?

 
https://blogs.msdn.microsoft.com/vi [...] oundation/

J'ai juste survolé mais à première vue rien à voir avec VS lui même, c'est plus le support TFS et tout ça qui sera étendu à d'autres systèmes.
 
A moins que MS ne porte Visual Studio sous Eclipse

 
Ba faut avouer que personne fait de .Net sous linux, donc c'est pas forcement intéressant de maintenir le truc
Après de ce que je sais, le framework mono lui continue d'évoluer indépendamment de l'IDE (grâce à Xamarin entre autres)
 
D'ailleurs, l'IDE Xamarin te permet de faire du .NET sous MAC.
 
Après, peut être qu'avec le rachat de Xamarin par MS et leur envie de vouloir s'étendre au monde Linux amenera un nouvel IDE ( ou l’adaptation de Xamarin sous linux ) qui sais    

 
Je pense que ca montre une volonter de MS d'aider au development d'un vrai IDE sous Linux, ce qui a du sens vu leur politique actuel

C'est clair, ça fait plusieurs années qu'ils sont dans cette mouvance, l'IDE c'est sans doute leur prochaine grande étape.
Ca serait cool, ça m'inciterait peut être enfin à me (re)mettre à Linux

Sachant que mono est distribué sous Linux (genre Debian), c'est qu'il y a un public pour l'utiliser
Ou pour aller plus loin, sachant que mono a été développé, c'est qu'il existait une demande pour avoir .NET sous Linux

 
+1
 
Bon, Mono j'ai laché l'affaire il y a bien 5 ans maintenant.. pas assez performant malgré une compatibilité plutôt satisfaisante..
 
Je sais pas s'ils ont amélioré le truc depuis

 
Quand j'ai dit personne c'est une "expression", je pense juste que la communauté n'est pas assez active .

En même temps la réticence est facile à expliquer, si tu vas dire "Microsoft" chez un pro linux y a des chances qu'il te vomisse sur les pompes.  
Du coup c'est pas eux qui vont réclamer

Il y a les pro Linux, et les pro Productivité.
J'ai croisé pas mal de monde qui switch d'un environnement à un autre, je suis moi même un ancien Linuxien (toutes mes machines sous Linux chez moi pendant des années)
Mais aujourd'hui, les pro Linux, je n'en veux pas dans mes équipes et nous sommes nombreux dans ce cas. Il faut de l'ouverture d'esprit bordel §§
 
/coup de gueule
/marre de faire du vb6

 
 
 
Mon programme utilise un DLL (reportviewer 12 ) , il est en copie local dans le rep de sortie mais c'est la version intergrée a windows qui est utilisée, et donc parfois il ne le trouve pas ( pour differentes raisons, )
 
 y'a moyen de le forcer a utiliser le DLL local ?  

Specific Version=true + numéro qui va bien ?

PS : http://stackoverflow.com/questions [...] in-the-gac

Je vais essayer de répondre sans dire trop de conneries (corrigez si besoin)
Par défaut, l'ordre de chargement est le suivant :
* Global assembly cache (GAC)
* Chemins déclarés dans l'AppDomain
* Le répertoire d'exécution courant

Tu peux forcer l'utilisation de la version courante de ta DLL déclarée dans le projet (dans les références Specific version = true), si cette version n'est pas présente dans la GAC, ça sera basculera sur le répertoire local d'exécution.

Une solution alternative, sera de charger manuellement ta DLL.
Sinon je pense qu'il y a peut-être un truc à regarder du côté des noms partiels vs complets des assemblies

EDIT:   , je suis trop lent à répondre

merci, vous etes adorables messieurs

Mais toi tu as pris le temps de rédiger pour expliquer
Pour l'ordre exact je ne me risquerai pas à te contredire, je ne me souviens pas mais ça me parait cohérent . Par contre il doit y avoir encore un ou deux autres endroits où il cherche.

Pour info tu peux activer les logs d'assembly binding pour voir les détails exacts de la résolution d'assembly, parfois on a des surprises d'ailleurs

En dernier recours, il y a :
:\Windows\Sytem32
:\Windows
:\Windows\Sytem

Pour les logs d'assembly binding : attention à bien les désactiver après utilisation !! j'ai déjà vu des serveurs tomber à cause de ça => ça peut générer des 100ene de Mo en quelques minutes (voir secondes si de nombreuses applications .Net sont hébergées sur la machine)

C'est clair, c'était *juste* le temps de vérifier ce qui se passe que je conseillais ça, parce que parfois la situation n'est pas aussi évidente qu'elle le semble pour -the_unforgiven-, merci pour la précision.
Genre ta foutue DLL est là, un peu partout, mais ton appli ne veut jamais la charger pour une raison très obscure.

A propos de ces fameux logs pour en dire un peu plus, le plus simple pour les voir et les activer est de passer par FUSLOGVW.exe
"C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\x64\FUSLOGVW.exe" ou à peu près n'importe où ailleurs selon votre version de Windows et du framework, c'est le nom de l'EXE qui compte.

Sinon ça se passe dans le registre pour l'activation et dans un endroit totalement improbable (les fichiers temporaires d'IE) pour la lecture, c'est chiant.

 
Merci !! Moi qui me suis toujours emmerdé à aller manipuler la BDR !!! Ca va me faire gagner du temps ça

mais bordel, pourquoi j'ai jamais cherché si une IHM permettait de faire ça...

Y a un million de supers outils dans le SDK Windows (sysinternals suite), dans le framework .Net et pour IIS (IIS 6.0 Resource Kit, Web Platform Installer...) mais faut vraiment se casser la tête pour découvrir qu'ils existent vu que c'est plein de petits EXE mystérieux et planqués. Après tu peux plus t'en passer.
C'est dommage que ça ne soit pas mieux documenté

petit retour sur mon probleme
le Specific Version etait deja sur true, alors je l'ai mis a false et ca a marché

j'ai besoin de la version 12 du DLL, mais en etait sur true il cherche la 11 ... il decide de lui meme de la version, j'ai pas tout compris
au niveau du code je ne demande rien de special, je ne fais qu'importer

Edit : en fait non ca ne marche toujours pas -_-

la version est définie au moment ou tu ajoute ta DLL au projet. Va bien chercher ta dll manuellement et non pas dans la liste par défaut

Tu es sûr que la version dans ton répertoire est ok ? (32/64 bits, etc) ?
La DLL "incluse" dans le projet est vraiment vraiment exactement la bonne ?
En debug ça foire aussi ?
tu as tenté d'activer l'assembly binding log comme je suggérais pour voir ce qu'il fait concrètement en allant chercher ta dépendance ?

Ce binding log est un truc magique !

j'y vois que mon pb a un peu evolué, il est question d'un autre DLL.  Je vais analyser tout ca

pour info, ca marche partout sauf sur win7 pro et certain win server

La piste du 32/64 bits est peut etre la bonne alors  

tu ne serais pas avec une appli utilisant de multiples AppDomain par hasard ?

Salut les gens,
 
Y'en a ici qui implement des strategies de cache sur leur apps ? (web app)
 
Je bosse sur une legacy webapplication avec de nombreuses donnees diverse et complexe. Pas du "Big Data" mais beaucoup de cas business complexes et de croisement de donnees
 

Les rares fois où j'ai eu à faire avec du cache de données niveau application dans mes web apps, c'était toujours géré en variables de session avec une auto expiration (il y a un CacheManager tout fait il me semble dans .NET pour ça), ou, à la main, avec de bêtes cookies.

L'idée est de checker qu'une clé (statique, par exemple, une chaine de caractère constante dans une classe statique) était enregistrée au magasin (= en session). Si non, alors on get les datas, on les ajoute au store avec la dite clé pour une certaine période. Si oui, alors on get simplement les datas dans la session plutôt qu'en base de données / webservice / whatever.
Il faut aussi gérer l'expiration de la validité.
Mais vraiment, je ne me souviens pas avoir déjà eu à le faire, donc ça doit être prévu nativement dans un objet .NET

EDIT : Attention, je ne parle pas ici du cache de données, assuré, par exemple, par EntityFramework, et qui se charge de réduire la charge côté serveur de base de données

Hey
 
Désolé de remettre ça sur le tapis
J'ai pris le temps d'observer un peu ce qui se fait en terme d'accès aux données avec les UWP, toujours dans le contexte de ma petite appli universelle.
D'après ce que j'ai lu ici et là, il semble, en effet, que Microsoft tende à privilégier l'utilisation de fichiers de données SQLite pour la partie DB, comme ce que vous m'aviez préconisé il y a quelques mois.
Jusqu'à maintenant, j'étais un peu réticent, ayant toujours eu l'habitude et préféré utiliser ce bon vieil Entity Framework...
 
Et bien apparemment, quelqu'un a entendu ma prière, et il est maintenant possible de faire de l'UWP, avec un fichier de données SQLite, en utilisant Entity Framework, le tout en code first, avec les DB migrations
C'est rendu possible par EF 7 rc1 apparemment, et c'est super simple à mettre en oeuvre. Il n'y a AUCUN SDK à installer pour SQLite, aucune création à faire, tout est géré par les data migrations côté DB.
Côté appli, on a plus qu'à repartir en terrain connu, avec du DBContect, du .SaveChanges() etc etc
Faut juste bien penser, comme toujours en code first, à bien ajouter ses DbSets dans la classe de contexte db, quand on ajoute une nouvelle entité, mais ça s'arrête là.
Comme on joue avec EF, les contraintes / clés étrangères / relations, sont très faciles à gérer, lazy loading oblige (on s'en fout au pire, on est sur un fichier local...)
 
Autre énorme avantage : ça rend le tout compatible avec un design MVVM bien plus propre que le tout-en-un que j'avais utilisé dans le tuto précédent.
On doit pouvoir saupoudrer tout ça d'une jolie injection de dépendance, pour ne pas avoir à se coltiner des "Using DBContext" sans arrêt, mais je n'ai pas encore creusé de ce côté
 
Lien d'un tuto pour mettre tout ça en oeuvre : http://docs.efproject.net/en/lates [...] arted.html

pas de driver sqlite ?  
géré nativement ? enfin ?

En fait, il semble suffire d'installer un unique package NuGet dédié (EntityFramework.SQLite), c'est probablement lui qui contient directement le provider. Le tuto fait aussi installer EntityFramework.Commands, probablement pour rendre le tout compatible avec les data migrations
Il y a 2 ou 3 petites astuces à modifier dans les fichiers de config de la solution (une app UWP ici), mais rien lié au SQLite.
A mon avis, ça sent bon l'intégration globale à EF 7 final
 
Sinon je n'ai rien eu d'autre à installer sur ma machine
Code First oblige, je n'ai même pas eu à créer de fichier .SQLite de départ, m'obligeant à installer un SQLite Browser

Oui avec l'EF7 le provider sqlite est maintenant natif, théoriquement plus besoin de se battre pendant 2j avec System.Data.Sqlite pour que ça marche vaguement.
Par contre vla les prérequis pour faire tourner EF7 (alias EF Core 1.0 pour reprendre leur nouvelle nomenclature à la con), on sent bien la technologie de rupture...

Ces jours-ci je suis sur un contrôle Winform (oui c'est archaïque) pour générer des graphiques bien compliqués, je suis tombé sur un tuto très sympa pour le support du double buffering et quelques autres infos intéressantes http://inchoatethoughts.com/custom [...] -buffering  

Visual Studio Code 1.0 est sorti.
https://code.visualstudio.com/
Editeur de texte avancé gratuit, compatible Windows, Linux, OS X, et avec un beau troupeau de plugins divers...

C'est vachement repompé de Sublime Text/Atom, quand même
J'avais rapidement testé la version précédente en janvier, j'avais pas été convaincu.

Innover sur un truc comme un éditeur de texte c'est pas forcément évident en même temps
Quels étaient tes griefs ?

Spa tellement innover, ils ciblent clairement le côté "éditeur de code pour les devs front end", donc HTML/JS/CSS et tout le toutim. Ils sont au niveau de leurs "concurrents", Atom et Sublime, mais j'attendais une meilleure intégration des outils "standards" du web : Node, Gulp, Angular, React... certes, y a des trucs dispo via des extentions m'enfin spa la folie non plus.
Typiquement, un truc comme "lancer le build Grunt/Gulp puis lancer l'appli derrière avec Node", l'offrir de base aurait été vraiment bien.
Idem pour les préférences : vas-y, édite tes prefs en JSON... pour un truc MS, c'est limite
Le truc vraiment bien, c'est IntelliSense pour JavaScript. C'est réactif et complet, de ce que j'ai pu en voir c'est cool

Au final, je trouve qu'ils auraient pu aller plus loin dans plein d'autres domaines. L'éditeur de texte ++ multi-OS qui a des possibilités infinies grâce à son système de plugins, c'est vu et revu, VS Code n'apporte pas grand-chose.