Cache de l'assembly SharePoint-clear

J'ai un site WSS sur un hôte tiers partagé.Cache de l'assembly SharePoint-clear

J'ai une solution avec certains contrôles personnalisés -J'utilise ensuite le composant WebPart SmartPart pour afficher ces contrôles.

Voici le problème -Je mets à jour le code et publie la solution sur l'hôte distant. Mais ensuite je vois les résultats de la "vieille" assemblée.

J'ai tout essayé et la seule solution est de changer le nom des classes des contrôles.

Je ne suis pas sûr où cela est mis en cache-et comment pourrais-je l'effacer.

Nous vous remercions de votre aide.

Source

2010-09-22 Anonymous

FYI Je l'ai résolu en mettant à jour la version d'assemblage sur chaque build. Le composant WebPart SmartPart possède une classe LateBinder qui exécute un Assembly.Load du contrôle d'utilisateur Web sélectionné (je pense qu'il ne prenait pas la dernière version), mais la mise à jour de la version d'assemblage l'a résolu. (Je crains de ne pas être sûr à 100% de ceci à cause de mon environnement limité.) BTW Je n'ai pas eu accès au serveur pour faire une réinitialisation d'IIS. Merci de votre aide. –

Généralement, il n'y a pas de mise en cache lorsque vous suivez un cycle complet de retrait/suppression/ajout/déploiement du package de solution. Mais tout d'abord je ferais en sorte que le paquet que vous déployez ait la bonne version du code. Pour ce faire, renommez le package en * .cab, extrayez l'assembly et vérifiez le code modifié dans Reflector. Une fois que vous savez que vous avez l'assemblage correct dans le package de solution, veillez à rétracter et supprimer le wsp précédent sur le serveur SharePoint. Pour mettre à jour un assembly uniquement, une mise à niveau de la solution devrait être correcte - mais essayez la fonction complète de retrait/suppression/ajout/déploiement juste pour être du côté de la sauvegarde.

Je suppose que vous n'avez pas d'accès physique au serveur SharePoint. Mais dans le cas où ce qui précède échoue votre assembly peut être mis en cache dans les fichiers temporaires ASP.NET des cadres ou n'est pas correctement supprimé du dossier GAC/BIN. Pour les réinitialiser, un administrateur doit effectuer une réinitialisation IIS, puis supprimer (avant que le site ne soit à nouveau utilisé) ce dossier: C: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ Fichiers ASP.NET temporaires et cocher BIN/Dossiers GAC pour l'assemblage. Faites-moi savoir si cela aide ...

Source

2010-09-23 08:19:12 Bernd

Ce n'est pas tout à fait vrai, les assemblages sont mis en cache en mémoire par le travail du minuteur, ce qui peut affecter le déploiement des mises à jour du code du récepteur. En fonction du manifeste WSP, IIS peut également être réinitialisé automatiquement ou non. Dans le cas de fichiers déployés dans le GAC, cela peut nécessiter une réinitialisation manuelle afin de voir les modifications. Un assembly n'est jamais mis en cache dans le dossier ASP.NET temporaire. Il est uniquement utilisé pour les fichiers ASPX ou ASCX conformes dynamiquement par exemple. – TheCodeKing

Merci d'avoir signalé cela. Je suppose que vous avez raison sur le dossier temporaire ASP.NET. Ce que vous dites sur le travail du minuteur dont je ne suis pas sûr. Pourquoi et comment le travail du minuteur doit-il mettre en cache les assemblages? En ce qui concerne la réinitialisation IIS, je ne suis pas sûr de ce que vous voulez dire. Dès que vous déployez la solution en utilisant un travail de minuteur (pas avec -local), vous avez la garantie que tous les WFE de la batterie exécutent un iisreset (c'est ce que MSDN dit ...). – Bernd

Oui, le travail du minuteur peut mettre en mémoire cache le code d'assemblage lorsque certaines commandes sont exécutées via stsadm. Dans ce cas, en fonction de la commande, ils peuvent s'exécuter dans le contexte du processus de temporisation. Il est parfois nécessaire de redémarrer le processus de minuterie pour que le code du récepteur de fonction mis à jour soit exécuté.Je le sais parce que j'ai passé de nombreuses heures dessus. En ce qui concerne la réinitialisation d'IIS, il existe une option dans le manifeste WSP pour contrôler le comportement appelé ResetWebServer. Certes, je pense que par défaut, ils seraient toujours redémarrés si le code déployé vers le GAC. – TheCodeKing

Si vous déployez les assemblys sur le GAC, vous devrez redémarrer IIS. Les composants WebPart SmartPart peuvent également mettre en cache des données en mémoire, ce qui peut aider à la réinitialisation des services Internet (IIS). Cela dépend de la façon dont le problème se manifeste. Est-ce que le contenu de la page n'est pas en train de se mettre à jour, ou est-ce que l'ancien code semble fonctionner?

Source

2010-09-22 22:21:55 TheCodeKing

Merci, c'était vraiment utile -J'ai ajouté un commentaire à ma question expliquant comment je pouvais le résoudre. –

Cache de l'assembly SharePoint-clear

Répondre

Questions connexes