Language service is broken again

[Peter-Juhasz]

VS 17.12 P3

This update is completely unusable.

• Components/attributes/events are not recognized
• Partial syntax highlighting
• No completion for any of them

What is interesting that HTML and C# seems to work.

And there is a huge number of errors for all components:

Found markup element with unexpected name 'AppIcon'. If this is intended to be a component, add a @using directive for its namespace.

There are not even logs related to Razor like they used to be in VS:

[davidwengier]

@Peter-Juhasz That does not sound good at all. Can you just confirm a few things for me please:

• If you go Tools -> Options -> Text Editor -> Razor, check the log level. I know at some point in the past you pushed this to "Debug", but perhaps updating VS somehow broke the setting value. Certainly not ideal or intentional, but perhaps simple explanation for what otherwise appears to be a major problem
• When you say "What is interesting that HTML and C# seems to work", do you mean "C# and Html work in the context of a Razor file" or "C# and Html files themselves work"?
• Can you open Tools -> Options and search for the word "force". You should see an option in Preview Features called "Force use of runtime code generation for Razor". Can you let me know if it is checked, and if it is, can you uncheck it and try restarting Visual Studio.

If none of the above is fruitful, and you still don't see Razor Logger Output available in the Output Window, I think perhaps a Repair might be the way to go. It's a bit of a sledehammer approach but I can't think of any reason the logs shouldn't show up. I checked my own 17.12 P3 install and didn't have any issue seeing logs.

[Peter-Juhasz]

(No extensions enabled, no proxies/VPN, etc.)

HTML and C#:

• They seemed to work in the context of a Razor file (so it was not fully broken, but "only the components were")
• On the other end, C#/Roslyn marked all members in a Razor code behind as unused with no references (I did not check component classes specifically)

What did not help:

• Editing a Razor file (earlier it usually helped to ping the server again)
• Build/rebuild
• Restarting VS
• I got it work randomly one time yesterday (so I was finally able to work and didn't close VS for that day :D)

Logs:

Now I have the Razor Logger Output back in the Output pane, but don't know why.

I remember a log message something like "unable to get semantic tokens for Host version 4", but forgot to copy it, sorry about that.

What seemed to help for some degree:

• I cleaned the bin/obj folders for that Blazor WASM project, and it seems more stable.

But unfortunately, it did not. (I'm writing this post while testing it this morning.) I restarted VS again, and now different parts are broken:

• No outlining
• No Razor Logger Output at all again (although I had earlier today)

And the next restart:

• There is outlining
• But no completion, it just never loads
• No logs either

Next attempt:

• Everything works fine
• There are logs as well

I have not tested VS repair (although I did that recently some time ago but before P3) or the preview feature switch for code generation yet, but the whole system feels super fragile. Testing any of these workarounds may take time, because having a working VS+Razor may be just "luck", and we have to wait for like a week, to say that "there is high probability" that the workaround helped.

Is there any resource allocation for reliability? I can see language feature bugs are covered with unit tests, and although integration tests with the hosting environment VS (or VS Code) may not be that easy, but it may worth some investment. Or is this "co-hosting" theme supposed to help too? (Sorry for the off-topic I'm just curious. Both for the technical aspect and as a user, what will finally bring a shift in reliability. If you have any docs about that topic, I would be happy to read that.)

[davidwengier]

Ugh, sorry that you're experiencing this. Let me tackle the easy bits first.

I can see language feature bugs are covered with unit tests, and although integration tests with the hosting environment VS (or VS Code) may not be that easy, but it may worth some investment

We do have integration tests, they run twice per day, and are generally green. We did have some recent failures, specifically around that "Force runtime code generation" flag I mentioned, however they have mostly been addressed already, and sadly were not the types of failures you are experiencing. In fact, now that you've supplied more information, I don't think that option is relevant to what you're seeing: It certainly won't have anything to do with logs not appearing, or components not being discovered.

There isn't any doco, but if you're curious the integration tests are here, and they run on an Azure DevOps pipeline against the latest nightly build of Visual Studio. The intention is to find reliability issues very early, and indeed the last two commits that went into 17.12 Preview 3 (https://github.com/dotnet/razor/pull/10967 and https://github.com/dotnet/razor/pull/10949) were to fix bugs that the integration tests identified. Just to be clear - these bugs are fixed in your build, and they're not the issues you're running into anyway. We used to run integration tests on ever PR, against the latest public preview build of Visual Studio, but had to remove that because it got to be almost impossible to restrict our dependencies to only what is in preview, and policy means a build against non-preview Visual Studio is not allowed from an open source repository.

No outlining

We have had one other report of intermittent outlining, though not accompanied with any of the other issues you're seeing. Outlining is an interesting "canary in the coal mine" because it happens very early in the lifecycle of a document being opened.

No Razor Logger Output at all again (although I had earlier today)

This is the oddest issue of all, and I think the one that we should focus on first. It is surprising, and I've never seen it before, but what is extra surprising is that other Razor features seem to be working. Our output window logger is in the same DLL and DI container as our features that receive project information, yet seemingly only half of that is working.

From memory, you are allowed to log a VS Feedback issue, but not include a recording, is that correct? How does your company feel about taking a memory dump of devenv.exe from Task Manager, and emailing it to me instead? :)

If you can log a feedback issue (without a recording is fine) when you see the problem, there are some things that would be captured which might prove interesting. If you want to see what they are for yourself, the things I would look for are:

• In your %localappdata%\Microsoft\VisualStudio folder you should see a folder that has the pattern "17.0_XXXXXXXX" where "XXXXXXXX" is the first 8 characters of a Guid. You might see more than one, if you have multiple Visual Studio installations, and will make this next step a little harder. In that folder, there is a ComponentModelCache folder, and in that folder a Microsoft.VisualStudio.Default.err file. If you search for "Razor" in that file, does anything come up that isn't just a path to a DLL? Feel free to email me the file if it's easier.
• Going back up a directory, you should be in something like C:\Users\dawengie\AppData\Local\Microsoft\VisualStudio\17.0_637604e0. If you click in the address bar and change "Local" to "Roaming" that will put you into a folder that has an ActivityLog.xml file. Again, is there anything in there if you search for "Razor"?

The presence of anything in the .err file that says Razor, and isn't a DLL path, is probably proof that a Repair is necessary. The ActivityLog can be a little more nuanced.

Testing any of these workarounds may take time, because having a working VS+Razor may be just "luck"

I completely understand, and it would be remiss of me not to mention that the VS Installer now includes a "Rollback" function, if going back to Preview 2 is a better solution for you. I greatly appreciate all of the effort you go to when logging issues, and investigating these suggestions, but I realise you have actual work to do too :)