Description
Is there an existing issue for this?
- I have searched the existing issues
Describe the bug
I'm not sure where this issue actually belongs. On one hand it seems like a VS tooling issue, on the other it seems like fixing it potentially changes how certs are loaded in aspnetcore.
When you use a standard naming convention for projects within a solution, for instance, you call you blazor projects Web and have two different solutions open at the same time one of them ends up with the wrong passphrase for the certificate and an error that it can't find the certificate even though you can clearly see the Web.pfx certificate mounted in the container.
Best I can tell this is ultimately caused by the fact VS tooling overwrites that Web.pfx certificate in %APPDATA% when the second project goes to run leaving the first project with a certificate that is named properly, but the wrong passphrase because it's user secrets contained the passphrase for the original Web.pfx that was created.
I believe a way to resolve this conflict would be to simply use the user secrets id as the certificate name which kind of ties it together for any developer digging in to understand and eliminates the ambiguity in file names that ultimately causes this issue int he first place.
Expected Behavior
No response
Steps To Reproduce
No response
Exceptions (if any)
No response
.NET Version
No response
Anything else?
No response