We have identified a regression between project.json and csproj which is preventing users from generating deterministic build outputs.
Because this issue prevents us from providing deterministic build outputs, we will need to fix it at some point. I’d rather fix it in 1.0 RTM, before the change becomes breaking relative to 1.0.
Background
What we had in Project.json
In project.json the CLI would append the RID to a project’s output path if the output contained RID-specific artifacts. This meant that:
Portable Project
These would output to:
<projdir>/bin/Debug/{TFM}/
RID-Specific project
These would output to:
<projdir>/bin/Debug/{TFM}/{RID}/
What we have in csproj
Portable Project
These would output to:
<projdir>/bin/Debug/{TFM}/
RID-Specific project
These would output to:
<projdir>/bin/Debug/{TFM}/
What’s the issue?
In the new SDK we do not have a unique output path for common build configurations. Consider these scenarios:
- Portable Project
- Multi-TFM project
- dotnet build –framework=netcoreapp1.0
- dotnet build –framework=netcoreapp1.1
- Multi-RID project
- dotnet build –runtime=win7-x64
- dotnet build –runtime=win7-x86
In the first two project types, everything is fine. The portable project has but a single output. The multi-TFM project has two outputs, but each goes into a TMF-specific directory.
The Multi-RID project is the problem. Both of those build invocations will result in outputs being generated into the same directory, despite the outputs being meaningfully different!
What is worse, this error will likely occur silently. Our own incrementality checks will assume that the x86 build produced valid outputs for x64 and will simply return.
How to fix?
We already have a property, AppendRuntimeIdentifierToOutputPath, that is defaulted to ‘false’. We would like, instead, to set this property to true by default IFF the current build has a RuntimeIdentifier specified. This will provide a unique output path for every build gesture advertised to users. It will also simplify fixes for several race condition style bugs that we’re facing because RIDs do not have unique output paths.
What’s the risk?
Early adopters of the SDK [anyone using it so far] may have dependencies on the output path of their RID-specific builds. They will have two recourses once this change is made:
a. Update their dependencies to use the new output path
b. Set AppendRuntimeIdentifierToOutputPath=false in their csproj/on the cmd line
/cc @srivatsn @MattGertz @nguerrera @dsplaisted
We have identified a regression between project.json and csproj which is preventing users from generating deterministic build outputs.
Because this issue prevents us from providing deterministic build outputs, we will need to fix it at some point. I’d rather fix it in 1.0 RTM, before the change becomes
breaking relative to 1.0.Background
What we had in Project.json
In
project.jsonthe CLI would append the RID to a project’s output path if the output contained RID-specific artifacts. This meant that:What we have in csproj
What’s the issue?
In the new SDK we do not have a unique output path for common build configurations. Consider these scenarios:
In the first two project types, everything is fine. The portable project has but a single output. The multi-TFM project has two outputs, but each goes into a TMF-specific directory.
The Multi-RID project is the problem. Both of those
buildinvocations will result in outputs being generated into the same directory, despite the outputs being meaningfully different!What is worse, this error will likely occur silently. Our own incrementality checks will assume that the x86 build produced valid outputs for x64 and will simply return.
How to fix?
We already have a property,
AppendRuntimeIdentifierToOutputPath, that is defaulted to ‘false’. We would like, instead, to set this property totrueby default IFF the current build has aRuntimeIdentifierspecified. This will provide a unique output path for every build gesture advertised to users. It will also simplify fixes for severalrace conditionstyle bugs that we’re facing because RIDs do not have unique output paths.What’s the risk?
Early adopters of the SDK [anyone using it so far] may have dependencies on the output path of their RID-specific builds. They will have two recourses once this change is made:
a. Update their dependencies to use the new output path
b. Set AppendRuntimeIdentifierToOutputPath=false in their csproj/on the cmd line
/cc @srivatsn @MattGertz @nguerrera @dsplaisted