View compilation fails when cross-compiling for Linux on Windows

[Daniel15]

1. Use Visual Studio to create a new ASP.NET Core Web Application (.NET Framework). Note: Not .NET Core, as I'm running my site on Mono with the full .NET Framework.
2. Add NuGet reference to Microsoft.AspNetCore.Mvc.Razor.ViewCompilation version 1.1.0
3. Modify the csproj to add:

<MvcRazorCompileOnPublish>true</MvcRazorCompileOnPublish>

4. Run

dotnet restore -r debian-x64
dotnet publish . -o "C:\temp\ViewPrecompilationBug_Deploy" -c Release -r debian-x64

Expected: Publish works as expected
Actual: Error is thrown:

C:\temp\ViewPrecompilationBug\ViewPrecompilationBug
λ dotnet publish . -o "C:\temp\ViewPrecompilationBug_Deploy" -c Release -r debian-x64
Microsoft (R) Build Engine version 15.1.548.43366
Copyright (C) Microsoft Corporation. All rights reserved.

  ViewPrecompilationBug -> C:\temp\ViewPrecompilationBug\ViewPrecompilationBug\bin\Release\net452\debian-x64\ViewPrecompilationBug.exe
  'bin\Release\net452\debian-x64\Microsoft.AspNetCore.Mvc.Razor.ViewCompilation.exe' is not recognized as an internal or external command,
  operable program or batch file.
C:\Users\Daniel\.nuget\packages\microsoft.aspnetcore.mvc.razor.viewcompilation\1.1.0\build\net451\Microsoft.AspNetCore.Mvc.Razor.ViewCompilation.targets(36,5): error MSB3073: The command "bin\Release\net452\debian-x64\Microsoft.AspNetCore.Mvc.Razor.ViewCompilation.exe @"obj\Release\net452\debian-x64\microsoft.aspnetcore.mvc.razor.viewcompilation.rsp"" exited with code 9009. [C:\temp\ViewPrecompilationBug\ViewPrecompilationBug\ViewPrecompilationBug.csproj]

[Daniel15]

Here's my hacky workaround: Build first for Windows, then build for Linux with view precompilation disabled, then copy across the PrecompiledViews assembly:

dotnet restore
dotnet publish -o "C:\TempPublish\site_win" -c Release
dotnet restore -r debian-x64
dotnet publish -o "C:\TempPublish\site" -c Release -r debian-x64 /p:MvcRazorCompileOnPublish=false

copy c:\TempPublish\site_win\Daniel15.Web.PrecompiledViews.dll c:\TempPublish\site\
rd /s /q c:\TempPublish\site\Views

[davidfowl]

None of the toolchain natively supports mono anymore. You'll hit edges like this all over the stack. The "fix here" is to have the driver invoke mono {exe} when running on Linux and targeting net4x

[Daniel15]

@davidfowl - I'm not running the tools on Mono, I'm only running the published website on Mono (which works fine). I'm running those dotnet restore and dotnet publish commands on the regular .NET Framework on Windows 10.

[pranavkm]

Sort of related to #72. I'll speak to @Eilon about what we need to do about these class of issues.

[simsod]

Just want to add that this also occurs when trying to publish for windows on osx.
ie: dotnet publish -r win7-x64
On osx sierra (osx.10.12-x64)

And to clarify, Mono is not involved at all, target is netcoreapp1.1

[karl-sjogren]

To expand a bit on what @simsod said. We are building this on OSX to be deployed on a Windows server.

dotnet publish -r osx.10.11-x64 gives the following output:

Microsoft (R) Build Engine version 15.1.548.43366
Copyright (C) Microsoft Corporation. All rights reserved.

  Saga.Web.Core -> /Users/karl/src/Saga/Saga.Web/src/Saga.Web.Core/bin/Debug/netstandard1.6/Saga.Web.Core.dll

  Saga.Web -> /Users/karl/src/Saga/Saga.Web/src/Saga.Web/bin/Debug/netcoreapp1.1/osx.10.11-x64/Saga.Web.dll
  Razor view compilation for Saga.Web -> obj/Debug/netcoreapp1.1/osx.10.11-x64/Saga.Web.PrecompiledViews.dll

dotnet publish -r win7-x64 on the other hand crahes like this:

Microsoft (R) Build Engine version 15.1.548.43366
Copyright (C) Microsoft Corporation. All rights reserved.

  Saga.Web.Core -> /Users/karl/src/Saga/Saga.Web/src/Saga.Web.Core/bin/Debug/netstandard1.6/Saga.Web.Core.dll

  Saga.Web -> /Users/karl/src/Saga/Saga.Web/src/Saga.Web/bin/Debug/netcoreapp1.1/win7-x64/Saga.Web.dll
  Could not resolve CoreCLR path. For more details, enable tracing by setting COREHOST_TRACE environment variable to 1
/Users/karl/.nuget/packages/microsoft.aspnetcore.mvc.razor.viewcompilation/1.1.0/build/netcoreapp1.1/Microsoft.AspNetCore.Mvc.Razor.ViewCompilation.targets(25,5): error MSB3073: The command "dotnet exec --runtimeconfig "/Users/karl/src/Saga/Saga.Web/src/Saga.Web/bin/Debug/netcoreapp1.1/win7-x64/Saga.Web.runtimeconfig.json" --depsfile "/Users/karl/src/Saga/Saga.Web/src/Saga.Web/bin/Debug/netcoreapp1.1/win7-x64/Saga.Web.deps.json" "/Users/karl/.nuget/packages/microsoft.aspnetcore.mvc.razor.viewcompilation/1.1.0/build/netcoreapp1.1/../../lib/netcoreapp1.1/Microsoft.AspNetCore.Mvc.Razor.ViewCompilation.dll" @"obj/Debug/netcoreapp1.1/win7-x64/microsoft.aspnetcore.mvc.razor.viewcompilation.rsp"" exited with code 135. [/Users/karl/src/Saga/Saga.Web/src/Saga.Web/Saga.Web.csproj]

If test it out on a Windows 10 machine the opposite things work (ie win7-x64 compiles fine and osx.10.11-x64 fails with a similar error). If I disable viewcompilation everything is fine on both environments.

This worked fine using the old tooling (project.json) using the same version of Microsoft.AspNetCore.Mvc.Razor.ViewCompilation (ie 1.1.0).

[pranavkm]

@karl-sjogren, would you mind filing a separate issue for your thing? The original issue is about trying to target desktop (net4x) on cross-plat environments. In general, targeting mono isn't a supported scenario. There might be a few knobs that might attempt to make it work, but none of it is designed to work out of the box. Your scenario is different, trying to publish a standalone for a rid that doesn't match the current OS. That's supported but we did not think about it enough when designing the tool.

[Daniel15]

@simsod @karl-sjogren - The same workaround that I'm using might work for your use case too: Build for the "current" platform, then build for the destination platform with view precompilation disabled, then copy across the PrecompiledViews assembly.

dotnet restore
dotnet publish -o /tmp/publish/ -c Release
dotnet restore -r win7-x64
dotnet publish -o /tmp/publish_win/ -c Release -r win7-x64 /p:MvcRazorCompileOnPublish=false
cp /tmp/publish/Foo.PrecompiledViews.dll /tmp/publish_win/
rm -rf /tmp/publish_win/views/

It's a bit slower as it builds the site twice, I couldn't get view precompilation working without doing a full build though (running the ViewCompilation assembly directly just threw an error)

[karl-sjogren]

@pranavkm Sorry, I missed that he said mono and not netcore (not sure how I missed that). The error just looked so much like ours. I'll file a separate bug tomorrow when I get in at work.

[grzegorz-ogrodowski]

Any news in this topic?
I have similar problem.

[pranavkm]

Sorry, not as yet. We need to rethink some of the design for how the tool works and haven't had a chance to set up a meeting with the relevant folks as yet. We'll have this triaged for our next milestone - preview3.

[Eilon]

⬆️🏈⬆️ Moving to 2.1.0 because in 2.0.0 w/ runtime stores the size of apps is a lot smaller anyway.

The fix is for the precompilation task to build the user's app and run it w/o the specified RID so that the code can run properly on the local machine.

[los93sol]

Any movement on this? I'm compiling for win10-arm to run on iOT Core Pi3 and it's pretty painful waiting for that device to compile the views at runtime

[pranavkm]

@los93sol - we're still wrapping up 2.0.0 stuff. The work item was moved to the 2.1.0 release. For the time being, the workaround @Daniel15 has in #102 (comment) might alleviate some of your issues.

[wilson0x4d]

is precompilation required for Razor pages to work, ie. is this really a required/necessary step in the tools, and also, is it necessary to double-build just to publish and test cross-platform?

[los93sol]

It is not necessary for development but is absolutely necessary to put something into production, otherwise your site will take several minutes for the first load. Subsequent loads are fast since the views are compiled at that point, but once your app recycles the first load will be brutally slow again.

[Eilon]

@wilson0x4d precompilation is never "required," but it can indeed improve runtime performance. Though, I've never seen that without precompiling an application that it would take "several minutes" for the first load. Views are compiled on-demand, so unless the first request uses thousands of views (many layout pages, partial views, view components, etc.), it should take only a few seconds to compile the first few views.... and then another few milliseconds for each additional view. The first view to be compiled has the overhead of loading the compiler, and that's typically just a few seconds.