project-system: Razor "Go to definition" breaks when target is defined an SDK-style project
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.
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 2
- Comments: 31 (23 by maintainers)
As mentioned in https://github.com/dotnet/project-system/issues/2670#issuecomment-444844616, 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 alsonetstandardornetcoreapp- 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.
The fix will be available in VS 2019 Preview 4.
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-stylenet472and has two old-stylev4.7.2web 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.
@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
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 https://github.com/dotnet/project-system/issues/3558
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.
Installed the RC, it works now, I can’t thank you enough.