Problèmes connus et dépannage (Outils Visual Studio pour Unity)

2023-03-22

Dans cette section, vous allez trouver les solutions aux problèmes courants rencontrés par Visual Studio Tools pour Unity, ainsi que la description de problèmes identifiés. Vous apprendrez aussi comment vous pouvez aider à améliorer Visual Studio Tools pour Unity en signalant les erreurs.

Résolution des problèmes de connexion entre Unity et Visual Studio

Confirmer que `Editor Attaching` est activé ou `Code Optimization On Startup` est défini sur `Debug`

Dans le menu Unity, sélectionnez Edit / Preferences.

Selon la version d’Unity utilisée :

Vérifiez que Code Optimization On Startup est défini sur Debug.
Ou sélectionnez l’onglet External Tools. Vérifiez que la case à cocher Editor Attaching est activée.

Pour plus d’informations, voir la documentation sur les préférences d’Unity.

Impossible de s’attacher

Essayez de désactiver temporairement votre antivirus ou créez des règles d’exclusion pour VS et Unity.
Essayez de désactiver temporairement votre pare-feu ou créez des règles d’autorisation de mise en réseau TCP/UDP entre VS et Unity.
Certains programmes, comme TeamViewer, risquent d’interférer avec la détection des processus. Vous pouvez tenter d’arrêter temporairement tous les logiciels supplémentaires pour voir si cela change quelque chose.
Ne renommez pas l’exécutable Unity principal, car VSTU surveille uniquement les processus « Unity.exe ».

Visual Studio est en panne

Ce problème peut être dû à un endommagement du cache MEF de Visual Studio.

Tentez de supprimer le dossier suivant pour réinitialiser le cache MEF (fermez Visual Studio avant) :

%localappdata%\Microsoft\VisualStudio\<version>\ComponentModelCache

Votre problème devrait être résolu. Si le problème persiste, exécutez une invite de commandes développeur pour Visual Studio en tant qu’administrateur et utilisez la commande suivante :

 devenv /setup

Visual Studio cesse de répondre

Plusieurs plug-ins Unity comme Parse, FMOD, UMP (Universal Media Player), ZFBrowser ou Embedded Browser utilisent des threads natifs. Un problème se pose quand un plug-in finit par attacher un thread natif au runtime, ce qui aboutit ensuite à des appels bloquants pour le système d’exploitation. Cela signifie qu’Unity ne peut pas interrompre ce thread pour le débogueur (ou le rechargement de domaine) et cesse de répondre.

Pour FMOD, il existe une solution, vous pouvez passer l’indicateur d’initialisation FMOD_STUDIO_INIT_SYNCHRONOUS_UPDATE pour désactiver le traitement asynchrone et effectuer tout le traitement sur le thread principal.

Si vous développez votre propre plug-in natif, nous vous recommandons d’utiliser des appels de procédure asynchrone (APC) et en particulier les fonctions SleepEx, SignalObjectAndWait, MsgWaitForMultipleObjectsEx, WaitForMultipleObjectsEx ou WaitForSingleObjectEx pour coopérer correctement avec Unity et Mono lorsque le débogueur doit suspendre des threads.

Projet incompatible dans Visual Studio

La chose très importante à savoir est que Visual Studio enregistre l’état « Incompatible » dans les paramètres du projet et n’essaie pas de recharger un projet tant que vous n’utilisez pas Reload Project explicitement. Par conséquent, après chaque étape de résolution des problèmes, veillez à essayer de rouvrir la solution et essayez de cliquer avec le bouton droit sur tous les projets incompatibles, puis choisissez Reload Project.

Vérifiez que Visual Studio est configuré comme éditeur de script externe dans Unity en utilisant Edit / Preferences / External Tools.
Selon votre version d’Unity :
- Vérifiez que le plug-in Visual Studio est installé dans Unity. Help / Aboutdoit afficher un message tel que Microsoft Outils Visual Studio pour Unity est activé en bas.
- Unity 2020.x+ : vérifiez que vous utilisez le dernier package Éditeur Visual Studio dans Window / Package Manager.
Essayez de supprimer tous les fichiers de projets/solutions et le dossier .vs de votre projet.
Essayez de recréer des projets/solution à l’aide de Open C# Project ou Edit / Preferences / External tools / Regenerate Project files.
Vérifiez que vous avez installé la charge de travail Game/Unity dans Visual Studio.
Essayez de nettoyer le cache MEF comme expliqué ici.
Essayez de réinstaller Visual Studio (à l’aide de la charge de travail Game/Unity uniquement pour démarrer).
Essayez de désactiver les extensions tierces au cas où elles pourraient interférer avec l’extension Unity dans Tools / Extensions.

Rechargements supplémentaires ou perte de toutes les fenêtres de Visual Studio

Veillez à ne jamais toucher aux fichiers projet directement à partir d’un processeur de composants ou de tout autre outil. Si vous devez vraiment manipuler le fichier projet, utilisez pour cela l’API que nous exposons. Consultez la section des problèmes de références d’assembly.

Si vous constatez des rechargements supplémentaires ou si Visual Studio perd toutes les fenêtres ouvertes lors du rechargement, vérifiez que les packs de ciblage .NET installés sont les bons. Pour plus d’informations, voir la section suivante sur les frameworks.

Le débogueur ne s’arrête pas sur les exceptions

Lors de l’utilisation du runtime Unity hérité (équivalent de .NET 3.5), le débogueur s’arrête toujours quand une exception est non gérée (= en dehors d’un bloc try/catch). Si l’exception est gérée, le débogueur utilise la fenêtre Paramètres d’exception pour déterminer si un arrêt est nécessaire ou non.

Avec le nouveau runtime (équivalent de .NET 4.6), Unity introduit une nouvelle méthode de gestion des exceptions de l’utilisateur : toutes les exceptions sont considérées comme « gérées par l’utilisateur », même si elles sont en dehors d’un bloc try/catch. C’est pourquoi vous devez maintenant les vérifier explicitement dans la fenêtre Paramètres d’exception si vous voulez que le débogueur s’arrête.

Dans la fenêtre Paramètres d’exception (Déboguer > Fenêtres > Paramètres d’exception), développez le nœud d’une catégorie d’exceptions (par exemple Exceptions Common Language Runtime, c’est-à-dire les exceptions .NET), puis cochez la case correspondant à l’exception spécifique que vous voulez intercepter dans cette catégorie (par exemple System.NullReferenceException). Vous pouvez également sélectionner une catégorie entière d'exceptions.

Dans Windows, Visual Studio vous demande de télécharger la version cible de .Net Framework pour Unity

Lors de l’utilisation du runtime Unity hérité (équivalent.NET 3.5), Outils Visual Studio pour Unity nécessite .NET Framework 3.5, qui n’est pas installé par défaut sur Windows 8 ou 10. Pour résoudre ce problème, suivez les instructions de téléchargement et d’installation du .NET Framework 3.5.

Lors de l’utilisation du nouveau runtime Unity, les packs de ciblage .NET version 4.6 ou 4.7.1 sont également requis en fonction de la version d’Unity. Il est possible d’utiliser le programme d’installation Visual Studio pour les installer rapidement (modifier votre installation, composants individuels, catégorie .NET, sélectionnez tous les packs de ciblage 4.x).

Problèmes de référence d’assembly ou de propriété de projet

Si votre projet est complexe côté référence ou si vous souhaitez mieux contrôler cette étape de génération, vous pouvez utiliser notre API pour manipuler le contenu du projet ou de la solution généré. Vous pouvez également utiliser des fichiers réponse dans votre projet Unity et nous les traiterons.

Avec les versions récentes de Visual Studio et Unity, la meilleure approche semble utiliser un fichier personnalisé Directory.Build.props avec vos projets générés. Vous pourrez ensuite contribuer à la structure du projet sans interférer avec le processus de génération.

Points d’arrêt avec un avertissement

Si Visual Studio ne parvient pas à trouver un emplacement source pour un point d’arrêt spécifique, un avertissement s’affiche autour de votre point d’arrêt. Vérifiez que le script utilisé est correctement chargé/utilisé dans la scène Unity actuelle.

Points d’arrêt non atteints

Vérifiez que le script utilisé est correctement chargé/utilisé dans la scène Unity actuelle. Quittez à la fois Visual Studio et Unity, puis supprimez tous les fichiers générés (*.csproj, *.sln), le dossier .vs et l’intégralité du dossier Library. Vous trouverez plus d’informations sur le débogage C# sur le site web Unity.

Impossible de déboguer les lecteurs Android

Nous utilisons la multidiffusion pour la détection de lecteur (qui est le mécanisme par défaut utilisé par Unity), mais nous utilisons par la suite une connexion TCP standard pour attacher le débogueur. La phase de détection représente le principal problème des appareils Android.

Wi-Fi est polyvalent, mais très lent comparé à USB en raison de la latence. Nous avons constaté un manque de prise en charge de multidiffusion appropriée pour certains routeurs ou appareils (les séries Nexus sont bien connues pour cela).

USB est très rapide pour le débogage, et Visual Studio Tools pour Unity est maintenant en mesure de détecter les périphériques USB et de communiquer avec le serveur adb pour transférer correctement des ports pour le débogage.

Problèmes avec IntelliSense ou coloration du code

Essayez de mettre à niveau votre Visual Studio vers la dernière version. Essayez les mêmes étapes de résolution des problèmes que pour les projets incompatibles.

Problèmes connus

Il existe des problèmes connus dans Visual Studio Tools pour Unity qui résultent de la façon dont le débogueur interagit avec une version antérieure de Unity du compilateur C#. Nous nous efforçons de vous aider à résoudre ces problèmes, mais vous rencontrerez peut-être les problèmes suivants d’ici-là :

Lors du débogage, il arrive que Unity s'arrête.
Lors du débogage, il arrive que Unity se bloque.
L'exécution pas à pas et la reprise des méthodes ne fonctionnent parfois pas très bien, en particulier dans les itérateurs ou dans les instructions switch.

Signaler les erreurs

Aidez-nous à améliorer la qualité de Visual Studio Tools for Unity en envoyant des rapports d'erreurs lorsque vous êtes confronté à un arrêt, un blocage ou autres erreurs. Ceci nous permet d'examiner et de résoudre les problèmes de Visual Studio Tools pour Unity. Merci !

Comment signaler une erreur lorsque Visual Studio se bloque

Il a été établi que Visual Studio se bloque parfois lors du débogage avec Visual Studio Tools pour Unity, mais nous avons besoin de plus de données pour comprendre ce problème. Vous pouvez nous aider à enquêter sur le problème en suivant les étapes ci-dessous.

Pour signaler que Visual Studio se bloque pendant le débogage avec Visual Studio Tools pour Unity

Sur Windows :

Ouvrez une nouvelle instance de Visual Studio.
Ouvrez la boîte de dialogue Attacher au processus. Dans la nouvelle instance de Visual Studio, dans le menu principal, choisissez Déboguer, Attacher au processus.
Attachez le débogueur à l'instance figée de Visual Studio. Dans la boîte de dialogue Attacher au processus , sélectionnez l'instance figée de Visual Studio à partir de la table Processus disponibles , puis choisissez le bouton Attacher .
Interrompez le débogueur. Dans la nouvelle instance de Visual Studio, dans le menu principal, choisissez Déboguer, Interrompre tout ou appuyez simplement sur Ctrl+Alt+Pause.
Créez un vidage de thread. Dans la fenêtre Commande, entrez la commande suivante et appuyez sur Entrée :
```
Debug.ListCallStack /AllThreads /ShowExternalCode
```
Vous devrez peut-être afficher d'abord la fenêtre Commande . Dans Visual Studio, dans le menu principal, choisissez Affichage, Autres fenêtres, Fenêtre Commande.

Sur Mac :

Ouvrez un terminal et obtenez le PID de Visual Studio pour Mac :
```
ps aux | grep "[V]isual Studio.app"
```
Lancez le débogueur lldb :
```
lldb
```
Attachez à l’instance de Visual Studio pour Mac à l’aide du PID :
```
process attach --pid THE_PID_OF_THE_VSFM_PROCESS
```
Récupérez le StackTrace pour tous les threads :
```
bt all
```

Enfin, envoyez le vidage de thread à vstusp@microsoft.com, ainsi qu’une description de ce que vous faisiez quand Visual Studio s’est bloqué.

Voir aussi

Résolution des problèmes de Visual Studio

Partager via