Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Compilation versus Exécution des DLL
Bonjour,
Quelqu'un peut me dire ce qui se passe au moment de la compilation et l'exécution des DLL d'un projet avec vs2003 et vs2008 svp?
J'ai plusieurs problèmes avec un projet, car j'ai une machine physique qui utilise des dll de vs2003 et une autre machine virtuelle qui utilise des dll de vs2008. En plus, je travaille dans un endroit ou l'on peut choisir son propre environnement (Unit, Fonct, ect...) et nous utilisons plusieurs modules communs dont nous avons aucun contrôle.
Merci!
vs2003 compile sur une plateforme dotnet 2.0 uniquement car il force la compilation du projet en 2 même si dotnet 4 (full/cp) est installé.
vs2008 compile en ce que tu veux, excepté dotnet 4 (full/cp)
vs2010 compile en ce que tu veux.
Globalement quelque chose de compiler en dotnet 2.0 fonctionnera toujours même sur dotnet 4...
Simplement certaines bibliothèques/classes/méthodes ont été entre temps deprecated, mais fonctionnent toujours pour tout programme compilé avec une version plus ancienne de dotnet, même si elles ne sont plus du tout accessible sur une version plus récente.
entre vs2003 et vs2008 aucun souci d'interopérabilité, temps que l'interopérabilité se fait dans le bon sens.
si le projet est compilé en dotnet 2 sur les 2 environnement alors ils sont parfaitement interopérable, même si les 2 IDE sont différents.
si le projet est compilé en dotnet 3.5 sur le projet VS2008, alors le problème peut se poser du coté de la machine sous vs2003 si dotnet 3.5 n'est pas installé sous cette machine.
en réalité, il faut bien comprendre, que dans un environnement managé comme dotnet, tu n'est plus réellement dépendant de la plateforme, comme tu l'étais en natif.
c'est également vrai pour les versions du framework.
entre dotnet 2, et dotnet 3.5SP1 seules des librairies supplémentaires ont été ajoutées, mais la CLR n'a pas changée.
cela signifie qu'un programme exécuté sur dotnet 3.5 est exactement exécuté de la même façon qu'un autre écrit en dotnet 2.0. Bien entendu un projet dotnet 3.5 nécessite le framework 3.5 pour fonctionner, car 3.5 ajoute une panoplies de technologies, de namespaces, de librairies supplémentaires par rapport à dotnet 2.0
la version du framework disponible sur la machine, est totalement indépendante du visual studio installé et utilisé.
ainsi tu peux très bien avoir dotnet 4 sur une machine avec VS 2003 et faire du dotnet... cela fonctionne, la différence, c'est que les produits écrit avec VS2003 seront forcément en dotnet 2.0 car :
1. VS2003 ne permet pas de régler la version ciblée, toujours fixé à dotnet 2.0
2. VS2003 ne reconnait que C# 2.0 et pas des versions plus récentes du langage.
attention toutefois, certaines technologies dont les écritures font parties intégrantes du langage, ne sont pas disponibles sous vs2008 si tu compile en dotnet 2.0...
c'est notamment le cas des écritures Linq, et par conséquent des méthodes d'extensions fournies par Linq, et des Lambda expressions, car le moteur de gestion des lambda, a été intégré avec Linq.
Euh ... non, VS 2003 compile sur une plateforme .NET 1.1, pas 2.0.Envoyé par cinemania
C'est VS 2005 qui compile sur 2.0 (ou 3.0).
Oui, mais pour .Net 2.0, c'est au moins VS 2005 pas 2003si le projet est compilé en dotnet 2 sur les 2 environnement alors ils sont parfaitement interopérable, même si les 2 IDE sont différents.
Non : 1.1cela fonctionne, la différence, c'est que les produits écrit avec VS2003 seront forcément en dotnet 2.0 car :
Il me semble qu'on peut utiliser certaines extensions langage du C#3.0 en VS 2008 en compilant pour le fw .Net 2.0 car c'est juste un pre-processing du compilateur non lié au framework (la CLR restant en 2.0 avec le framework 3.5, et si tu choisis le framework 2.0 en VS2008 tu restes dans tous les cas avec le compilateur C# 3.0, qui gére par pre-processing les extensions spécifiques du langage mais génére un IL en 2.0).attention toutefois, certaines technologies dont les écritures font parties intégrantes du langage, ne sont pas disponibles sous vs2008 si tu compile en dotnet 2.0...
c'est notamment le cas des écritures Linq, et par conséquent des méthodes d'extensions fournies par Linq, et des Lambda expressions, car le moteur de gestion des lambda, a été intégré avec Linq.
pardon pour l'erreur de version du framework, effectivement c'est la version 1.1...
pour ce qui est des extensions du langages, oui certaines constructions spécifiques à C# 3 sont utilisables même si tu compile en fw2.0, mais aucunes de ces constructions liées à une technologie introduite dans le fw3 ou 3.5...
cela signifie par exemple que les extensions Linq, et toutes les écritures qui en découlent sont impossibles.
je ne suis même plus sure qu'il soit possible, de définir soit même des méthodes d'extensions, pourtant élément quasi indispensable de C# 3.0... lorsqu'on compile sous fw2.0... car si mes souvenirs sont bon, même les méthodes d'extensions découlent indirectement de Linq.
le problème c'est que nombre des nouveautés de C# 3, on les doit notamment à l'introduction de Linq...
le cas est sensiblement le même avec C# 4... que tu compile en fw3.5SP1 ou 2.0 le constat sera le même...
les dynamic sont inutilisables car ils dépendent d'une technologie et d'une librairie introduite en .NET4.0 et également d'une modification au niveau de la CLR...
d'ailleurs le problème est le même entre fw 1.1 et fw 2.0 et notamment les generics.
90% des innovations introduites dans C# 2.0 sont indisponibles si tu compile en dotnet 1.1.
en revanche il est vraie que des écritures comme celles-ci
très utilisées maintenant, sont possibles, avec la bonne version de C#, même si tu compile pour le fw 1.1... car ces 2 écritures ne résulte pas d'une nouvelle technologie, mais bel et bien d'une pure évolution du langage.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
d'ailleurs cette amélioration ne dépend pas non plus d'un changement de la CLR...
je rappel d'ailleurs que la première écriture nécessitait clairement d'instancier un délégué, alors que là, c'est fait de façon automatique.
Tout à fait d'accord.
Non , les méthodes d'extensions ne sont pas utilisables en 2.0 car si c'est un "syntax sugar" qui ne dépend que du preprocessing du compilateur, il nécessite l'ajout de la classe ExtensionAttribute qui fait partie du framework 3.5.je ne suis même plus sure qu'il soit possible, de définir soit même des méthodes d'extensions, pourtant élément quasi indispensable de C# 3.0...
C'est un peu l'inverse : c'est Linq qui nécessite les méthodes d'extensions.lorsqu'on compile sous fw2.0... car si mes souvenirs sont bon, même les méthodes d'extensions découlent indirectement de Linq.
En effet, dans le cas de C# 4.0 on a une évolution IL + CLR.le cas est sensiblement le même avec C# 4... que tu compile en fw3.5SP1 ou 2.0 le constat sera le même...
les dynamic sont inutilisables car ils dépendent d'une technologie et d'une librairie introduite en .NET4.0 et également d'une modification au niveau de la CLR...
En effet, dans ce cas, c'est une problématque similaire à celle du 4.0; entre le 1.1 et le 2.0 on a eu aussi une évolution IL + CLR.d'ailleurs le problème est le même entre fw 1.1 et fw 2.0 et notamment les generics.
Merci d'avoir pris le temps de me répondre!
Répondre avec citation
Partager