F# project deps file has entry entry in defines causing a compilation failure
See original GitHub issueApologies if this is not the right home, I’m trying to find the correct routing for this issue.
Using an FSharp project, the `.deps.json file contains:
{
"runtimeTarget": {
...
},
"compilationOptions": {
"defines": [
"",
"TRACE",
"DEBUG",
"NETCOREAPP2_0"
],
...
},
When we read the deps file and hand this off to Roslyn, the result is a compilation error:
Microsoft.AspNetCore.Mvc.Razor.Compilation.CompilationFailedException: One or more compilation failures occurred:
fdw11r2q.auy(1,1): error CS8301: Invalid name for a preprocessing symbol; '' is not a valid identifier
at Microsoft.AspNetCore.Mvc.Razor.Internal.RazorViewCompiler.CompileAndEmit(RazorCodeDocument codeDocument, String generatedCode)
at Microsoft.AspNetCore.Mvc.Razor.Internal.RazorViewCompiler.CompileAndEmit(String relativePath)
Removing the ‘empty define’ by editing the deps file makes compilation succeed.
We set up the compilation options by using the DependencyContext
to read the deps file: https://github.com/aspnet/Mvc/blob/dev/src/Microsoft.AspNetCore.Mvc.Razor/Internal/DependencyContextRazorViewEngineOptionsSetup.cs
This was working until recently, and we have working setups that do contain the ‘empty define’.
But it still doesn’t seem right to have an empty define since that is illegal. I think the F# SDK is doing something wrong.
Dependency model version: 2.0.0-preview2-25407-01
dotnet --info
.NET Command Line Tools (2.0.0-preview2-006492)
Product Information:
Version: 2.0.0-preview2-006492
Commit SHA-1 hash: 7ab3d5b8d8
Runtime Environment:
OS Name: Windows
OS Version: 10.0.15063
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\2.0.0-preview2-006492\
Microsoft .NET Core Shared Framework Host
Version : 2.0.0-preview2-25407-01
Build : 40c565230930ead58a50719c0ec799df77bddee9
Issue Analytics
- State:
- Created 6 years ago
- Comments:8 (7 by maintainers)
Top GitHub Comments
We could also add a safe-guard for this type of error in the future by using
StringSplitOptions.RemoveEmptyEntries
here:https://github.com/dotnet/sdk/blob/master/src/Tasks/Microsoft.NET.Build.Tasks/CompilationOptionsConverter.cs#L20
Looks like ‘no’. I added https://github.com/dotnet/sdk/issues/1628