Discussion :

[torb500]

Bonjour à tous,

J'ai un souci :
Je développe une application asp.Net (je sais qu'il y a un forum dédié mais la question concerne uniquement la partie c# et .net).
Cette application doit pouvoir se connecter à une imprimante à distance, pour cela, j'ai choisi d'utiliser Google Cloud Print, j'utilise donc une bibliothèque de classes pour me simplifier la vie.
Bibliothèque de classes

Le souci est que mon application tourne sous le framework 4.0 alors que l'assembly tourne elle sous la version 4.5.2.
Si je référence la bibliothèque dans un projet dans la même version que l'assembly, ça marche, normal.

J'ai cru comprendre dans une vidéo que l'application peut supporter des versions inférieures mais pas des versions supérieures, n'y a-t-il pas de moyen de contourner cette limite? j'ai entendu parler de :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<supportedRuntime version="v4.0.50727"/>

Est-ce une bonne piste? est-ce déprécié?

Sinon je vois deux solutions mais qui ne me plaisent pas :
Traduire tout le code de l'assembly pour le faire tourner sous la version 4.0
Passez mon application sous la version 4.5.2 de .net mais là je pense que c'est pas une mince affaire, à moins que je ne me trompe?

Merci de votre aide!
Nico.

[François DORIN]

Passez mon application sous la version 4.5.2 de .net mais là je pense que c'est pas une mince affaire, à moins que je ne me trompe?

Généralement, c'est justement une mince affaire. Les frameworks .Net assurent une compatibilité descendante. Si ton code marche en 4.0, il marchera quasi à coup sur en version 4.5.2. La seule source d'incompatibilité que je vois est l'utilisation de nom qui sont devenus des mots-clés avec le Framework 4.5 (au hasard, async, await). Mais hormis cela, et à moins d'avoir des choses très exotiques, le changement de version sera indolore.

A noter par contre que dans l'autre sens (descendre de version) ce n'est bien évidemment pas vrai !

[torb500]

Généralement, c'est justement une mince affaire. Les frameworks .Net assurent une compatibilité descendante. Si ton code marche en 4.0, il marchera quasi à coup sur en version 4.5.2. La seule source d'incompatibilité que je vois est l'utilisation de nom qui sont devenus des mots-clés avec le Framework 4.5 (au hasard, async, await). Mais hormis cela, et à moins d'avoir des choses très exotiques, le changement de version sera indolore.

A noter par contre que dans l'autre sens (descendre de version) ce n'est bien évidemment pas vrai !

Tout a l'air de fonctionner en 4.5.2 effectivement, je n'ai rien non plus à modifier sous IIS? il n'y a pas d'erreur apparemment mais ça me parait louche, comment un pool .net 4.0 peut-il faire tourner une application en 4.5.2?

En tout cas merci beaucoup, je marque la question comme résolue

Bonne soirée, Nico.

[François DORIN]

Tout a l'air de fonctionner en 4.5.2 effectivement, je n'ai rien non plus à modifier sous IIS? il n'y a pas d'erreur apparemment mais ça me parait louche, comment un pool .net 4.0 peut-il faire tourner une application en 4.5.2?

Ca marche, car il y a une différence subtile. Un pool d'application ne fait pas référence à une version de Framework .Net, mais à la version du CLR (Common Language Runtime). En gros, la VM qui fait tourner les programmes .Net. Le Framework 4.5 est simplement une évolution de la bibliothèque standard. Le CLR n'a pas été modifié et est donc le même que l'on utilise le Framework .Net 4.0 ou .Net 4.5

[torb500]

Ca marche, car il y a une différence subtile. Un pool d'application ne fait pas référence à une version de Framework .Net, mais à la version du CLR (Common Language Runtime). En gros, la VM qui fait tourner les programmes .Net. Le Framework 4.5 est simplement une évolution de la bibliothèque standard. Le CLR n'a pas été modifié et est donc le même que l'on utilise le Framework .Net 4.0 ou .Net 4.5

Ok merci beaucoup!