Razor "Go to definition" breaks when target is defined an SDK-style project

[onyxmaster]

Consider the source at https://github.com/onyxmaster/RazorDefs. Open the solution in Visual Studio 2017 (tested with 15.5 Preview 5), then build the solution and open (with the same instance of VS) the index.cshtml in RazorDefs project.
When opened, try navigating to all three types definitions via F12/"Go To Definition". The first two types are handled properly. Unfortunately, the last one would use the fallback "metadata" decompilation mode.
The apparent reason is that the code is defined in the SDK-style project. The target framework of this project is unimportant (netstandard2.0 or net461 both lead to such problems), the debugging format also appears not to matter (at first I blamed portable PDBs).
This is mildly disappointing when one is gradually converting a pre-VS2017 solution projects to new format.

P.S. I understand that this at least partly a Visual Studio + ASP.NET issue, but I'm not sure where this should be sent, so I place it here. Please excuse me for failing to find a better place to report this.

[davkean]

@jasonmalinowski @BillHiebert @dpoeschl @Pilchie Where do we start with this, is this likely a Razor, Roslyn or project system issue?

[Pilchie]

My initial guess would be that the reference to the sdk project is not being added properly as a project to project reference from the .cshtml project.

This means that either the P2P reference api isn't being called in Roslyn, or the output path that is passed for netstandard reference that is passed doesn't match what Roslyn has internally.

I suspect this should start with @BillHiebert.

[jasonmalinowski]

Did somebody grab a screenshot by chance to see what the metadata as source code is? Looking at the "assembly" header up top would give a good way to diagnose.

[onyxmaster]

[Pilchie]

@BillHiebert - this looks like a razor tooling issue to me. Should this issue be moved somewhere?

[Pilchie]

Ping @BillHiebert?

[BillHiebert]

Razor (and other web pages like aspx, master, etc) intellisense requires the project being referenced to implement the IVsHierarchy property VSHPROPID_IntellisenseUnknown. I don't think the managed project system implements it.

Note that I am referring to Razor intellisense in non-core projects which RazorDefs is.

[jasonmalinowski]

@BillHiebert Why does it use that...?

[davkean]

Tag @rynowak. Can someone point me to the usage of VSHPROPID_IntellisenseUnknown so that I can understand how Razar uses it?

[BillHiebert]

@davkean - it s not razor per se, but the intellisense infrastructure in the older project systems (websites and WAPs). Sync up with me and I can point you to code which uses it.

[Pilchie]

Is there an internal thread on this that I'm not aware of?

[Pilchie]

Ping @davkean @rynowak @BillHiebert ?

[rynowak]

I don't have any context on this, @BillHiebert is probably the only one who can help.

[lt-gerjan]

I have filed this under #3558 but it seems the same issue.
This is targetted 15.8, do you guys have confidence that this will/can be solved by then? Whats the rough estimate for 15.8?

Sorry for pushing but this one is kinda dealbreaker for me to move to .NET Standard libs :(

[davkean]

@rynowak/@BillHiebert Would this part of the rewrite of the Razor <-> Roslyn layer? Or would it be separate?

[Pilchie]

I assume that would only fix the case where it's ASP.NET Core and razor pages on the source side, not when it's a traditional webforms or MVC app referencing a .NET Standard Library.

[lt-gerjan]

@davkean @Pilchie Yes, in my case it is a WebForms website. So that's slightly different than the OP/TS

[rynowak]

Can someone point me to the usage of VSHPROPID_IntellisenseUnknown so that I can understand how Razar uses it?

Sorry, I must have missed this ping. I don't have any familiarity with this. @BillHiebert is your guy.

[davkean]

At this point, we don't have an intention of returning anything for VSHPROPID_IntellisenseUnknown - language service hookup is much different in new project system versus legacy. I suspect we'll run into the same issue when we move over to IWorkspaceProjectContext for legacy as well.

We should figure out why the automatic conversion from binary reference to P2P isn't kicking in here, and change either side to make this work. This is in 15.8 but cannot see how we make this fit.

[wanton7]

Any chance instead putting man hours to fixing this, just add new csproj format support for ASP.NET MVC 5 projects instead?

[NickCraver]

As mentioned in #2670 (comment), this is a huge pain point for migrations. I'm suffering this in Opserver because it's just me and I can pay the price to help advance this whole thing. Or I thought, if in retrospect I knew this kind of stuff would be punted for so long I never would have touched the new project system for anything referenced by ASP.NET MVC 5. It's not worth it. And I won't put others through it.

When it comes to a whole team of developers migrating Stack Overflow (and anyone working on it, not just those actively migrating), I can't ask developers to suffer this. It's a huge productivity loss and frustration. And it's a regression. When you want to go see source, you can't. You're back to find all references or find in files. Code Lens is useless (I don't believe this is hyperbole, if it doesn't find things, you can't trust it at all): you can't tell what's referenced, what's not, what's safe to remove, etc. It makes porting a nightmare and incredibly more risky.

When we need to port an ASP.NET application to ASP.NET Core, we first extract all code possible into another project to minimize the duration, impact, and risk of the ASP.NET move itself. This way we can be building as much code as possible not only on net4* but also netstandard or netcoreapp - whatever the final target is. But we can't do that. We have to choose between doing that and a working IDE. This means one of the two reasons for moving all that code and ensuring it's good to go on the net target frameworks is moot. We have to big bang it at the end anyway.

This is one of the biggest pain points I've hit as part of #2670 (meant to be an issue covering all the pain points). Please consider fixing this portion of it first. It prevents us even using the new project system during a migration - we basically have to pretend it doesn't exist if referenced anywhere in the chain.

[lt-gerjan]

To support @NickCraver 's statement: I have a large software project (180+ projects, mixed .NET and .NET Core) and I really want to move to the new MsBuild SDK/Project System, but this single issue is stopping me from doing it.
It's just unacceptable for me that our developers lose F12, Code lens etc.

Porting everything to .NET core would be a 1-year+ task.

PS1: Yes I know I can only +1 Nicks reaction, but I think a comment would give more "weight"
PS2: Please do not forget WebForms, see #3558

[onyxmaster]

We're in situation not unlike Nick's one. We've got a 200+-project solution that is partially new-style netstandard2.0, partially new-style net472 and has two old-style v4.7.2 web application projects. I guess our developer team is much smaller, but still we have the same problems. In fact for me, this is second-worst "feature" I encounter when working on this project (the first one is VS being "slow", but that's another story).

Can we live with it? Sure, in most cases F12+Ctrl-T or just Ctrl-T work fine, since we mostly use this feature for exploring existing service APIs (and my team is good at naming things). But it feels like I'm fighting against the tools I have to use.

[lt-gerjan]

@davkean @Pilchie Is it possible for you to say when this will be fixed? Or is it hard to say? (I know its saying milestone 16 but that one has no date)
I am at a point where I want to start converting but I'm still hesitating

[Pilchie]

@BillHiebert and @rynowak - is this something that we could take another look at given that other features like CodeLens and FAR have been updated to work here?

cc @jjmew

[NickCraver]

Is there any update on this? As stated above it's a major issue for migrations and we're about to eat a lot of pain experiencing it.

[jjmew]

The fix will be available in VS 2019 Preview 4.

[onyxmaster]

Installed the RC, it works now, I can't thank you enough.

[davkean]

@onyxmaster Great to hear! //cc @BillHiebert

[NickCraver]

@davkean It's also working well for us (and a big help at this critical part of our migration). Thanks for getting this in!

[davkean]

@NickCraver Thanks for following up.