Likely a result of the migration to the new JSON APIs
{
"runtimeTarget": {
"name": ".NETCoreApp,Version=v3.0",
"signature": ""
},
"compilationOptions": {},
"targets": {
".NETCoreApp,Version=v3.0": {
"ConsoleApp1/1.0.0": {
"runtime": {
"ConsoleApp1.dll": {}
}
}
}
},
"libraries": {
"ConsoleApp1/1.0.0": {
"type": "project",
"serviceable": false,
"sha512": ""
}
}
}
cc @ahsonkhan @nguerrera
Cc @dsplaisted
Does this have any impact? Are there supposed to be compilation options recorded in this case?
No functionality impact but it should be cleaned up as it's unnecessary and frankly strange to see.
Likely a result of the migration to the new JSON APIs
I don't think the migration affected this. At least, looking at the tests, this was by-design before too:
https://github.com/dotnet/sdk/blob/b73819e683af64bd19c961973c77b2239cd20e5d/src/Tasks/Microsoft.NET.Build.Tasks.UnitTests/GivenADependencyContextBuilder.cs#L63
Make a new console app with .net core 2.1 or 2.2, does it have the compilationOptions?
Just tried it with an old 2.1.4xx sdk and a 2.1 app. It does the same thing. Seems it's always been this way.
Omg then we should fix it...
I'd like to see the empty signature node removed too. That isn't used by anything, it's an artifact of some servicing thing before my time that never saw the light of day. Also, the empty sha512...
We use the Microsoft.Extensions.DependencyModel APIs to write the deps file, so it's likely that we'd need a change in that library in order to make these changes.
That's right. This is coming from the DependencyModel. Is the plan here to remove CompilationOptions from the DependencyModel entirey because this thing is never used or just to not create the empty node?
AFAIK there are still some scenarios where CompilationOptions is used, so the proposal would be to not include it in the deps file if it's empty.