Expériences

Expérience

SQL 2008R2 + SP2 + SP3 = RB3 Echec

Le problème

Un client avait une plateforme SharePoint 2010, avec un Service de Reporting (SSRS) sous SQL Server 2008R2… Il avait décidé d’appliquer le SP3 pour bénéficier du support étendu. Les grands utilisateurs n’avaient pas pris le temps de tester dans les environnements d’intégration et de préproduction (ne me demandez pas pourquoi, je n’étais pas encore en prestation et je ne veux pas le savoir).

Malheureusement, en cas d’installation du SP3 par-dessus le SP2 de SQL SERVEUR 2008R2, le logiciel ReportBuilder fourni par SSRS ne peut plus se déployer sur les postes clients via ClickOnce.

Démonstration

Si on lance la modification d’un rapport via l’interface web… ClickOnce vérifie les dépendances requises pour lancer et installer si besoin l’application “ReportBuilder”…

Et c’est donc le drame… cela échoue… “Impossible de démarrer l’application” – “Echec de la validation”.

Plus de détails…

Le message d’erreur (dans les détails) est plutôt explicite :

« File, Microsoft.ReportingServices.ComponentLibrary.Controls.dll, has a different computed hash than specified in manifest. »

Il y a donc un problème avec le fichier Microsoft.ReportingServices.ComponentLibrary.Controls.dll que l’application (ClickOnce) voudrait bien déployer car la version de la dll spécifiée dans le manifeste est différente de celle effectivement présente dans le répertoire de déploiement…

Le fichier fourbe en question se trouve dans le répertoire :

[…]\Microsoft SQL Server\MSRS10_50.MSSQLSERVER\Reporting Services\ReportServer\ReportBuilder\RptBuilder_3

Voici ses propriétés…

Quelle est la cause ?

Des internautes ont fait l’effort de comparer les versions de tous les fichiers déployés sur le serveur par le SP1, puis le SP2, puis le SP3 versus SP2 puis SP3, etc. Ils ont justement relevé un comportement bizarre dans les versions du fichier Microsoft.ReportingServices.ComponentLibrary.Controls en fonction des services pack appliqués…

Version de SSRS Version de Microsoft.ReportingServices.ComponentLibrary.Controls.dll
RTM 10.50.1600.1
SP1 10.50.1600.1
SP2 10.50.3721.0
SP3 10.50.1600.1 (?!!!)
SP2 + SP3 10.50.3721.0 (??!!)

Moralité :

  • C’est donc la version 10.50.1600.1 qui devrait être déployée avec le SP3 !?!
  • Elle est plus ancienne que celle déployée par le SP2 (10.50.3721.0) !!!
  • C’est donc pour ça que le SP3 n’a pas voulu l’écraser avec sa version à lui !?!

La version 10.50.1600.1 est celle fournie avec ReportBuilder3, téléchargeable ici :

http://www.microsoft.com/en-pk/download/details.aspx?id=6116

C’est le seul fichier qui présente cette anomalie.

Solutions

Procédures officielles

Il y a 2 solutions officielles présentées dans un article de Microsoft

  • Solution N°1 : Installer ReportBuilder sur tous les postes, clients sans utiliser la version « ClickOnce » déposée sur le serveur SSRS (et corrompue). Cela va à l’encontre de la simplicité proposée par le lien ClickOnce dans SharePoint, d’autant plus qu’on ne connait pas à l’avance la population d’utilisateurs qui veulent l’utiliser.
  • Solution N°2 : Tout désinstaller (SP3, puis SP2) puis réinstaller (SP3) sur le serveur. C’est démesuré, surtout dans un contexte de vielle plateforme fragile et pour laquelle on ne voulait pas trop dépenser de temps.

Il existe une troisième solution. 😉

Il s’agit de rétablir une version cohérente de l’applicatif « ReportBuilder » déposé sur le serveur SSRS.

Les utilisateurs pourront alors de nouveau la télécharger automatiquement avec le lien « ClickOnce » comme d’habitude.

Procédure officieuse

SACHANT QU’IL SUFFIT DE REMPLACER LA DLL 10.50.3721.0 PAR LA VERSION 10.50.1600.1 ATTENDUE…

La procédure, à appliquer sur chaque serveur SSRS, est la suivante :

  1. Récupérer la DLL « Microsoft.ReportingServices.ComponentLibrary.Controls.dll » version 10.50.1600.1…
    Cette version peut se retrouver dans le fichier d’installation « MSI » de Rb3, fourni par MS, avec la commande « msiexec /a c:\temp\ReportBuilder3.msi /qb TARGETDIR=c:\temp\RB3files »
  2. Copier et changer le nom de la DLL en ajoutant le suffixe « .deploy » à la fin : « Microsoft.ReportingServices.ComponentLibrary.Controls.dll.deploy »
  3. Écraser le fichier « Microsoft.ReportingServices.ComponentLibrary.Controls.dll.deploy » sur le(s) serveur(s) SSRS cible(s) accessible dans le répertoire : %Program Files%\Microsoft SQL Server\MSSRS10_50.(SqlServer)\Reporting Services\ReportServer\ReportBuilder\RptBuilder_3\ »

Il n’y a pas besoin de redémarrer la machine ni même le moindre service.

C’EST SIMPLE, NON ?

Conclusion

La 3e procédure, de recopie de la dll perdue, est vraiment beaucoup plus simple, mais elle est à appliquer en votre âme et conscience…

Je n’ai pas encore vu de retour de Microsoft si cela rompt le “support” de la plateforme… ce qui serait étonnant quand même pour une simple dll mal remplacé par l’installshield.

Pour rappel, le support “principal” de SQL 2008R2 est terminé et le support “étendu” arrive à expiration prochainement (juillet 2019) 😉

Qu’en pensez-vous ?

Nouveau commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*

Solve : *
15 + 1 =


Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.