Risoluzione dei problemi e problemi noti (Visual Studio Tools per Unity)

In questa sezione verranno illustrate le soluzioni a problemi comuni relativi a Visual Studio Tools per Unity. Oltre alla descrizione dei problemi noti, verrà spiegato come contribuire al miglioramento di Visual Studio Tools per Unity segnalando gli errori.

Risoluzione dei problemi di connessione tra Unity e Visual Studio

Verificare che Editor Attaching sia abilitato o Code Optimization On Startup che sia impostato su Debug

Nel menu Unity selezionare Edit / Preferences.

A seconda della versione di Unity usata:

  • Verifica che Code Optimization On Startup sia impostato su Debug.
  • In alternativa, selezionare la External Tools scheda. Verificare che la Editor Attaching casella di controllo sia abilitata.

Per altre informazioni, vedere le preferenze nella documentazione di Unity.

Non è possibile connettersi

  • Provare a disabilitare temporaneamente il programma antivirus o a creare regole di esclusione per Visual Studio e Unity.
  • Provare a disattivare temporaneamente il firewall o a creare regole per consentire la connettività di rete TCP/UDP tra Visual Studio e Unity.
  • Alcuni programmi, come Team Viewer, possono interferire con il rilevamento dei processi. Interrompere temporaneamente qualsiasi software aggiuntivo e verificare se la situazione cambia.
  • Non rinominare il file eseguibile principale di Unity, perché Visual Studio Tools per Unity esegue il monitoraggio solo dei processi "Unity.exe".

Visual Studio si arresta in modo anomalo

Questo problema può essere dovuto al danneggiamento della cache MEF di Visual Studio.

Rimuovere la cartella seguente per reimpostare la cache MEF. Prima di eseguire questa operazione, chiudere Visual Studio:

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

Questo dovrebbe risolvere il problema. Nel caso in cui il problema si verifichi ancora, eseguire un prompt dei comandi per gli sviluppatori per Visual Studio come amministratore e usare il comando seguente:

 devenv /setup

Visual Studio smette di rispondere

Alcuni plug-in Unity come Parse, FMOD, UMP (Universal Media Player), ZFBrowser o Embedded Browser usano thread nativi. Il problema si verifica quando un plug-in tenta di collegare un thread nativo al runtime, causando il blocco delle chiamate al sistema operativo. Ciò significa che Unity non può interrompere il thread per il debugger (o ricaricare il dominio) e interrompere la risposta.

Per FMOD, è disponibile una soluzione alternativa che consiste nel passare il flag di inizializzazione FMOD_STUDIO_INIT_SYNCHRONOUS_UPDATE per disabilitare l'elaborazione asincrona ed eseguire tutte le elaborazioni nel thread principale.

Se si sviluppa un plug-in nativo personalizzato, è consigliabile usare chiamate asincrone di procedure (APC) e in particolare SleepEx, , WaitForMultipleObjectsExSignalObjectAndWaitMsgWaitForMultipleObjectsEx, , o WaitForSingleObjectEx funzioni per collaborare correttamente con Unity e Mono quando il debugger deve sospendere i thread.

Progetto incompatibile in Visual Studio

L'aspetto molto importante da sapere è che Visual Studio sta salvando lo stato "Incompatibile" nelle impostazioni del progetto e non tenterà di ricaricare un progetto fino a quando non si usa Reload Projectin modo esplicito . Quindi, dopo ogni passaggio di risoluzione dei problemi, assicurarsi di provare a riaprire la soluzione e provare a fare clic con il pulsante destro del mouse su tutti i progetti incompatibili e scegliere Reload Project.

  1. Verificare che Visual Studio sia impostato come editor di script esterno in Unity usando Edit / Preferences / External Tools.
  2. A seconda della versione di Unity:
    • Verificare che il plug-in di Visual Studio sia installato in Unity. Help / Aboutdovrebbe visualizzare un messaggio come Microsoft Visual Studio Tools per Unity è abilitato nella parte inferiore.
    • Unity 2020.x+: verificare di usare il pacchetto di Visual Studio Editor più recente in Window / Package Manager.
  3. Provare a eliminare tutti i file di progetti/soluzioni e la .vs cartella nel progetto.
  4. Provare a ricreare progetti/soluzioni usando Open C# Project o Edit / Preferences / External tools / Regenerate Project files.
  5. Assicurarsi di aver installato il carico di lavoro Game/Unity in Visual Studio.
  6. Provare a pulire la cache MEF come illustrato qui.
  7. Provare a reinstallare Visual Studio (usando solo il carico di lavoro Game/Unity per l'avvio).
  8. Provare a disabilitare le estensioni di terze parti nel caso in cui possano interferire con l'estensione Unity in Tools / Extensions.

Ricarichi aggiuntivi o perdita di tutte le finestre aperte di Visual Studio

Verificare di non toccare mai i file di progetto direttamente da un processore di risorse o qualsiasi altro strumento. Se è necessario modificare il file di progetto, è disponibile un'API. Controllare la sezione relativa ai problemi dei riferimenti degli assembly.

Se si verificano ricaricamenti aggiuntivi o se Visual Studio perde tutte le finestre aperte durante il ricaricamento, verificare di aver installato i .NET Targeting Pack appropriati. Per altre informazioni, controllare la sezione seguente sui framework.

Il debugger non si interrompe in caso di eccezioni

Quando si usa il runtime di Unity legacy (equivalente a .NET 3.5), il debugger si interrompe sempre quando un'eccezione non viene gestita (= all'esterno di un blocco try/catch). Se l'eccezione viene gestita, il debugger usa la finestra Impostazioni eccezioni per determinare se è necessaria o meno un'interruzione.

Con il nuovo runtime (equivalente a .NET 4.6), Unity ha introdotto un nuovo modo per gestire le eccezioni utente e, di conseguenza, tutte le eccezioni vengono interpretate come "gestite dall'utente", anche se si trovano all'esterno di un blocco try/catch. Ecco perché è ora necessario controllarle in modo esplicito nella finestra Impostazioni eccezioni se si vuole che il debugger si interrompa.

Nella finestra Exception Impostazioni (Debug > Windows > Exception Impostazioni), espandere il nodo per una categoria di eccezioni (ad esempio, Eccezioni Common Language Runtime, ovvero eccezioni .NET) e selezionare la casella di controllo per l'eccezione specifica che si vuole intercettare all'interno di tale categoria (ad esempio System.NullReferenceException). È inoltre possibile selezionare un'intera categoria di eccezioni.

In Windows Visual Studio chiede di scaricare il framework di destinazione Unity

Quando si usa il runtime di Unity legacy (equivalente a .NET 3.5), Visual Studio Tools per Unity richiede .NET Framework 3.5, che non è installato per impostazione predefinita in Windows 8 o 10. Per risolvere questo problema, seguire le istruzioni per scaricare e installare .NET Framework 3.5.

Quando si usa il nuovo runtime di Unity, sono necessari anche pacchetti di destinazione .NET versione 4.6 o 4.7.1 a seconda della versione di Unity. È possibile usare il programma di installazione di Visual Studio per installarli rapidamente (modificare l'installazione, i singoli componenti, la categoria .NET, selezionare tutti i pacchetti di destinazione 4.x).

Problemi relativi alle proprietà di assembly o di progetto

Se il progetto si basa su riferimenti complessi o se si vuole controllare meglio questo passaggio di generazione, è possibile usare l'API di Visual Studio per la modifica del contenuto della soluzione o del progetto generati. È anche possibile usare file di risposta nel progetto Unity perché venga elaborato.

Con le versioni recenti di Visual Studio e Unity, l'approccio migliore sembra usare un file personalizzato Directory.Build.props insieme ai progetti generati. Sarà quindi possibile contribuire alla struttura del progetto senza interferire con il processo di generazione.

Punti di interruzione con avviso

Se Visual Studio non riesce a trovare un percorso di origine per un punto di interruzione specifico, verrà visualizzato un avviso per il punto di interruzione. Verificare che lo script in uso sia caricato/usato correttamente nella scena Unity corrente.

Mancato accesso ai punti di interruzione

Verificare che lo script in uso sia caricato/usato correttamente nella scena Unity corrente. Uscire sia da Visual Studio che da Unity, quindi eliminare tutti i file generati (*.csproj, *.sln), la .vs cartella e l'intera cartella Library. Per altre informazioni sul debug C#, vedere il sito Web Unity.

Impossibile eseguire il debug dei lettori Android

Per il rilevamento dei lettori viene usato il multicast, che è il meccanismo predefinito usato da Unity, ma in seguito viene usata una connessione TCP normale per collegare il debugger. La fase di rilevamento è il problema principale per i dispositivi Android.

Il Wi-Fi è versatile ma è molto lento rispetto alla connessione USB a causa della latenza. Alcuni router o dispositivi non supportano il multicast: è il caso, ad esempio, della serie Nexus.

La connessione USB è ultra rapida per il debug e Visual Studio Tools per Unity è ora in grado di rilevare i dispositivi USB e comunicare con il server adb per inoltrare in modo appropriato le porte per il debug.

Problemi con IntelliSense o colorazione del codice

Provare ad aggiornare Visual Studio alla versione più recente. Provare gli stessi passaggi per la risoluzione dei problemi dei progetti incompatibili.

Problemi noti

In Visual Studio Tools per Unity sono presenti problemi noti derivanti dall'interazione tra il debugger e la versione precedente del compilatore C# inclusa in Unity. Microsoft sta lavorando per risolvere questi problemi, ma nel frattempo potrebbe verificarsi quanto segue:

  • Durante il debug si verifica talvolta un arresto anomalo di Unity.

  • Durante il debug si verifica talvolta un blocco di Unity.

  • Durante l'esecuzione o l'uscita da istruzioni o metodi vengono riscontrati comportamenti errati, in particolare negli iteratori o all'interno di istruzioni switch.

Segnalare errori

È possibile contribuire a migliorare la qualità di Visual Studio Tools per Unity inviando apposite segnalazioni quando si riscontrano arresti anomali, blocchi o errori di altro tipo. In questo modo Microsoft potrà esaminare e correggere i problemi relativi a Visual Studio Tools per Unity. Grazie.

Come segnalare un errore in caso di blocco di Visual Studio

Sono stati segnalati alcuni casi di blocco di Visual Studio durante il debug con Visual Studio Tools per Unity, ma sono necessari maggiori dati per analizzare questo problema. Per contribuire alla risoluzione del problema, eseguire le operazioni descritte di seguito.

Per segnalare un blocco di Visual Studio durante il debug con Visual Studio Tools per Unity

In Windows:

  1. Aprire una nuova istanza di Visual Studio.

  2. Aprire la finestra di dialogo Connetti a processo. Nel menu principale della nuova istanza di Visual Studio scegliere Debug, Connetti a processo.

  3. Connettere il debugger all'istanza bloccata di Visual Studio. Nella finestra di dialogo Connetti a processo selezionare l'istanza bloccata di Visual Studio dalla tabella Processi disponibili e quindi fare clic sul pulsante Connetti .

  4. Sospendere l'esecuzione del debugger. Nel menu principale della nuova istanza di Visual Studio scegliere Debug, Interrompi tutto oppure premere CTRL+ALT+INTERR.

  5. Creare un dump del thread. Nella finestra Comando immettere il seguente comando e premere INVIO:

    Debug.ListCallStack /AllThreads /ShowExternalCode
    

    Potrebbe essere necessario rendere prima visibile la finestra Comando . Nel menu principale di Visual Studio scegliere Visualizza, Altre finestre, Finestra di comando.

In Mac:

  1. Aprire un terminale e ottenere il PID di Visual Studio per Mac:

    ps aux | grep "[V]isual Studio.app"
    
  2. Avviare il debugger lldb:

    lldb
    
  3. Collegarsi all'istanza di Visual Studio per Mac usando PID:

    process attach --pid THE_PID_OF_THE_VSFM_PROCESS
    
  4. Recuperare l'analisi StackTrace per tutti i thread:

    bt all
    

Inviare infine il dump del thread all'indirizzo vstusp@microsoft.com, insieme a una descrizione dell'operazione in corso quando si è verificato il blocco di Visual Studio.

Vedi anche