Creating new Blazor Client Side app -> Open .razor file can result in an exception

[NTaylorMullen]

Just found that after creating a Blazor client side application you can occasionally get:

Error encountered from project 'C:\Users\nimullen.REDMOND\source\repos\Repro\Repro\.\Repro.csproj': System.InvalidOperationException: The file 'C:/Users/nimullen.REDMOND/source/repos/Repro/Repro/Shared/MainLayout.razor' is not a descendent of the base path 'C:/Users/nimullen.REDMOND/source/repos/Repro/Repro/.'.   at Microsoft.AspNetCore.Razor.Language.DefaultRazorProjectFileSystem.GetItem(String path, String fileKind)   at 
Microsoft.CodeAnalysis.Razor.ProjectSystem.DocumentState.GetImportsCore(DefaultProjectSnapshot project)   at 
Microsoft.CodeAnalysis.Razor.ProjectSystem.DefaultDocumentSnapshot.GetImports()   at 
Microsoft.CodeAnalysis.Razor.ProjectSystem.DocumentState.ComputedStateTracker.<GetImportsAsync>d__9.MoveNext() --- End of stack trace from previous location where exception was thrown ---    at 
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)   at 
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)   at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)   at 
Microsoft.CodeAnalysis.Razor.ProjectSystem.DocumentState.ComputedStateTracker.<GetGeneratedOutputAndVersionCoreAsync>d__7.MoveNext() --- End of stack trace from previous location where exception was thrown ---    at 
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)   at 
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)   at Microsoft.CodeAnalysis.Razor.ProjectSystem.DefaultDocumentSnapshot.<GetGeneratedOutputAsync>d__20.MoveNext() --- End of stack trace from previous location where exception was thrown ---    at 
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)   at 
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)   at Microsoft.CodeAnalysis.Razor.BackgroundDocumentGenerator.<ProcessDocument>d__44.MoveNext() --- End of stack trace from previous location where exception was thrown ---    at 
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)   at 
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)   at Microsoft.CodeAnalysis.Razor.BackgroundDocumentGenerator.<TimerTick>d__48.MoveNext()
--

I'm having an extremely hard time reproducing the issue. That being said this is most likely a VS issue since IVsHierarchy is obviously providing us a bogus project path: https://github.com/aspnet/AspNetCore-Tooling/blob/master/src/Razor/src/Microsoft.VisualStudio.LanguageServices.Razor/Editor/DefaultTextBufferProjectService.cs#L67-L79

or the project system is providing us a bogus project path: https://github.com/aspnet/AspNetCore-Tooling/blob/ff1a749559a093b2f5bfce48da9597995f27c280/src/Razor/src/Microsoft.VisualStudio.LanguageServices.Razor/ProjectSystem/DefaultRazorProjectHost.cs#L107

@BillHiebert is there a known issue on the project system side of the world where UnconfiguredProject can have a funky project path when the project is in the midst of loading?

Here's where I reprod it (ignore the null ref exception, that's a WTE issue), you can see it mentioned in the activity logs:

[BillHiebert]

@NTaylorMullen I assume it is the extra .\ that is causing the issue? I wonder if the template is creating the project with this path. Would calling Path.GetFullPath() normalize these?

[NTaylorMullen]

@BillHiebert yup, the extra .. Path.GetFullPath would probably normalize but I wouldn't imagine that'd be necessary since we haven't run into this before. Is this new behavior the result of something recent and expected? I imagine we wouldn't be the only ones impacted.

[BillHiebert]

@phenning could a template change have caused this?

[phenning]

This looks like it was a result of combining the Blazor template down into one template. When it creates a non-hosted version of the template, it renames the Client\client.csproj file to .\client.csproj and returns that relative path via primaryOutputs.

I have a fix ready for the VS side. I did notice that if you close the solution and reopen, everything is fine, even though the sln file still has the .\ segment in the path.

[NTaylorMullen]

This looks like it was a result of combining the Blazor template down into one template. When it creates a non-hosted version of the template, it renames the Client\client.csproj file to .\client.csproj and returns that relative path via primaryOutputs.

I have a fix ready for the VS side. I did notice that if you close the solution and reopen, everything is fine, even though the sln file still has the .\ segment in the path.

Awesome, @phenning could you include me in those VS side changes so I can forward along to those impacted?

Also, I imagine that fix would make it in for 3.0.0-preview8 / VS16.3-preview2 correct?

[phenning]

@NTaylorMullen Added you to the PR in the WebTools repo.

And yes, this will make 16.3-preview2

[NTaylorMullen]

This was fixed by @phenning here: https://devdiv.visualstudio.com/DevDiv/_git/WebTools/pullrequest/193547