Problem description
We recently pinned the version of dotnet that we use in the sentry-dotnet repo. This ensures that when we're building the solution in local development environments we get the same versions of workloads (for things like MAUI) that are used when building the solution in CI. Without this, .NET will roll forward to the latest available workload versions, which can change the behaviour of the resulting application (or even break the builds).
However this may not be the same version of .NET that is installed on the docker containers used by Craft when publishing NuGet packages.
Originally posted by @github-actions in #5421
dotnet: A compatible .NET SDK was not found.
dotnet:
dotnet: Requested SDK version: 9.0.203
dotnet: global.json file: /github/workspace/repo/global.json
This is because when the craft workflow downloads the build artefacts it extracts both the NuGet packages that need publishing and the global.json file that we use for development. So any dotnet commands that Craft tries to execute, at that point, are bound by the constraints specified in the global.json file.
Possible solution
Ultimately craft is trying to publish the (already built) NuGet packages to NuGet and the specific version of dotnet that is used for this operation is unimportant.
We could temporarily disable the global.json file (if present) by renaming it prior to this operation and then re-enable it again afterwards... so something like:
public async uploadAsset(path: string): Promise<any> {
+ mv global.json global.json.disabled
- return spawnProcess(NUGET_DOTNET_BIN, [
+ var result = spawnProcess(NUGET_DOTNET_BIN, [
'nuget',
'push',
path,
'--api-key',
'${NUGET_API_TOKEN}',
'--source',
this.nugetConfig.serverUrl,
]);
+ mv global.json.disabled global.json
+ return result
}
That logic would have to be converted into valid typescript code, of course, but you get the idea.
There doesn't seem to be any other way of disabling global.json when executing a specific command in .NET.
Problem description
We recently pinned the version of dotnet that we use in the sentry-dotnet repo. This ensures that when we're building the solution in local development environments we get the same versions of workloads (for things like MAUI) that are used when building the solution in CI. Without this, .NET will roll forward to the latest available workload versions, which can change the behaviour of the resulting application (or even break the builds).
However this may not be the same version of .NET that is installed on the docker containers used by Craft when publishing NuGet packages.
Originally posted by @github-actions in #5421
This is because when the craft workflow downloads the build artefacts it extracts both the NuGet packages that need publishing and the global.json file that we use for development. So any
dotnetcommands that Craft tries to execute, at that point, are bound by the constraints specified in the global.json file.Possible solution
Ultimately craft is trying to publish the (already built) NuGet packages to NuGet and the specific version of dotnet that is used for this operation is unimportant.
We could temporarily disable the global.json file (if present) by renaming it prior to this operation and then re-enable it again afterwards... so something like:
public async uploadAsset(path: string): Promise<any> { + mv global.json global.json.disabled - return spawnProcess(NUGET_DOTNET_BIN, [ + var result = spawnProcess(NUGET_DOTNET_BIN, [ 'nuget', 'push', path, '--api-key', '${NUGET_API_TOKEN}', '--source', this.nugetConfig.serverUrl, ]); + mv global.json.disabled global.json + return result }That logic would have to be converted into valid typescript code, of course, but you get the idea.
There doesn't seem to be any other way of disabling global.json when executing a specific command in .NET.