Open omajid opened 9 months ago
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.
Perhaps we can use <PathMap>
( https://github.com/dotnet/roslyn/issues/949 ) and/or /deterministic
(https://github.com/dotnet/roslyn/issues/5070) to improve this?
/deterministic
I think we're using deterministic, that's why PE timestamps are in the future.
I took a look in the SDK and there is something called DeterministicSourcePaths
.
At least the name sounds good... I haven't tried using it.
DeterministicSourcePaths
seems to be set as part of building the VMR in source-build mode. From a recent build:
...
Running command:
/home/omajid/devel/dotnet/dotnet/src/runtime/build.sh --restore --build --pack --publish --ci --configuration Release -bl /p:DotNetBuildRepo=true /p:DotN
etBuildOrchestrator=true /p:DotNetBuildSkipTests=true /p:ArcadeBuildFromSource=true /p:PreviouslySourceBuiltNupkgCacheDir="/home/omajid/devel/dotnet/dotnet/p
rereqs/packages/previously-source-built/" /p:ReferencePackageNupkgCacheDir="/home/omajid/devel/dotnet/dotnet/prereqs/packages/reference/" /p:TargetRid=fedora
.39-x64 /p:RuntimeOS=linux /p:BaseOS=linux-x64 /p:PortableBuild=false /p:SourceBuildNonPortable=true /p:UsingToolMicrosoftNetCompilers=false
With Environment Variables:
DOTNET_INSTALL_DIR=/home/omajid/devel/dotnet/dotnet/.dotnet/
DOTNET_PATH=/home/omajid/devel/dotnet/dotnet/.dotnet/
DOTNET_HOST_PATH=/home/omajid/devel/dotnet/dotnet/.dotnet/dotnet
_InitializeDotNetCli=/home/omajid/devel/dotnet/dotnet/.dotnet/
_DotNetInstallDir=/home/omajid/devel/dotnet/dotnet/.dotnet/
_InitializeToolset=/home/omajid/devel/dotnet/dotnet/artifacts/source-built-sdks/Microsoft.DotNet.Arcade.Sdk/tools/Build.proj
_OverrideArcadeInitializeBuildToolFramework=net9.0
DotNetUseShippingVersions=true
PreReleaseVersionLabel=preview.2
PackageVersionStamp=preview.2
ContinuousIntegrationBuild=true
MSBUILDDISABLENODEREUSE=1
OfficialBuildId=20240126.4
BUILD_BUILDNUMBER=20240126.4
GitCommitCount=
GitCommitHash=bcc1d3d6f00fbcea3f454b2e35bceeaa51e604b1
GitInfoCommitHash=bcc1d3d6f00fbcea3f454b2e35bceeaa51e604b1
SourceRevisionId=bcc1d3d6f00fbcea3f454b2e35bceeaa51e604b1
RepositoryCommit=bcc1d3d6f00fbcea3f454b2e35bceeaa51e604b1
COMMIT_SHA=bcc1d3d6f00fbcea3f454b2e35bceeaa51e604b1
GIT_COMMIT=bcc1d3d6f00fbcea3f454b2e35bceeaa51e604b1
RepositoryType=Git
DeterministicSourcePaths=true ### <--- this line
SourceRoot=/home/omajid/devel/dotnet/dotnet/src/runtime/
DotNetBuildFromSourceFlavor=Product
DotNetPackageVersionPropsPath=/home/omajid/devel/dotnet/dotnet/artifacts/obj/x64/Release/PackageVersions.runtime.props
DotNetBuildFromSource=true
SOURCE_BUILT_SDK_ID_ARCADE=Microsoft.DotNet.Arcade.Sdk
SOURCE_BUILT_SDK_ID_ARCADE_SHARED_FX_SDK=Microsoft.DotNet.SharedFramework.Sdk
SOURCE_BUILT_SDK_VERSION_ARCADE=9.0.0-beta.24076.5
SOURCE_BUILT_SDK_VERSION_ARCADE_SHARED_FX_SDK=9.0.0-beta.24076.5
SOURCE_BUILT_SDK_DIR_ARCADE=/home/omajid/devel/dotnet/dotnet/artifacts/source-built-sdks/Microsoft.DotNet.Arcade.Sdk/
SOURCE_BUILT_SDK_DIR_ARCADE_SHARED_FX_SDK=/home/omajid/devel/dotnet/dotnet/artifacts/source-built-sdks/Microsoft.DotNet.SharedFramework.Sdk/
...
Moved out of Servicing
(into Backlog
). This is not something that regressed, it appears to have always be like this.
@tmat do you know who can help us understand the content of RSDS metadata and the expectation for PDB path - should it be a filename only? I believe the path does not matter and is only something that reflects the PDB location at build time.
@ViktorHofer do you know who could help with information about PDB metadata in .NET binaries?
@hoyosjs
DeterministicSourcePaths seems to be set as part of building the VMR in source-build mode. From a recent build:
It looks like in some places the pdb paths are updated, but not in all.
/usr/lib64/dotnet$ strings ./sdk/8.0.101/DotnetTools/dotnet-user-jwts/8.0.1-servicing.23580.8/tools/net8.0/any/Microsoft.IdentityModel.Tokens.dll | grep pdb
/builddir/build/BUILD/dotnet-8.0.1/src/source-build-externals/artifacts/source-build/self/src/src/azure-activedirectory-identitymodel-extensions-for-dotnet/src/Microsoft.IdentityModel.Tokens/obj/Release/netstandard2.0/Microsoft.IdentityModel.Tokens.pdb
/usr/lib64/dotnet$ strings ./shared/Microsoft.NETCore.App/8.0.1/System.Xml.dll | grep pdb
/_/src/runtime/artifacts/source-build/self/src/artifacts/obj/System.Xml/Release/net8.0-linux/System.Xml.pdb
I took a closer look.
To enable a deterministic build, an end-user needs to set ContinuousIntegrationBuild
(which then sets DeterministicSourcePaths
) and build from a place that the SDK can find the git info to do a source mapping.
The vmr build.sh
is taking care of the latter.
For some repos, like runtime, we set ContinuousIntegrationBuild
:
https://github.com/dotnet/runtime/blob/d752f9a19f2d4bc4559e0e303e9374e4042a916e/eng/DotNetBuild.props#L70
Where we still see the original paths, ContinuousIntegrationBuild
is not being set.
Re-testing things with .NET 9 RC 1:
$ grep -rF '/builddir/'
grep: packs/Microsoft.NETCore.App.Host.fedora.40-x64/9.0.0-rc.1.24431.7/runtimes/fedora.40-x64/native/singlefilehost: binary file matches
grep: shared/Microsoft.NETCore.App/9.0.0-rc.1.24431.7/libSystem.Security.Cryptography.Native.OpenSsl.so: binary file matches
grep: shared/Microsoft.NETCore.App/9.0.0-rc.1.24431.7/libclrjit.so: binary file matches
grep: shared/Microsoft.NETCore.App/9.0.0-rc.1.24431.7/libcoreclr.so: binary file matches
grep: shared/Microsoft.NETCore.App/9.0.0-rc.1.24431.7/libmscordaccore.so: binary file matches
grep: shared/Microsoft.NETCore.App/9.0.0-rc.1.24431.7/libmscordbi.so: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/FSharp/FSharp.Compiler.Service.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/Sdks/NuGet.Build.Tasks.Pack/CoreCLR/NuGet.Build.Tasks.Pack.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/Sdks/NuGet.Build.Tasks.Pack/CoreCLR/NuGet.Commands.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/Sdks/NuGet.Build.Tasks.Pack/CoreCLR/NuGet.Common.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/Sdks/NuGet.Build.Tasks.Pack/CoreCLR/NuGet.Configuration.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/Sdks/NuGet.Build.Tasks.Pack/CoreCLR/NuGet.Credentials.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/Sdks/NuGet.Build.Tasks.Pack/CoreCLR/NuGet.DependencyResolver.Core.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/Sdks/NuGet.Build.Tasks.Pack/CoreCLR/NuGet.Frameworks.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/Sdks/NuGet.Build.Tasks.Pack/CoreCLR/NuGet.LibraryModel.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/Sdks/NuGet.Build.Tasks.Pack/CoreCLR/NuGet.Packaging.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/Sdks/NuGet.Build.Tasks.Pack/CoreCLR/NuGet.ProjectModel.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/Sdks/NuGet.Build.Tasks.Pack/CoreCLR/NuGet.Protocol.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/Sdks/NuGet.Build.Tasks.Pack/CoreCLR/NuGet.Versioning.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/Sdks/NuGet.Build.Tasks.Pack/NuGet.Build.Tasks.Pack.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/Sdks/NuGet.Build.Tasks.Pack/NuGet.Commands.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/Sdks/NuGet.Build.Tasks.Pack/NuGet.Common.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/Sdks/NuGet.Build.Tasks.Pack/NuGet.Configuration.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/Sdks/NuGet.Build.Tasks.Pack/NuGet.Credentials.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/Sdks/NuGet.Build.Tasks.Pack/NuGet.DependencyResolver.Core.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/Sdks/NuGet.Build.Tasks.Pack/NuGet.Frameworks.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/Sdks/NuGet.Build.Tasks.Pack/NuGet.LibraryModel.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/Sdks/NuGet.Build.Tasks.Pack/NuGet.Packaging.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/Sdks/NuGet.Build.Tasks.Pack/NuGet.ProjectModel.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/Sdks/NuGet.Build.Tasks.Pack/NuGet.Protocol.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/Sdks/NuGet.Build.Tasks.Pack/NuGet.Versioning.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/Microsoft.Build.NuGetSdkResolver.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/NuGet.Build.Tasks.Console.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/NuGet.Build.Tasks.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/NuGet.CommandLine.XPlat.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/NuGet.Commands.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/NuGet.Common.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/NuGet.Configuration.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/NuGet.Credentials.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/NuGet.DependencyResolver.Core.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/NuGet.Frameworks.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/NuGet.LibraryModel.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/NuGet.Packaging.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/NuGet.ProjectModel.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/NuGet.Protocol.dll: binary file matches
grep: sdk/9.0.100-rc.1.24452.1/NuGet.Versioning.dll: binary file matches
It looks like dlls in the SDK still embed the build directory. The paths embedded in some of the .so files are also surprising.
Describe the Bug
.dll files in .NET SDK/Runtime contain a full path to pdb associated with it, except path corresponds to the original build location, and doesn't match the pdb location when end users install the .NET SDK.
If the path actually matters, shouldn't there be a way to set it to the actual pdb location/path on the end-user systems?
If the path doesn't matter, should it exist at all? Maybe it could just be a file name without the full path?
This also affects reproducibility, because building .NET in a different location changes the built SDK.
Steps to Reproduce
Note the path starting with
/builddir/build/BUILD/
. That's the location the build server used to build NET SDK. That location doesn't exist on my machine.