Aspnetcore: Blazor WASM Debugging in VS launches Edge with a separate user data directory

Created on 16 Apr 2020  Â·  8Comments  Â·  Source: dotnet/aspnetcore

@rynowak told me to just file something here to start with :). I'm sure this lives somewhere else, like in VS.

If I launch a Blazor WASM app in VS with Ctrl-F5, I get a new tab opened in my existing Edge browser window and everything is nice. My extensions are present, and I'm properly signed in to Edge, you can see my profile picture in the top-right:

The top-right of a Microsoft Edge browser window showing my profile picture

Cool cool cool cool.

Now, I launch with F5 to use the swanky new debugging features. Instead of a new tab, I get a new window. That's fine, I don't mind that. However, it's not signed in with my profile, so I don't get my extensions or existing cookies. This was annoying because I'm building an app that signs in to GitHub, and I didn't have my Github cookie or my password manager in order to log in again. Since I'm not signed in, my profile picture isn't in the top right:

The top-right of a Microsoft Edge browser window showing no profile picture

I noticed that VS launched msedge with a --user-data-dir=C:\Users\anurse\AppData\Local\Microsoft\VisualStudio\16.0_019f56a0\WebTools\EdgeUserData_E906737D_E10E9004-4C41-47FB-B7F0-6B3B57970109 parameter which seems to be why it's not picking up my normal profiles. This seems odd to me :(.

Docs affected-most area-blazor blazor-wasm enhancement severity-nice-to-have

Most helpful comment

Thanks @anurse.
I will follow up with the JS Debugger team regarding this.

All 8 comments

Thanks @anurse.
I will follow up with the JS Debugger team regarding this.

As I understand it, it’s necessary to use a separate profile. Chromium browsers only support a single instance per profile directory, so if you already have a browser open then ask it to open a new one with different command line options (eg to open the debugging port) it will ignore the different options and continue using the existing instance.

The only way we can be sure to enable debugging is either:

  • Force the user to close all existing browser instances (extremely hostile)
  • Or, launch on a separate profile

What @SteveSandersonMS said is correct. If you want to use your existing user data folder with your extensions and preference you'll have to close all existing browser instances before launching it from Visual Studio (you'll need to do this each time).

To configure Visual Studio to launch the browser with your existing user data folder you'll need to:

  1. Go to the Browse with... option:
    image
  2. Add... a new browser:
    image
  3. Configure the path to your browser, and use a custom ---user-data-dir argument pointing to your user data folder
    image
    In my PC they are:
    C:\Program Files (x86)\Microsoft\Edge Beta\Applicationmsedge.exe
    --user-data-dir="C:\Users\\AppData\local\Microsoft\Edge Beta\User Data"
  4. Ok to add it, and then optionally set it as the Default browser if you choose to.
  5. Browse with your user profile

Ugh. That feels like a really unpleasant user experience. I get the issues, but from a user experience side it feels really unsatisfactory.

I’ve made it work (by logging in to the “alternate” profile) so I don’t really need to set up the new browser launch profile. I’m not sure most users would understand what’s going on here and why they don’t have any of their cookies and extensions.

The 2 main restrictions that we have are:
1: If Chrome was launched without a debugging port (this is the normal launch), you cannot add one later, so we won't be able to debug it.

  1. If you launch Chrome with a user profile that is already being used by another instance of Chrome, the existing instance is reused, so if Chrome is already running for that user profile, and it doesn't have a debugging port, you cannot add one unless you stop all instances of Chrome for that user profile first

The only alternative I can think of to avoid that experience would be for the user to chose a fixed port for Chrome, and modify all Chrome shortcuts to always open debugging with that fixed port, and then modify VS to also use that port too.

@anurse If you have any suggestions as to how we can improve the experience, we'd love to hear them :)

Yeah, it certainly does seem like we’re stuck with what we’ve got :(. Maybe some way of notifying the user would help? And/or docs clarification?

And of course we could see about filing a chromium bug but I’m not super hopeful about that being resolved any time soon (if at all :)).

Let's wait and see how community feels about this. Moving this to the backlog (as a potential docs improvement).

I followed these instructions and it worked for me. It would be really helpful, if this is documented in the debugging section.

I would suggest to add another browser profile called "Microsoft Edge with Dev-Profile" or something.

Was this page helpful?
0 / 5 - 0 ratings