Discussion :

[abasourdix]

Bonjour,
J'ai migré mon appli web qui fonctionne parfaitement du framework 4.0 au framework 4.5.
Et là, bardaf, c'est l'embardée.

Mes pages basées sur un masterpage renvoient :
La collection Controls ne peut pas être modifiée, car le contrôle contient des blocs de code (c'est-à-dire <% ... %>).

Je résous le problème en changeant dans le web.config
<pages validateRequest="false" controlRenderingCompatibilityVersion="4.0" clientIDMode="AutoID"/> en
<pages validateRequest="false" controlRenderingCompatibilityVersion="3.5" clientIDMode="AutoID"/>.

Cette valeur avait en effet été changée automatiquement par vs2012 lors de la migration

Mais cette solution sonne trop bricolage à mon gout et ne me convient pas.
Quelqu'un aurait une piste où chercher ?

merci

[Immobilis]

Salut,

J'ai migré mon appli web qui fonctionne parfaitement du framework 4.0 au framework 4.5.

Comment as-tu réalisé cette migration?
Une solution VS2010 doit être migrée pour être ouverte avec VS2012. Pour autant, cela ne veut pas dire qu'elle peut être développée sur le FW 4.5.

Ce n'est pas vraiment du bricolage.

A+

[abasourdix]

bonjour,
j'avais déjà fait migrer vers VS2012 depuis quelques mois en ouvrant ma solution avec VS 2012, justement. Mais elle était toujours en .NET 4.0

Là, j'ai juste voulu passer en framework 4.5 pour éventuellement profiter des nouvelles fonctions d'asynchronisme. Je suis passé par les propriétés du projet > Application > framework cible.

Cette modification a engendré des modification de mon edmx apparemment, mais aussi du web.config plus divers fichiers de ressources ainsi que le reférence.cs

Mais, je n'ai pas de problème à la compil. juste à l'éxécution.


J'ai un peu galéré avant de trouver l'astuce qui consistait à changer controlRenderingCompatibilityVersion="4.0" en "3.5", parceque évidement, en repassant au fmrk 4.0, ces modifications automatiques n'étaient pas annulées. (Merci Winmerge)

Le problème est que je ne maîtrise pas les conséquences de ma rustine. Qu'est ce que je perds ?
Et surtout, d'où ça peut bien venir et comment je peux corriger ça ?

en tout cas, merci pour la réponse

[vanquish]

Je ne vois pas en quoi ta modification te contrarie.

L'ancienne transformation des ID C# en ID HTML construisait systématiquement des id HTML à rallonge (surtout dans le cas de MasterPage) dans le but d'éviter les conflits.

Par défaut asp.net essaie désormais de générer des id plus concis.

Sauf erreur de ma part, ces id client n'ont d'importance que dans le cas de manipulation en javascript coté client (ce qui va être le cas de certains contrôles ASP.net évolués d'éditeur tiers).

La solution la plus simple et la plus radicale est celle consistant à changer le controlRenderingCompatibilityVersion dans le web.config.

Mais il est possible de faire un réglage plus fin au niveau de chaque page et même chaque contrôle grâce à la propriétés ClientIDMode.

Il en existe 3 : l'ancien (AutoID), le nouveau (Predicable) et Static (où id c# == id html / très pratique mais attention aux conflit).

http://msdn.microsoft.com/fr-fr/libr...entidmode.aspx

exemple :

Code :

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

<%@ Page Title="" Language="C#" MasterPageFile="~/MasterPage.master" ClientIDMode="Predictable" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %>

Il n'y a donc pas de solution unique.
Tout dépend de la nature et de la taille de ton projet.

Cette nouvelle génération d'id, créée une incompatibilité.
Donc même si cela fait bricolage, il faut la gérer à un niveau ou un autre (globale ou ponctuelle) : il n'y a pas de miracle.

Cordialement

[PascalL67]

Bonjour,

Pour information, ouvrir une solution VS2010 dans VS2012 ne demande pas de migration. Les fichiers sont compatibles entre les deux versions et il est même possible de revenir en arrière (par exemple travailler avec 2012 et ensuite ouvrir le projet dans 2010).

Pascal