Print an error when MvcRazorFilesToCompile is empty

[guylando]

I added the precompilation package and csproj tag and when I publish the main project I get the error:

bin\Release\net451\Microsoft.AspNetCore.Mvc.Razor.ViewCompilation.exe @"obj\Release\net451\microsoft.aspnetcore.mvc.razor.viewcompilation.rsp"
EXEC(6,49): Error CS0826: No best type found for implicitly-typed array
EXEC(6,49): Error CS1503: Argument 1: cannot convert from '?[]' to 'System.Collections.Generic.IReadOnlyList<Microsoft.AspNetCore.Mvc.ApplicationParts.ViewInfo>'
C:\Users\XXX\.nuget\packages\microsoft.aspnetcore.mvc.razor.viewcompilation\1.1.0-msbuild4-final\build\net451\Microsoft.AspNetCore.Mvc.Razor.ViewCompilation.targets(36,5): Error MSB3073: The command "bin\Release\net451\Microsoft.AspNetCore.Mvc.Razor.ViewCompilation.exe @"obj\Release\net451\microsoft.aspnetcore.mvc.razor.viewcompilation.rsp"" exited with code 1.

I have a solution with a couple of projects where the views are separated to a different project than the main project. Does the views precompilation supports such a situation? Is this related to the error?
Do you recognize this error or encountered it before and have a workaround?

[Eilon]

Hi @guylando , I think that the scenario you describe should work.

Can you please share your project, or at least the relevant parts of your csproj file? Also, if you can share the generated obj\Release\net451\microsoft.aspnetcore.mvc.razor.viewcompilation.rsp file that would help as well.

[Eilon]

Closing because we don't have enough information to reproduce.

[henkmollema]

@Eilon I'm running into this issue too after I've migrated to MSBuild. It worked using project.json tooling.

I have a class library with views which I want to precompile and embed into the assembly to consume them in multiple applications. This scenario is similar to what is begin tested in this repo with these projects:
ClassLibraryWithPrecompiledViews and ApplicationUsingPrecompiledViewClassLibrary.

The csproj of my class library looks like this:

<Project Sdk="Microsoft.NET.Sdk">
  <Import Project="..\..\common.props" />
  <PropertyGroup>
    <TargetFramework>netcoreapp1.1</TargetFramework>

    <PreserveCompilationContext>true</PreserveCompilationContext>
    <OutputType>Exe</OutputType>
    <MvcRazorOutputPath Condition="'$(TargetFramework)'!=''">obj\precompiled\$(TargetFramework)</MvcRazorOutputPath>    
  </PropertyGroup>

  <ItemGroup>
    <Content Include="obj\precompiled\**\*" Pack="true" PackagePath="lib\%(RecursiveDir)%(FileName)%(Extension)" />
  </ItemGroup>
  
  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.1.2" />
    <PackageReference Include="Microsoft.AspNetCore.Mvc.Razor.ViewCompilation" Version="1.1.0" PrivateAssets="All" />
  </ItemGroup>

  <Target Name="PrecompileRazorViews" AfterTargets="Build" DependsOnTargets="MvcRazorPrecompile" Condition="'$(TargetFramework)'!=''" />
</Project>

When I call dotnet build on this project I receive the same error as @guylando. Except for that fact that I'm using a .netcoreapp1.1 target framework, the error is the same.

My microsoft.aspnetcore.mvc.razor.viewcompilation.rsp file:

C:\src\App\src\MyTemplatesApp
--output-path=obj\precompiled\netcoreapp1.1\
--application-name=MyTemplatesApp
--content-root=C:\src\App\src\MyTemplatesApp
--file=

.NET Core version:

λ dotnet --info
.NET Command Line Tools (1.0.0)

Product Information:
 Version:            1.0.0
 Commit SHA-1 hash:  e53429feb4

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.14393
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\1.0.0

[henkmollema]

I was thinking, do the 1.1 runtime packages of this even work with MSBuild tooling?

[henkmollema]

I guess the problem is that the --file= part is empty. My templates are in this folder structure (starting from the root):

/Templates
  /Controls
    /Textbox.cshtml
    /Dropdown.cshtml
  /SomeOtherTemplate.cshtml

[henkmollema]

@Eilon @guylando I guess I found the issue. When I use the Web SDK it seems to work:

<Project Sdk="Microsoft.NET.Sdk.Web">

Probably there is some magic in there that makes this work.

[pranavkm]

@henkmollema Thanks for looking in to this at depth. The Microsoft.Net.Sdk.Web marks cshtml files as Compile which is what we look for
https://github.com/aspnet/MvcPrecompilation/blob/dev/src/Microsoft.AspNetCore.Mvc.Razor.ViewCompilation/build/common.targets#L15.

@Eilon, we should fail more gracefully when we can't find any cshtml files to compile. Let's use this work item to track it.

[henkmollema]

Thanks @pranavkm. That makes sense.

[Eilon]

Is it actually an error to have no CSHTML files? Perhaps a warning would make more sense?

[Eilon]

cc @DamianEdwards for thoughts.

[pranavkm]

Perhaps a warning would make more sense?

Yeah, that would be fine.

Precompilation is enabled, but no cshtml files were found. Set ... in your project to specify the views to compile.

[Eilon]

@ajaybhargavb / @pranavkm - @danroth27 just tried publishing a new default Web API project with 2.0 and didn't see any error/warning/anything. Was this maybe fixed by some other change in recent history?

[pranavkm]

Wouldn't we want to print a warning though (at least that's what I assumed we wanted to do here)

[Eilon]

When @danroth27 and I were talking, we were wondering if the correct behavior is to be silent. What exactly would we be warning the user about? What would they "fix" to avoid this?

Imagine a pure Web API project, which of course has no views, but also has view pre-compilation enabled (because it's enabled by the SDK by default). It doesn't make sense to have a warning in that case, does it?

[pranavkm]

I guess that makes sense. Perhaps it's best to get some more feedback to see if it's something people keep running in to and decide accordingly (maybe an MSBuild info log or something along those lines).

[Eilon]

So are we good to close this for now? No warnings/errors are ever shown?

[Eilon]

@pranavkm - can you confirm that's what you're seeing on the latest dev bits?

[pranavkm]

Verified this no longer prints an error. We produce a <App Name>.PrecompiledViews.dll, but it's empty. No runtime exceptions either, so this should be good to close.