Estensioni e supporto dell'ecosistema
Uno degli obiettivi principali di Visual Studio Live Share è consentire agli sviluppatori di collaborare tra loro, dal comfort dei propri strumenti preferiti e altamente personalizzati. In questo modo, le interazioni ad hoc possono verificarsi frequentemente, pur rimanendo visivamente familiari ed ergonomiche, indipendentemente da ciò che stai aiutando con. A tale scopo, è fondamentale che i partecipanti all'interno di una sessione di collaborazione possano continuare a usare tutte le estensioni che supportano le preferenze e i flussi di lavoro personali (ad esempio temi colore/icone, tasti di scelta rapida, miglioramenti della produttività dell'editor).
Inoltre, per rendere il più immediato possibile l'azione di partecipare a una sessione di collaborazione, rimanendo altamente produttivi, l'obiettivo di Visual Studio Live Share è consentire agli utenti guest di sfruttare automaticamente gli strumenti specifici del progetto che hanno condiviso l'host. In questo modo, è possibile semplicemente fare clic su un collegamento, avviare lo strumento preferito e iniziare a collaborare, senza alcuna configurazione aggiuntiva. A tale scopo, è fondamentale che le estensioni, che alimentano il flusso di lavoro principale di modifica, compilazione e debug, siano in modo trasparente "remoto" dall'host al guest, in modo che elementi come il completamento automatico, la definizione go-to-definition e il debug "just work".
Questo documento illustra lo stato noto corrente per l'ampio ecosistema di estensioni, nonché una "scorecard" per gli obiettivi sopra indicati. Se si verifica un'estensione che non soddisfa questi criteri ed è fondamentale per il flusso di lavoro personale, segnalarlo.
Estensioni specifiche dell'utente
Le estensioni che supportano personalizzazioni specifiche dell'utente devono funzionare per l'host e devono funzionare per tutti gli utenti guest. Se un'estensione non funziona correttamente per l'host, si tratta di una regressione ed è probabilmente un bug in Visual Studio Live Share (segnalare un problema se ne viene visualizzato uno!). Se un'estensione non si comporta come previsto per un guest, potrebbe richiedere modifiche nell'estensione stessa e collaboreremo con l'ecosistema per risolvere o migliorare questi scenari.
Visual Studio Code
1 A meno che un utente non abbia già familiarità con un frammento di codice, non si aspetterebbe che sia disponibile e quindi non abbia necessariamente senso renderlo condiviso.
2 Queste categorie di estensione sono così diverse, che è impossibile dire che funzionano tutti. Tuttavia, in teoria, dovrebbero tenere traccia delle chiavi che non lo fanno.
3 Queste categorie di estensioni possono trarre vantaggio dalle esperienze di collaborazione e quindi abbiamo bisogno di commenti e suggerimenti degli utenti finali per sapere che!
4 Questi richiedono che il guest abbia installato gli strumenti di runtime (ad esempio Node.js) e funzioni eseguendo il codice in locale.
5 Queste operazioni si connettono a un server di qualche tipo e possono funzionare con server centralizzati, server condivisi dal guest.
Estensioni specifiche del progetto
Le estensioni installate dall'host, che supportano la modifica principale, la compilazione e il debug di un'applicazione e sono specifiche di un linguaggio/piattaforma/libreria/SDK, devono essere automaticamente disponibili per gli utenti guest, senza che sia necessario installarle. In questo modo, gli host possono configurare il proprio ambiente per supportare lo sviluppo produttivo di un progetto e consentire ai loro guest di unirsi immediatamente a loro, senza ulteriori prerequisiti. Poiché le estensioni specifiche del progetto non sono soggettive o personali in alcun modo, possono essere condivise in modo deterministico da host a guest, senza influire sull'ambiente familiare di chiunque.
Inoltre, per supportare estensioni specifiche del progetto installate da un guest, ma l'host non offre idealmente un'esperienza funzionale danneggiata , ad esempio ottenere un singolo file intellisense, in grado di formattare un documento.
| Categoria | Esempi | Condiviso? | Guest supportato? |
|---|---|---|---|
| Grammatiche/Evidenziazione della sintassi | Fish Shell, Nginx, Vetur, DotEnv, ES6 String HTML, Todo+, Rainbow CSV | ❌ | ✅ |
| Servizi linguistici | YAML, Path IntelliSense, ARM | ✅1 | ✅2 |
| Schemi JSON | Funzioni di Azure | ✅ | ✅ |
| Linter | ESLint, Markdownlint, Correttore ortografico del codice, PHPCS | ✅ | ✅2 |
| Formattatori | Prettier, Estetifi | ✅ | ✅2 |
| Debugger | Python, Debugger per Chrome | ✅3 | ❌4 |
| Test Runners | Java Test Runner, Mocha Sidebar, Jest Runner, Neptune | ❌5 | ✅2 |
| Anteprima file personalizzati | Anteprima SVG, GraphViz, Dimensioni immagine Markdown | ❌ | ✅ |
| Generatori di file/progetti | generatore di progetti C/C++ Funzioni di Azure | ❌ | ❌6 |
| Provider di controllo del codice sorgente | SVN, Hg | ❌ | ❌ |
1 Attualmente solo C# e JavaScript/TypeScript.
2 Supporta solo il documento attivo corrente, perché gli utenti guest non dispongono dell'accesso ai file locali.
3 L'esperienza di debug principale è condivisa, tuttavia, tutti i server avviati non vengono inoltrati automaticamente.
4 Gli utenti guest non hanno una copia locale dell'app e pertanto l'app in esecuzione e le sessioni di debug devono essere avviate nel computer dell'host.
5 L'output di un'esecuzione di test richiederebbe che anche tutti i terminali risultanti, i riquadri di output e gli errori siano stati condivisi con gli utenti guest.
6 Quasi tutti questi userebbero direttamente il modulo Node.js fs per creare file, che non funzionerebbero.
Problemi noti
Di seguito sono riportati i problemi noti relativi all'estensione, che potrebbero impedire l'uso di utenti guest nel contesto di una sessione di collaborazione (insieme alle relative soluzioni alternative) e pertanto potrebbero influire sul flusso di lavoro:
Visual Studio Code
| Problema | Motivo | Soluzione alternativa |
|---|---|---|
Uso del modulo Node.js fs per rilevare/leggere i file (ad esempio un file di configurazione) o enumerare le directory (e non si è un servizio di linguaggio). |
Gli utenti guest non hanno accesso ai file locali. | 1. Ridurre normalmente l'esperienza utente (se possibile). 2. Usare le API dell'area openTextDocument di lavoro e findFiles per leggere ed enumerare i file. |
Uso del modulo Node.js fs per creare o scrivere file |
Uguale a quanto sopra | N/D È possibile usare l'API openTextDocument(Uri) per creare un untitled file, ma non è possibile salvarlo direttamente nel file system, in un percorso specifico. |
| A seconda di una libreria o uno strumento in bundle di progetto | Uguale a quanto sopra | 1. Aggregare una versione di fallback della dipendenza con l'estensione 2. Supportare l'installazione globale per sbloccare gli utenti guest se scelgono di installarlo in modo esplicito. 3. Remote the state/action if possible, since the host would have the right dependencies available. |
Uso del modulo Node.js fs per creare una directory |
Uguale a quanto sopra | N/D |
Limitazione delle funzionalità ai documenti che usano lo file schema. |
I file sul lato guest usano lo vsls schema . |
Aggiungere il supporto per vsls i documenti (ad esempio) |
Uso del Uri.file metodo e/o Uri.fsPath/TextDocument.fileName dei membri per serializzare/analizzare gli URI |
Uguale a quanto sopra | Usare Uri.parse e Url.toString() , invece, che mantengono e rispettano gli schemi di file (esempio) |
Uso del workspace.openTextDocument metodo con un percorso di file anziché con un Uri |
Uguale a quanto sopra | Specificare un'istanza Uri anziché una stringa di percorso del file non elaborato (esempio) |
Uso della workspace.rootPath proprietà per rilevare la presenza di un'area di lavoro |
La workspace.rootPath proprietà chiama Uri.fsPath il primo workspaceFolder in workspace, che presenta lo stesso problema menzionato in precedenza |
Usare la workspace.workspaceFolders proprietà per rilevare invece la presenza di un'area di lavoro e, se necessario, esaminare ogni workspaceFolderUri.scheme elemento per determinare se è locale o meno |
Non specificare uno schema di documento durante la registrazione dei servizi linguistici (tramite un LanguageCliento i languages.register* metodi ) |
Gli utenti guest ricevono i risultati del servizio linguistico dalle estensioni locali e dall'host e pertanto, se entrambi i partecipanti hanno la stessa estensione del servizio linguistico installata, gli utenti guest vedranno voci duplicate per determinati elementi (ad esempio, completamento automatico, azioni di codice) | Limitare i servizi linguistici solo file a schemi e untitled (esempio) |
Mancata verifica di un documento prima di Uri.scheme popolarlo DiagnosticCollection |
Uguale a quanto sopra | Genera Diagnostics solo per il documents cui Uri.schemefile === (esempio) |
Mancata verifica dello schema dell'area di lavoro durante la restituzione Tasks da un oggetto personalizzato TaskProvider |
Gli utenti guest visualizzano tutte le attività remote e locali e pertanto visualizzano duplicati se entrambi i partecipanti hanno installato la stessa estensione | Restituisce Tasks solo per WorkspaceFolders il cuifile === Uri.scheme (esempio) |
Vedi anche
- Supporto di linguaggi e piattaforme
- Requisiti di connettività per Live Share
- Funzionalità di sicurezza di Live Share
- Principali bug, richieste di funzionalità e limitazioni
- Richieste di funzionalità e limitazioni
Problemi? Vedere la risoluzione dei problemi o inviare un feedback.