none
Quelles sont les différences entre .NET Framework 4 et .NET Framework 4 Client Profile ? RRS feed

  • Question

  • Bonjour.

    Je rencontre souvent l'avertissement suivant après une compilation en VB 2010 : Impossible de résoudre l'assembly référencé "CommonV2", car il dépend de "System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" qui ne figure pas dans le Framework ciblé actuel ".NETFramework,Version=v4.0,Profile=Client". Supprimez les références aux assemblys qui ne se trouvent pas dans le Framework ciblé ou reciblez votre projet.

    J'ai compris que je pouvais résoudre ce souci en allant dans les propriétés du projet, onglet Compiler, Options avancées de compilation... où je pouvais modifier le framework cible.

    Mais en fait je ne comprends pas pourquoi il y a deux versions du framework 4, ni pourquoi ma dll a été migrée dans une version tandis que VS2010 crée systématiquement un projet WinForm dans l'autre version.

    Merci d'éclairer ma lanterne,

    Gilbert

    vendredi 21 janvier 2011 08:32

Réponses

  • Bonjour,

    Voir par exemple http://msdn.microsoft.com/fr-fr/library/cc656912.aspx (l'idée est de se passer des fonctions qui ne sont généralement utile que sur un serveur, le framework est donc divisé en gros en une partie "cliente" qui peut s'installer seule et une partie "serveur" optionnelle).

    J'imagine pour l'instant que CommonV2 est compilé en ciblant le framework complet. Donc les applis qui l'utilisent doivent nécessaire cibler le framework complet.

    J'avais vu aussi un ou deux messages sur des contrôle tiers qui ne séparent pas bien ce qui relève de la conception (nécessite un framework complet sur le poste du développeur) et de l'exécution (qui pourrait se contenter d'un framework "client"). Dans ce cas, il est nécessaire également de cibler un framework complet en attendant que le fournisseur du contrôle restructure son code.

    En complément comme je vois que le message concerne en particulier System.Web, le décodage/encodage HTML est également disponible dans System.Net.WebUtility pour cette raison. Et comme ci-dessus, si c'est une DLL qui comporte des fonctions générales, il peut être intéressant de la séparer éventuellement en une DLL qui se contente du framework "client" et une DLL qui nécessiterait le framework complet et dont les fonctions seraient plus destinées à un serveur.


    Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".
    vendredi 21 janvier 2011 11:45
    Modérateur

Toutes les réponses

  • Bonjour,

    Quand vous distribuez une application le mieux est de faire une copie local des références et avoir une pérennité de fonctionnement au cour de sa vie.

    Donc si vous avez des références particulières clique droit propriété et copie local = true

    Si vous rencontrez trop de probleme avec le FrameWork le mieux serait de faire la deinstallation de tout les Framework et d'en refaire une propre

     

     


    Cordialement, Troxsa
    vendredi 21 janvier 2011 08:43
    Auteur de réponse
  • Bonjour,

    Voir par exemple http://msdn.microsoft.com/fr-fr/library/cc656912.aspx (l'idée est de se passer des fonctions qui ne sont généralement utile que sur un serveur, le framework est donc divisé en gros en une partie "cliente" qui peut s'installer seule et une partie "serveur" optionnelle).

    J'imagine pour l'instant que CommonV2 est compilé en ciblant le framework complet. Donc les applis qui l'utilisent doivent nécessaire cibler le framework complet.

    J'avais vu aussi un ou deux messages sur des contrôle tiers qui ne séparent pas bien ce qui relève de la conception (nécessite un framework complet sur le poste du développeur) et de l'exécution (qui pourrait se contenter d'un framework "client"). Dans ce cas, il est nécessaire également de cibler un framework complet en attendant que le fournisseur du contrôle restructure son code.

    En complément comme je vois que le message concerne en particulier System.Web, le décodage/encodage HTML est également disponible dans System.Net.WebUtility pour cette raison. Et comme ci-dessus, si c'est une DLL qui comporte des fonctions générales, il peut être intéressant de la séparer éventuellement en une DLL qui se contente du framework "client" et une DLL qui nécessiterait le framework complet et dont les fonctions seraient plus destinées à un serveur.


    Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".
    vendredi 21 janvier 2011 11:45
    Modérateur