The preview currently focuses on ASP.NET and ASP.NET Core web applications/services along with Node.js based web applications. While syntax highlighting and other features may work broadly, particular attention has been paid to language support for C#, JavaScript, TypeScript, HTML, and CSS. See language and platform support for details.

We intend to improve support additional languages and non-web based application types over time.

Sound off and comment or 👍 (upvote) below on the languages / frameworks / app types you are most interested in seeing supported.

Note that developers starting the collaboration session (hosts) do not have this limitation. It is specific to guests joining a session.

Currently source control features like those found in the VS Team Explorer and the VS Code Source Control tabs do not function for guests joining a collaboration session as they rely on local files to work. In addition, source control diffing features suffer from similar problems regardless of where they are initiated.

We should consider doing the extra work required to allow guests to use source control diffing in VS and VS Code to help owners isolate issues if there is sufficient interest in the scenario.

Note that developers starting the collaboration session (hosts) do not have this limitation. It is specific to participants joining a session.

The results of tests run via the Test Explorer in Visual Studio do not land in the common output window or errors list and therefore require access to the Test Explorer to see. We could enable sharing of these results with guests if there is sufficient interest.

Note that developers starting the collaboration session (hosts) do not have this limitation. It is specific to participants joining a session.

Visual Studio Code supports the concept of running tasks via the command palette. While developers starting the collaboration session (hosts) can use this feature freely, participants that join the session are not able to take advantage of the capability as VS Code attempts to run these tasks locally. We should enable remote execution of these tasks for the guest so they are also able to take advantage of the feature.

While most developers that collaborate will be using an existing chat and voice solution (Slack, Teams, Skype, etc), enabling a rapid way to start up a voice conversation from within the tool with any participants could streamline this process significantly.

Note that developers starting the collaboration session (hosts) do not have this limitation. It is specific to guests joining a session.

Requires #31 to be implemented to resolve.

Currently package and dependency/reference management UIs like the "NuGet Package Manager" and dependency management features including"Add Reference..." are not available to guests in Visual Studio. The NuGet package manager console does not currently function for participants.

As a workaround, files like packages.config or csproj files can be manually updated by double clicking on the file and editing the XML contents to include the needed references.

Test

Note that developers starting the collaboration session (hosts) do not have this limitation. It is specific to guests joining a session.

Currently guests joining a collaboration session in Visual Studio are limited to the "Folder View" in the Solution Explorer. What the guest sees is basically equivalent to what the host sees if they then click on the "Solutions and Folders" button.

Solution View:

Folder view / what the guest sees:

While most web based projects mirror the file system, solution view is the most familiar starting point for developers using the tool. Therefore, allowing the guest to see the same "view" of information the host sees is useful to help communicate even if not all project system features are enabled for the guest.

(Note: See #46 on supporting projects outside of the solution root, #149 for sharing files not visible in the solution view, and #35 for supporting package management UX.)

While invite links are relatively short lived and non-guessable, given collaboration sessions can have multiple participants join, it may be useful to give users or organizations visibility to who has joined the session and when even after the session has completed. This access tracking would enable them to determine who to talk to if unexpected changes were either intentionally or unintentionally made by someone. Sound off below on whether you think this would be needed in your organization.

vsftest alpha demo

This issue has been moved from https://developercommunity.visualstudio.com/content/problem/135256/vsftest-alpha-demo.html
VSTS ticketId: 512659
These are the original issue comments:

Nikola Mihaylov [MSFT] on 10/20/2017, 10:52 AM (50 min ago):

I've tried it and it demoes

These are the original issue solutions:
(no solutions)

Related to #2.

Currently VS Live Share allows anyone with an invite link to sign in and join a collaboration session. The invite link identifier is only valid while collaboration session is active (so time is a factor), is large, and non-guessable which increases the overall security of the approach. However, while this is convenient and reduces friction for guests some individuals may want to lock down to specific individuals instead.

In addition to organizations being able to set invite link minimum access levels (#2), individuals could additionally be given the ability to set access levels on a specific invite link at one of the following levels:

1. Anonymous access (if supported, see #3)
2. Anyone with the link
3. Anyone in the account
4. Specific groups or people

Incremental feature to #2 and #4.

In addition to allowing organizations / individuals to limit access to links based on whether they are registered with the Live Share "account", we could enable users to use membership in VSTS teams, groups, or accounts to set similar limits.

Test

Note that developers starting the collaboration session (host) do not have this limitation. It is specific to participants joining a session.

Currently the developer that started the collaboration session (host) is the only one that can trigger a build or start a debugging session. While it provides the owner a high degree of control, the downside of this approach is that guests will be unable to start a build or debug while the owner is away temporarily. We could allow guests to run a build or start a debugging session to solve this challenge.

Test

Test

Currently the first guest that joins a collaboration session has full intellisense for C#, JS, and TS files. However, subsequent guest that join get colorization and basic / same file intellisense.

Test

vsftest alpha demo

This issue has been moved from https://developercommunity.visualstudio.com/content/problem/135256/vsftest-alpha-demo.html
VSTS ticketId: 512659
These are the original issue comments:
(no comments)
These are the original issue solutions:
(no solutions)

Note that developers starting the collaboration session (hosts) do not have this limitation. It is specific to guests joining a session.

The results of diagnostics like performance profiling land in specialized windows not currently shared with guests while performance profiling is running. We could enable sharing of these results in real-time like co-debugging features if there is sufficient interest.

As a near term workaround, owners can execute the profiling operations and save the resulting output .diagsession file in the project folder. Guests can then double click on this file to open it in VS.

Test

Test

Test

When working on a feature or bug with others it is often necessary to show another participant where a bug occurs in a given application by walking them through the scenario in the UI. While simply describing the location can be sufficient in many instances, allowing collaborators to start a "shared browsing" session could streamline this interaction.

A gesture would exist in tools that would allow a browser to start up on each collaborator's machine and clicks and navigation events would be synchronized across them. This provides a low-latency way to bring another participant to the right place in the application.

Test

Due to a missing protocol/feature, currently guests cannot rename, delete, or add files.

In addition, when the host executes these file operations they are not automatically reflected on the guest's Solution Explorer / File Explorer.

Test
TEST.zip

TEst

Incremental feature to #2 and #4.

In addition to allowing organizations / individuals to limit access to links based on whether they are registered with the Live Share"account", we could enable users to note specific GitHub teams or orgs to set similar limits.

Test

This is a test issue to verify that Visual Studio Feedback Bot has the correct level of access to this repository.

While Live Share automatically uses the identity used to sign into VS for work and school (AAD backed) accounts, personal Microsoft accounts require use of the "External" option in the dialog that appears.

Product and Version [VS/VSCode]: Visual Studio 2017 Update 6 (15.6)
OS Version [macOS/Windows]: Windows 10 64-bit
Live Share Extension Version: 0.1.0.217
Target Platform or Language [e.g. Node.js]: Any

Steps to Reproduce / Scenario:

1. [Host] Sign into Visual Studio using a personal Microsoft account (eg outlook.com, live.com, hotmail.com)
2. [Host] Share

Expected: Sharing occurs
Actual: Prompted to pick an identity. You then need to select "External Account" and sign in via the browser.

Currently the preview requires anyone with an invite link to sign in to join a collaboration session to ensure that the person starting the collaboration knows who is actually connected to the session. However, this adds an extra step for guests joining the collaboration session and may not be desirable in scenarios like open source projects.

Introducing an anonymous permissions level would resolve this problem where a participant could join the collaboration session without signing in (and then opt to sign in later). The invite link is non-guessable which increases the overall security of the approach.

Note that developers starting the collaboration session (owners) do not have this limitation. It is specific to guests joining a session.

Related to #36

Currently source control features like those found in the VS Team Explorer and the VS Code Source Control tabs do not function for guests joining a collaboration session as they rely on local files to work.

We should consider doing the extra work required to allow guests to execute source control operations (commit/checkin, pull, push, etc) on behalf of the owner if there is sufficient interest.

The private preview currently supports:

• Visual Studio 2017 Update 6 (15.6) on Windows 7, 8.1, and 10
• Visual Studio Code on Windows 7, 8.1, and 10
• Visual Studio Code on macOS Sierra (10.12) and up

👍 (upvote) if you'd like to see VS Code for Linux supported.

See #91 for VS for Mac. For voting on additional dev language or platform support, use #12.

Test

Test

Currently guests do not have access to build output as co-debugging initiates only after build and launch has competed. Build output should be shared once a build begins even if the actual debugging session does not kick off until some time later.

Currently the private preview has a unified undo/redo stack for everyone in the collaboration session. This can cause unexpected behaviors when individuals are not editing the same section of code. This is a significant technical challenge to overcome, but is worth taking on if we get sufficient interest and feedback.

Find in files and related functions have not yet been implemented. Unfortunately, while this is a "feature level" amount of work the result of it feels like a bug when you try to use the base feature set.

Currently VS Live Share allows anyone with an invite link to sign in and join a collaboration session. The invite link identifier is only valid while collaboration session is active (so time is a factor), is large, and non-guessable which increases the overall security of the approach. However, while this is convenient and reduces friction for guests some organizations may want to lock down to specific individuals instead.

Organizations should be able to establish a set of users in a Live Share “account” and set minimum invite link access at one of the following levels:

1. Anonymous access (if supported, see #3)
2. Anyone with the link
3. Anyone in the account
4. Specific groups

Organizations should be able to change these settings at any time and have this update any existing links automatically.

Currently Visual Studio profiles do not support GitHub based authentication and therefore extra steps are required to sign into Project Cascade using a GitHub ID from VS.

We could work to get GitHub auth supported in Visual Studio profiles to then fully support sign up and SSO across Microsoft Accounts, Azure AD, and GitHub.

Breakpoints do not currently synchronize between VS Code clients (though they do for VS). Breakpoints set by the host are hit and guests can step and see the debugging session stop, but guests can not set breakpoints and do not have visibility to those set by the host. We are working with the VS Code team to get the needed product changes to enable this capability.

Currently Live Share only supports a single root folder.

• In VS Code, this means the recently added multi-root workspace feature is not yet supported for guests.
• In VS, this means files from projects referenced in a solutions that are not in a folder at or underneath the solution file will not appear for guests.

This feature requests adding these capabilities into Live Share.

This is related to #44. Currently hosts can perform file operations during a collaboration session that are not automatically reflected in the Solution Explorer / File Explorer on the guest's side. As with #44, the protocol to enable this is not yet implemented but the result is bug-like, so flagging as both.

Due to a bug, Microsoft accounts (work, school, or personal) do not show an avatar even if one has been configured in the profile.

Product and Version [VS/VSCode]: Visual Studio 2017 Update 6 (15.6)
OS Version [macOS/Windows]: Windows 10 64-bit
Live Share Extension Version: 0.1.0.217
Target Platform or Language [e.g. Node.js]: Any

Steps to Reproduce / Scenario:

1. [Host] Add a profile picture to your Microsoft account
2. [Host] Sign into Visual Studio using a Microsoft account

• Do not override to GitHub vial Tools > Options > Live Share

3. [Host] Open a project with a Live Share supported platform (e.g. ASP.NET)
4. [Host] Share
5. [Guest] Sign into Visual Studio using a GitHub account (via Tools > Options > Live Share)
6. [Guest] Join the collaboration session using the link from step 3

Expected: The guest sees the host's profile picture near the share button and vice versa
Actual: While the host sees the guest's GitHub profile picture, the guest just sees initials

Note that developers starting the collaboration session (hosts) do not have this limitation. It is specific to guests joining a session.

A number of Visual Studio extensions use standard interface specifications and extension points and do not directly access the local filesystem (via native file APIs). These along with colorization, theming, key maps, snippets, etc will "just work" for guests that have joined a collaboration session.

However, there are extensions that use features that either:

1. Go directly at the file system
2. Shell out and execute command line tools that are expected to be installed locally

In some cases these extensions just go to the file system for a configuration file and otherwise function. Others will error out. There are a number of potential solutions to these problems that we are investigating.

Note that the person that initiated the collaboration session (host) will not run into any of these limitations.

Sound off in the comments below with any critical extensions you need that are not working as expected.

While development tools like VS and VS Code provide a solid base to work from, modern development often involves working with command line tools. In addition, there can be environment specific config issues ranging from environment variables to configuration files and more.

While providing unrestricted access to a terminal or command prompt to all participants has security implications, allowing the host to start up a shared terminal session that guests can then access as well could provide a good middle ground. The host and guests would all be able to enter commands into the terminal and see the output. The host would be able to terminate the session at any point.

vsftest alpha demo

This issue has been moved from https://developercommunity.visualstudio.com/content/problem/135256/vsftest-alpha-demo.html
VSTS ticketId: 512659
These are the original issue comments:

Nikola Mihaylov [MSFT] on 10/20/2017, 10:52 AM (46 min ago):

I've tried it and it demoes

These are the original issue solutions:
(no solutions)

Note that developers starting the collaboration session (hosts) do not have this limitation. It is specific to guest joining a session.

Many VS Code extensions use standard interface specifications like the language server protocol that abstract them away from local file system access. These along with colorization, theming, key maps, snippets, etc will "just work" for guests that have joined a collaboration session.

However, there are extensions that use features that either:

1. Go directly at the file system (e.g. via the fs module)
2. Shell out and execute command line tools that are expected to be installed locally

In some cases these extensions just go to the file system for a configuration file (e.g. eslint) and otherwise function. Others will error out. There are a number of potential solutions to these problems that we are investigating.

Note that the person that initiated the collaboration session (host) will not run into any of these limitations.

Sound off in the comments below with any critical extensions you need that are not working as expected.