Referencing 3.0 RCL project from 3.0 Web App results in 404

[mkArtakMSFT]

Describe the bug

Add a Razor Class Library(RCL) and reference from Web App 3.0, then run the project got 404 error.

To Reproduce

REPRO STEPS

1. File > New Project > C# > ASP.NET Core Web Application > .NET Core ~ ASP.NET Core 3.0 > Web Application > NoAuth
2. Right click the solution > Add > New project > ASP .NET Core Web Application > .NET Core ~ ASP.NET Core 3.0 > Razor Class Library
3. Paste in Page1.cshtml file with the following code:

   Hello World

4. Right click the Razor ClassLib project to build it
5. Right click the Web App project and select Add > Reference. In the Reference Manager dialog, check the Razor Class Library project > OK
6. Rebuild solution and run the Web App project, navigate to /MyFeature/Page1 in a web browser

A 404 error page shows up.

Expected behavior

The page loads just fine

Screenshots

Additional context

https://devdiv.visualstudio.com/DevDiv/_workitems/edit/738297

[NTaylorMullen]

So investigated this and we're missing some key features from the SDK and NuGet in regards to lifting transitive framework references from packages/projects into the deps.json. The tl;dr; of the issue is we don't end up thinking the Razor class library has a reference to MVC and therefore don't consider it as a candidate MVC assembly to translate into routes/other information.

Today we dive over the entire application graph (defined by deps.json) and look at each entries dependencies to see if it references one of MVC's many primary assemblies. If it does, we consider it for View discovery, otherwise we ignore it. This enables us to prevent loading every assembly in the world to enable a fast startup experience. Now that all of ASP.NET is a framework reference when we look at a dependent package/project that only targets a framework reference; we don't see that they're targeting MVC because the deps.json indicates they have 0 dependencies. Example:

  "Bug4332RCL/1.0.0": {
	"runtime": {
	  "Bug4332RCL.dll": {}
	},
	"compile": {
	  "Bug4332RCL.dll": {}
	}
  },

There are two issues tracking some of the efforts to manifest the understanding of a transitive project/package targeting a framework.

• Referencing a shared framework does not flow across ProjectReference sdk#2420
• Represent FrameworkReferences in NuGet - pack & restore support NuGet/Home#7342

@dsplaisted @livarcocc Is it fair to say these two issues embody bringing FrameworkReference information into the deps.json?

@rynowak @pranavkm has this scenario been thought of in this new world of ours where everything is a framework reference? Were there other plans to fix this or was the plan to just wait for fixes from other teams?

/cc @natemcmaster

[NTaylorMullen]

Talked with @rynowak offline and his suggestion was to remove our filtering logic of "is a candidate MVC assembly". Main motivation behind this is now that ASP.NET is a framework reference we greatly limit the number of dlls we need to inspect. I'll give this a shot and work with @sebastienros to see what startup impact it has.

[dsplaisted]

The NuGet issue is to reference FrameworkReferences in the assets file. I don't think we have plans to represent them in the deps file, though we could consider that if necessary.

[NTaylorMullen]

The NuGet issue is to reference FrameworkReferences in the assets file. I don't think we have plans to represent them in the deps file, though we could consider that if necessary.

Ah, ok. In regards to our requirements if i'm able to get by without needing the deps.json then we shouldn't need that. I'll keep this issue up-to-date

[NTaylorMullen]

Alright, so we tried to scan the whole world and ran into a ton of issues. Most importantly our perf got destroyed:

Description	RPS	CPU (%)	Memory (MB)	Avg. Latency (ms)	Startup (ms)	First Request (ms)	Latency (ms)
baseline	14,207	86	365	20.8	849	172.9	1.3
After Change	14,774	88	441	19	1056 (+24%)	608.7 (+352%)	1.4

Sooo, that being said @dsplaisted / @livarcocc we'll need a transitive package/project framework reference to exist in the deps.json. I'll send an email out so we can talk more.

[NTaylorMullen]

Marking as blocked until dotnet/sdk#2729 is completed.

[mkArtakMSFT]

Moving out to preview4 as the dependent work hasn't yet completed.

[mkArtakMSFT]

Talked to @nguerrera and @livarcocc regarding this. The dependent work will be available in 3.0.0-preview5 and this work will be unblock then.

[NTaylorMullen]

VSTS issue: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/738297

[mkArtakMSFT]

#8428

[ghstahl]

Lots of 3.0 talk going on here. Is this also going to get fixed in 2.2 or is that a dead branch? My problem #10331 happened on 2.2.

[pranavkm]

Is this also going to get fixed in 2.2 or is that a dead branch?

@ghstahl we will usually consider targeted fixes for 2.1 \ 2.2. Unfortunately the approach we took to fix this issue incurred a fairly substantial change so porting it the change as-is wouldn't be an option.

[ebekker]

Please note, in my experience using 3.0.0-Preview6, I'm still experiencing this issue.

The workaround described here to use the sample Add30AssemblyWorkaround does fix the issue for me.

[mkArtakMSFT]

Hi @ebekker. The was fixed in a way, which doesn't require the parts discovery workaround any more. There were some follow-up issues we had to address during Preview 7 release, specific to the new model. Can you please be more specific what is the exact problem you're having?

[ebekker]

If my ASP.NET Core web project just references an RCL library that contains a Razor Page, if I try to reference the page using the path that is either "implied" by the Page's directory path (e.g. /MyFeature/Page1 in the default project created by dotnet new razorclasslib) or explicitly specified in the @page directive (e.g. `@page "/testpage"), I get a 404 error.

If however, I also add the Add30AssemblyWorkaround call in my Startup.ConfigureServices, then both scenarios work as expected.

If you would like, I can provide a reference to a sample project. Or perhaps I should wait till preview 7 to retry my scenario.

[pranavkm]

If you would like, I can provide a reference to a sample project. Or perhaps I should wait till preview 7 to retry my scenario.

@ebekker could you please file a new issue and share a repro app?

[rodrmoya]

This seems to be happening still, at least on Mac, easy repro:

rodrigo@Rodrigos-MacBook-Pro:/tmp/test $ dotnet new sln
The template "Solution File" was created successfully.
rodrigo@Rodrigos-MacBook-Pro:/tmp/test $ dotnet new razorclasslib -s -o RazorUIClassLib
The template "Razor Class Library" was created successfully.

Processing post-creation actions...
Running 'dotnet restore' on RazorUIClassLib/RazorUIClassLib.csproj...
  Restore completed in 97.32 ms for /private/tmp/test/RazorUIClassLib/RazorUIClassLib.csproj.

Restore succeeded.

rodrigo@Rodrigos-MacBook-Pro:/tmp/test $ dotnet sln add RazorUIClassLib/RazorUIClassLib.csproj 
Project `RazorUIClassLib/RazorUIClassLib.csproj` added to the solution.
rodrigo@Rodrigos-MacBook-Pro:/tmp/test $ dotnet new mvc -o MvcApp
The template "ASP.NET Core Web App (Model-View-Controller)" was created successfully.
This template contains technologies from parties other than Microsoft, see https://aka.ms/aspnetcore/3.1-third-party-notices for details.

Processing post-creation actions...
Running 'dotnet restore' on MvcApp/MvcApp.csproj...
  Restore completed in 96.6 ms for /private/tmp/test/MvcApp/MvcApp.csproj.

Restore succeeded.
         
rodrigo@Rodrigos-MacBook-Pro:/tmp/test $ dotnet add MvcApp/MvcApp.csproj reference RazorUIClassLib/RazorUIClassLib.csproj 
Reference `..\RazorUIClassLib\RazorUIClassLib.csproj` added to the project.
rodrigo@Rodrigos-MacBook-Pro:/tmp/test $ cd MvcApp/
rodrigo@Rodrigos-MacBook-Pro:/tmp/test/MvcApp $ dotnet run
info: Microsoft.Hosting.Lifetime[0]
      Now listening on: https://localhost:5001
info: Microsoft.Hosting.Lifetime[0]
      Now listening on: http://localhost:5000
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]

[rodrmoya]

Forget it, this is due to the MVC project not having the correct AddMvc/MapRazorPages

[bhagyashree19sb]

If my ASP.NET Core web project just references an RCL library that contains a Razor Page, if I try to reference the page using the path that is either "implied" by the Page's directory path (e.g. /MyFeature/Page1 in the default project created by dotnet new razorclasslib) or explicitly specified in the @page directive (e.g. `@page "/testpage"), I get a 404 error.

If however, I also add the Add30AssemblyWorkaround call in my Startup.ConfigureServices, then both scenarios work as expected.

If you would like, I can provide a reference to a sample project. Or perhaps I should wait till preview 7 to retry my scenario.

@ebekker Add30AssemblyWorkaround didn't work for me. Could you please share a reference to the sample project? Thanks in advance.