westmor.blogg.se

Another instance is running windows 10
Another instance is running windows 10












another instance is running windows 10

Letting a admin-instance of VSCode writing to the same user data location as the non-admin one is really dangerous. To be fair, given our settings sync support it would be relatively easy to have both instances share the same settings and extensions by just enabling settings sync. If you were to go this route, I'm sure this would get reported as a bug pretty quickly. I wouldn't expect simply opening an app as admin to lose all of my settings, and any changes that I did make to not be reflected back when running the app not as admin. This would be a deal breaker in my books.

  • slight startup perf penalty because in order to find out on Windows if you run as admin, we run some C code ( ).
  • another instance is running windows 10

  • you cannot share any settings, keybindings etc.
  • the danger of writing to the user data dir with elevated rights and then running VSCode with normal permissions is prevented ( #109370).
  • Suggested fix is to detect elevated permissions on startup and depending on that derive a user-data-dir that is different from the normal one.
  • you see that warning dialog that another instance of VSCode is already running as admin.
  • VSCode cannot communicate with that pipe due to insufficient permissions.
  • VSCode will try to connect to the named pipe that runs as admin.
  • this will open a named pipe for communication with admin privileges.
  • goes) depending on wether you run with elevated permissions or not. The only way how we can support opening different windows of VSCode with different permissions is by creating a different user-data-directory (the place all our config etc. As part of our issue grooming effort this month, we might look into support for this issue.














    Another instance is running windows 10