Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Atteint de JavaScriptite Aiguë [Cyril Durand]

Expert ASP.net Ajax et WCF, Cyril Durand parle dans son blog de point techniques sur ASP.net, ASP.net Ajax, JavaScript, WCF et .net en général. Cyril est également consultant indépendant, n'hésitez pas à le contacter pour de l'assistance sur vos projets

Actualités

  • Blog de Cyril DURAND, passionné de JavaScript, Ajax, ASP.net et tout ce qui touche au developpement Web Client-Side.

    N'hésitez pas à me contacter pour vos projets .net : architecture, accompagnement, formation, ...

    View Cyril Durand's profile on LinkedIn
    hit counters


    Expertise Commerce server et BizTalk

ASP.net 3.5 SP1 : Could not load type 'System.Web.UI.ScriptReferenceBase'

Après publication de votre site web vous obtenez l'erreur suivante :

"System.TypeLoadException: Could not load type 'System.Web.UI.ScriptReferenceBase' from assembly 'System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'."

Cette erreur provient du SP1 de .net 3.5. Vous avez installé le SP1 sur votre machine de dev/déploiement puis publier le site web à partir de cette machine afin de le déposer sur le serveur ne possédant pas le SP1.
Pour corriger cette erreur, il faut installer le SP1 du framework 3.5 sur le serveur : Download : Microsoft .NET Framework 3.5 Service Pack 1

Mais d'où provient cette erreur ?

Dans votre site web, vous vous servez du ScriptManager afin d'insérer vos propres fichiers JavaScript, vous avez donc quelque chose ressemblant à :

<asp:ScriptManager runat="server"> <Scripts> <asp:ScriptReference Path="~/js/myfile.js" /> </Scripts> </asp:ScriptManager>

Lors de la publication du site web, vous avez la possibilité de cocher la case "Allow this precompiled site to be updatable", si vous la décochez (ce que je vous conseille) la publication va compiler les .aspx vers une assembly. La ligne du ScriptReference du contrôle ci-dessus va alors être traduite en ce code :

[DebuggerNonUserCode] private ScriptReference __BuildControl__control6() { ScriptReference reference2 = new ScriptReference(); reference2.set_Path("/WS/CSWS.asmx/js"); return reference2; }

Le SP1 de .net 3.5, amène une nouvelle classe : CompositeScriptReference. Cette classe permet d'utiliser le "script combining" une nouvelle fonctionnalité du ScriptManager permettant de regrouper plusieurs fichiers JavaScript en un seul. Cette classe a donc des fonctionnalités très proches du ScriptReference il est donc logique que ces deux classes partagent un parent commun, le SP1 a donc rajouté la classe ScriptReferenceBase.

image 

Si vous n'avez toujours pas vu le problème, regardons le code MSIL du code ci-dessus :

ldstr "/WS/CSWS.asmx/js" callvirt instance void [System.Web.Extensions]System.Web.UI.ScriptReferenceBase::set_Path(string)

On comprend maintenant pourquoi si l'on publie un site web à partir d'une machine possédant le SP1 de .net 3.5, ce site web ne fonctionne plus sur une machine ne possédant pas le SP1.

Bug ou pas bug ?
Je n'arrive pas à me décider, je ne trouve pas normal que la mis en place du SP1 sur la machine de dev entraine ce genre de problèmes, mais je ne vois pas d'autres solutions.

Et vous qu'en pensez vous ? bug ou pas bug ?

Posted: jeudi 14 août 2008 17:31 par cyril
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :

Commentaires

FREMYCOMPANY a dit :

Je dirais plutôt évolution... Les choses évoluent et cela cause parfois des problèmes de rétro-compatibilité. De là à dire que c'est un bug...

# août 14, 2008 19:14

findufin a dit :

Je vote pour bug ! entre une même "version" de framework (sp différent), il devrait au moins y avoir une compatibilité binaire. Mais bon on a déjà vu des différences de comportement notables entre 2.0 et 2.0 sp1, c'était déjà tout autant des bugs... Résumé, faut tout le temps faire attention aux version + sp + patch + windows update etc sur les serveurs de production...

# août 14, 2008 20:26

Erebuss a dit :

Un SP n'est pas  une même version .. même mineure.

Il corrige des bugs (tous les hotfix) et peut ajouter des fonctionnalités (ce qui est le cas ici)

Et si pour des questions de maintenance, il faut éviter la rétrocompatibilité, il ne faut pas hésiter.

Ton problème décrit est présent dans les notes. Tu imagines que si il avait couvert ca pendant plusieurs versions, quand ils auraient du faire le ménage, ils se seraient pris des :

Mais pourquoi vous ne l'avez pas fait plutot ... ca fait des dizaines de version que cela fonctionne ainsi blablabla.

Puis, faut pas oublier que les versions de Framework ne suivent plus les versions de CLR &amp; Co ... donc forcement on s'y perd ... et un changement comme un simple SP sur une version du FX peut signifier une mise à jour complete de la mécanique en dessous.

Et comme m'a dit un vieux monsieur  qui faisait du PERL alors ...

Machine de DEV &amp; Machine de PROD doivent être dans les memes conditions (même versions)

Si tu veux tester, il y a les machines de TEST. ;)

En tout cas, c'est bien que tu fasses la remarque, au moins avec l'indexation de ton blog, cela évitera pas mal de souci à ceux qui ne lisent pas les notes associées à une nouvelle version.

Bon Weekend :)

# août 15, 2008 00:14

cyril a dit :

Je n'arrive pas à me decider si c'est un bug ou non, pour moi ce n'est pas vraiment un bug et microsoft n'avait pas le choix, mais j'aurais bien aimé qu'un SP (qui n'est rien d'autres qu'un gros patch) ne casse pas la compatibilité. Si ca aurait été une nouvelle version genre .net 3.5.1 alors je ne me serais meme pas posé la question ... mais microsoft est sa politique de versionning.

Je n'ai rien trouvé mentionnant ce problème, si tu as des infos officiel de la part de Microsoft, je veux bien les avoir.

J'ai justement bloggé pour ne pas galerer trop longtemps sur ce problème. J'ai eu ce problème juste après le SP1 donc facile à detecter, mais on peut très facilement imaginer avoir le problème 1 mois après avoir appliqué le SP1 sur sa machine et ce genre de bug est pas facilement explicable ...

# août 15, 2008 01:26

Martillo a dit :

Betrand LeRoy dit: "This will happen with any dll that uses ScriptReference and that was compiled against SP1. The Control Toolkit can be recompiled against 3.5 to work around the issue if the server can't be upgraded." (http://www.codeplex.com/AjaxControlToolkit/WorkItem/View.aspx?WorkItemId=18545)

Voir aussi:http://www.codeplex.com/AjaxControlToolkit/WorkItem/View.aspx?WorkItemId=18545

# octobre 15, 2008 05:59
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Merci par Blog de Jérémy Jeanson le 10-01-2019, 20:47

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01