Dépannage dans Visual Studio au moment du design

Article
04/28/2010

Mise à jour : novembre 2007

Les problèmes suivants peuvent se produire lorsque vous développez des solutions à l'aide de Visual Studio Tools pour Office.

L'enregistrement d'une solution, suivi de son exécution, déclenche une erreur

Visual Studio stocke les solutions dans un dossier temporaire jusqu'à leur enregistrement. Visual Studio Tools pour Office modifie automatiquement votre stratégie de sécurité pour approuver la solution dans l'emplacement temporaire. Ces modifications sont apportées au moment de la génération de la solution. Si vous n'apportez pas aucune modification à la solution avant de l'enregistrer à un dossier permanent, Visual Studio ne génère pas la solution lorsque vous l'exécutez à nouveau à partir du nouvel emplacement. Par conséquent, la solution n'est pas automatiquement approuvée dans le nouvel emplacement, et ne s'exécute pas.

Si une erreur se produit après l'enregistrement d'une nouvelle solution dans un emplacement permanent, ouvrez le menu Générer, puis cliquez sur Régénérer la solution. Visual Studio génère alors la solution si vous ne lui avez apporté aucune modification. Visual Studio Tools pour Office apporte ensuite les modifications appropriées à la stratégie de sécurité pour le nouvel emplacement.

Impossibilité de générer un projet au niveau du document basé sur un document comportant des autorisations restreintes

Visual Studio Tools pour Office ne peut pas générer de projets au niveau du document si celui-ci comporte des autorisations restreintes. Si votre projet contient un document doté d'autorisations restreintes, la compilation du projet ne s'effectuera pas, et vous recevrez le message suivant dans la fenêtre Liste d'erreurs :

Impossible d'ajouter la personnalisation.

Si vous souhaitez inclure un document comportant des autorisations restreintes, utilisez un document non restreint pendant que vous développez et générez la solution. Ensuite, appliquez les autorisations restreintes au document dans l'emplacement de publication, une fois la solution publiée.

Certains événements ne sont pas déclenchés lors de l'utilisation de C#

Les objets Office qui ont une méthode et un événement portant le même nom ont été fractionnés dans deux objets dans les assemblys PIA (Primary Interop Assembly) d'Office : un objet principal avec toutes les propriétés et les méthodes, et un objet événement qui contient les événements dont les noms qui sont en conflit avec une propriété ou une méthode. Ces objets événement utilisent la convention de nom <NomObjet>_Événement. Si vous ne voyez pas un événement que vous attendez, effectuez un cast en interface <NomObjet>_Événement.

Par exemple, il existe un événement ActivateEvent et une méthode Activate pour un Workbook. Pour gérer cet événement, utilisez WorkbookEvents_Event au lieu de Workbook.

Créez des variables membres dans la section des déclarations :

private Excel.Workbook wkbk;
private Excel.WorkbookEvents_Event wbEvents;
private Excel.WorkbookEvents_ActivateEventHandler activateEvent;

Connectez l'événement dans _Startup :

wbEvents = (Excel.WorkbookEvents_Event)wkbk;
activateEvent = new Excel.WorkbookEvents_ActivateEventHandler(ThisWorkbook_Activate);
wbEvents.Activate += activateEvent;

Écrivez un gestionnaire d'événements :

private void ThisWorkbook_Activate()
{
    // Your code goes here.
}

Vous devez effectuer un cast à WorkbookEvents_Event parce que Excel.Workbook.Activate retourne la méthode Activate et pas l'événement ActivateEvent.

Pour éviter ce problème, vous pouvez aussi effectuer un cast de l'objet à son interface d'événement correspondante dans Startup :

((Excel.WorkbookEvents_Event)(Globals.ThisWorkbook.InnerObject)).Activate += 
    new Excel.WorkbookEvents_ActivateEventHandler(ThisWorkbook_Activate);

Écrivez ensuite un gestionnaire d'événements pour votre code :

private void ThisWorkbook_Activate()
{
    // Your code goes here.
}

Les références aux classes Office ne sont pas reconnues

Certains noms de classes, par exemple Application, se trouvent dans plusieurs espaces de noms tels que Microsoft.Office.Interop.Word et System.Windows.Forms. C'est pour cette raison que l'instruction Imports/using figurant en haut des modèles de projet inclut une constante qualifiante abrégée, par exemple :

Imports Word = Microsoft.Office.Interop.Word

using Word = Microsoft.Office.Interop.Word;

Du fait de cette utilisation de l'instruction Imports/using, vous devez différencier les références aux classes Office à l'aide du qualificateur Word ou Excel. Par exemple :

Dim doc As Word.Document

Word.Document doc;

Des erreurs se produiront si vous utilisez une déclaration non qualifiée. Par exemple :

Dim doc As Document  ' Class is ambiguous

Document doc;  // Class is ambiguous

Même si vous avez importé l'espace de noms Word ou Excel et que vous disposez d'un accès à toutes les classes qu'il contient, vous devez qualifier complètement tous les types avec Word ou Excel pour supprimer l'ambiguïté liée à l'espace de noms.

Les propriétés des contrôles sont perdues lorsque vous créez un nouveau projet basé sur un document d'un projet existant

Si vous créez un nouveau projet Visual Studio Tools pour Office basé sur un document d'un projet existant, les propriétés de tous les contrôles qui se trouvent sur le document ne sont pas copiées dans le nouveau projet. Vous devez redéfinir manuellement les propriétés pour tous les contrôles préexistants. Vous pouvez également conserver les propriétés des contrôles en créant une copie du projet existant au lieu de créer un nouveau projet, ou en chargeant le projet existant dans la nouvelle solution (dans le concepteur) et en copiant et collant les contrôles du document existant vers le nouveau document.

Les contrôles s'affichent sous forme de rectangles noirs sur le document ou la feuille de calcul

Si vous regroupez des contrôles sur un document ou sur une feuille de calcul, Visual Studio Tools pour Office ne les reconnaît plus. Les contrôles regroupés ne sont pas accessibles dans la fenêtre Propriétés et ils s'affichent sous forme de rectangles noirs sur le document ou la feuille de calcul. Vous devez dégrouper les contrôles pour restaurer leurs fonctionnalités.

Les contrôles sur un modèle Word ne sont pas visibles dans Visual Studio.

Si vous ouvrez un modèle Word dans le concepteur Visual Studio, les contrôles du modèle non alignés sur le texte peuvent ne pas être visibles. En effet, Visual Studio ouvre les modèles Word en mode Normal. Pour afficher les contrôles, cliquez sur le menu Affichage, sélectionnez Vue Microsoft Office Word, puis cliquez sur Mode Page.

Les noms des groupes de données Visual Basic mis en cache n'apparaissent pas correctement dans le cache

Les objets DataSet créés à l'aide de Visual Basic et qui sont marqués comme étant Cached et WithEvents (notamment les objets DataSet qui sont déplacés à partir de la fenêtre Sources de données ou de la boîte à outils et dont la propriété CacheInDocument a la valeur True) ont un trait de soulignement comme préfixe à leur nom dans le cache. Par exemple, si vous créez un DataSet et lui attribuez le nom Clients, le nom de CachedDataItem sera _Clients dans le cache. Lorsque vous utilisez ServerDocument pour accéder à cet élément mis en cache, vous devez spécifier _Clients au lieu de Clients.

Des erreurs du compilateur se produisent lorsqu'un projet Microsoft Office 2003 est nommé Excel ou Word

ExcelExcelWord sont des mots clés réservés dans les projets Office.

Des erreurs du compilateur se produisent après la suppression d'un contrôle NamedRange

Si vous supprimez un contrôle NamedRange d'une feuille de calcul autre que la feuille de calcul active dans le concepteur, il est possible que le code généré automatiquement ne soit pas supprimé de votre projet et que des erreurs du compilateur se produisent. Pour vous assurer que le code est supprimé, vous devez toujours sélectionner la feuille de calcul qui contient le contrôle NamedRange pour qu'elle devienne la feuille de calcul active avant la suppression du contrôle. Si le code généré automatiquement n'est pas supprimé lors de la suppression du contrôle, vous pouvez faire en sorte que le concepteur supprime le code en activant la feuille de calcul et en apportant une modification pour que la feuille de calcul soit marquée comme modifiée. Lorsque vous recréez le projet, le code est supprimé.

L'utilisation d'un chemin d'accès HTTP de l'assembly ne fonctionne pas

Les deux principales causes peuvent être les suivantes :

L'Assistant Projet Visual Studio Tools pour Office ne modifie pas la stratégie de sécurité pour les assemblys créés dans des emplacements HTTP. Vous devez accorder manuellement une confiance totale à l'assembly. Pour plus d'informations, consultez Comment : accorder des autorisations à des dossiers et des assemblys (Office System 2003).
Par défaut, ASP.NET désactive le téléchargement des DLL. Pour que les assemblys soient téléchargés sur l'ordinateur de l'utilisateur, l'administrateur de serveur Web doit modifier les propriétés IIS (Internet Information Services) pour permettre le téléchargement des DLL depuis le répertoire où l'assembly est stocké. Pour plus d'informations, consultez l'aide des services IIS (Internet Information Services) en accédant à l'adresse https://localhost/iisHelp/ sur le serveur Web.

Pour savoir si telle est l'origine du problème, vous pouvez vérifier si le journal du serveur Web contient des demandes refusées liées aux DLL. S'il s'avère que la cause du problème est autre, configurez le débogueur pour qu'il s'arrête sur toutes les exceptions et vérifiez les messages d'erreur.

Les projets créés dans des emplacements réseau UNC ne modifient pas automatiquement la stratégie de sécurité

L'Assistant Projet Visual Studio Tools pour Office modifie la stratégie de sécurité au niveau utilisateur. Si vous créez un projet dans un emplacement réseau UNC, la stratégie de sécurité doit être modifiée au niveau de l'ordinateur pour accorder une confiance totale à l'assembly avant de pouvoir l'exécuter. Vous devez effectuer manuellement les modifications de la stratégie au niveau de l'ordinateur. Pour plus d'informations, consultez Comment : accorder des autorisations à des dossiers et des assemblys (Office System 2003).

L'événement DocumentChange n'est pas déclenché lors de l'ouverture d'un document

L'événement DocumentChange est déclenché lorsque le document actif est modifié. Il est également souvent déclenché lors de l'ouverture d'un document. Toutefois, du fait des différentes façons dont Word peut ouvrir des documents (par exemple, à partir d'une ligne de commande, de l'Explorateur Windows ou du menu Fichier de Word), l'événement DocumentChange n'est pas toujours déclenché lors de l'ouverture du document. Il doit toujours être déclenché lorsque le document actif est modifié après son ouverture. Si vous voulez exécuter des actions lorsque le document est ouvert, utilisez l'événement Startup.

Les threads ne sont pas arrêtés correctement après le débogage

Visual Studio Tools pour Office suit une convention d'affectation des noms de threads qui permet au débogueur de fermer le programme correctement. Si vous créez des threads dans votre solution, vous devez nommer chaque thread avec le préfixe VSTA_ afin de garantir que ces threads sont gérés correctement lorsque vous arrêtez le débogage. Par exemple, vous pouvez affecter la valeur VSTA_NetworkListener à la propriété Name d'un thread qui attend un événement réseau.

Les événements Excel sont déclenchés différemment dans Internet Explorer que dans Excel

L'ordre de déclenchement des événements sera différent si le classeur est hébergé dans Internet Explorer ou ouvert dans Excel. De plus, certains des événements sont déclenchés deux fois. Si votre solution inclut Internet Explorer, testez la façon dont la séquence d'événements différente affecte le fonctionnement de votre solution.

L'événement New n'est pas déclenché lorsqu'un document est créé à partir d'un modèle

Lorsque vous utilisez une invite de commandes pour ouvrir un modèle Word et créer un document, vous devez utiliser le commutateur /z pour déclencher l'événement New. Ne placez pas d'espace après /z, sinon Word ouvre le modèle en vue de le modifier au lieu de créer un document basé sur le modèle. Par exemple : winword.exe /z"mytemplate.dot".

Cela revient à utiliser le commutateur /t, excepté qu'en plus, le commutateur /z déclenche l'événement New.

L'événement Open n'est pas déclenché lorsqu'une feuille de calcul XML est ouverte

Si vous basez un projet Excel sur une feuille de calcul non native existante (telle que le format XML Excel), l'événement Open n'est pas déclenché lorsque la feuille de calcul est ouverte.

La méthode BeforeClose s'exécute, mais le classeur de l'utilisateur reste ouvert

Il est possible pour un utilisateur final d'annuler l'opération de fermeture d'un classeur et de continuer à utiliser votre solution après avoir appelé le gestionnaire d'événements BeforeClose. Cela se produit lorsque l'utilisateur effectue des modifications dans une feuille de calcul, puis exécute une action pour fermer le classeur sans l'avoir préalablement enregistré. Le gestionnaire d'événements BeforeClose est appelé, puis l'utilisateur voit s'afficher une boîte de dialogue qui propose l'option d'annuler l'opération de fermeture.

Si vous placez du code dans le gestionnaire d'événements BeforeClose qui ferme les connexions de base de données ou qui exécute d'autres opérations de nettoyage, il est possible que ce code soit appelé pendant que l'utilisateur est encore en train de travailler avec votre solution.

La commande d'insertion d'images clipart n'a aucun effet dans le concepteur Visual Studio

Le fait d'ouvrir le menu Insérer, de pointer sur Image, puis de cliquer sur Image clipart n'ouvre pas le volet de tâches Image lorsqu'Excel ou Word est ouvert dans le concepteur Visual Studio. Pour ajouter une image clipart à l'aide des commandes de menu, vous devez ouvrir la copie du classeur ou du document qui se trouve dans le dossier du projet principal (et non pas la copie qui se trouve dans le dossier \bin) en dehors de Visual Studio, ajouter l'image clipart, puis enregistrer le classeur ou le document.

Impossible de créer un projet au niveau du document 2003 bien qu'Office 2003 est installé

Ce problème peut se produire si vous désinstallez la version 2007 de Microsoft Office System, puis installez la version 2003. Le message d'erreur suivant peut s'afficher lorsque vous créez un projet de personnalisation au niveau du document 2003 :

"Aucune version compatible de Microsoft Office n'est installée sur cet ordinateur."

Pour résoudre ce problème :

Fermez Visual Studio.
Ouvrez l'application Microsoft Office appropriée, puis fermez l'application. Par exemple, si vous souhaitez créer un projet de classeur Excel 2003, ouvrez puis fermez Excel 2003.
Démarrez Visual Studio et créez le projet.

Les classeurs Excel sont désactivés lorsqu'un projet de personnalisation au niveau du document Excel est ouvert dans Visual Studio

Lorsque vous ouvrez Excel 2007 et créez un projet de personnalisation au niveau du document Excel 2007 dans Visual Studio, le premier classeur ouvert ne répond plus.

Pour résoudre ce problème, cliquez sur la feuille de calcul visible dans le Concepteur Visual Studio. Le premier classeur ouvert répond à nouveau.

Voir aussi

Partager via