Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The CLI and VS do not play nicely #22388

Open
mattleibow opened this issue Oct 29, 2021 · 2 comments
Open

The CLI and VS do not play nicely #22388

mattleibow opened this issue Oct 29, 2021 · 2 comments
Assignees
Labels
Area-CLI Area-Workloads untriaged Request triage from a team member

Comments

@mattleibow
Copy link
Member

mattleibow commented Oct 29, 2021

Describe the bug

Just a start of the issue here. Will flesh out soon.

I was working to help Lutz get his machine "fixed" and the main issue was that he installed VS and then needed to update the .NET SDK. The only way currently is to download from dotnet/installer and then run that.

The issue with this is that installing a new .NET SDK causes VS to "forget" about the workloads. So, if I had checked maui in the IDE, then it suddenly forgets about it and I get build errors saying that it needs me to install android, ios and the rest.

As a good developer, I obey and run the commands. Now I am happy, and VS can run. But this is where the real issues start: When I uninstall VS and uninstall my .NET SDK, the workloads are still there. At least according the the msi/registy.

As a result, if I install a new VS then the IDE does nothing and re-uses the workloads or something. This causes the issue that since I had a workload installed that was unsigned/newer, the IDE cannot install what it needs. In the end, we end up with workloads that cannot be repaired. VS tries and then sees that I had installed a different thing, so skips.

I know this particular issue is a bit hard to solve, but maybe we need to teach the SDK to uninstall (somehow) the workloads it "owns". This means when I uninstall VS, the workloads are cleared up. Just like uninstalling VS uninstalls its workloads.

Or maybe just like the vswhere tool that lives outside the IDE, we need a sdk "manager" that shows where/what you have installed and can uninstall workloads even if I have removed both VS and dotnet. Or something.

The solution is pretty simple but at the same time no so simple. The fix is to install vs and the sdk again, then remove the workloads from the cli, then uninstall vs and then uninstall the sdk. The next round of installs will fix it.

To Reproduce

Exceptions (if any)

Further technical details

  • Include the output of dotnet --info
  • The IDE (VS / VS Code/ VS4Mac) you're running on, and its version
@dotnet-issue-labeler dotnet-issue-labeler bot added Area-CLI untriaged Request triage from a team member labels Oct 29, 2021
@dsplaisted
Copy link
Member

I think the first issue here (where installing the standalone SDK causes VS to forget about workloads) will be fixed by dotnet/installer#12600.

It sounds like there may be other issues too, but I'm not sure exactly what's going on there so it's hard to say if they'll be fixed by fixing that initial installation problem.

@dodikk
Copy link

dodikk commented Mar 9, 2023

Having a similar issue on MacOS.
After rebooting the mac - the visual studio "forgets" about ios and android platforms and yields the error NETSDK1139: The target platform identifier ios was not recognized error.

P.S. Removing visualStudio and all .net SDKs/runtimes has helped me once. But for the second time that's no longer the case. So given the installer's behaviour, the workloads are somehow surviving all my rm -rfs , uninstall-vsmac.sh and dotnet-core-uninstall actions respectively.

/cc @dsplaisted @mattleibow

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-CLI Area-Workloads untriaged Request triage from a team member
Projects
None yet
Development

No branches or pull requests

4 participants