Is there an existing issue for this?
Describe the bug
When using the aspire update to upgrade a solution to the latest version, the sdk version in the global.json file is not updated.
This applies especially when the Apphost.csproj defines the Aspire.Hosting.Sdk without a version. Like so: <Project Sdk="Aspire.AppHost.Sdk">
Then in the global.json have a definition for:
"msbuild-sdks": {
"Aspire.AppHost.Sdk": "13.2.1"
}
Expected Behavior
I would have expected the version of Aspire to be updated in the msbuild-sdks property of the global.json file.
Steps To Reproduce
No response
Exceptions (if any)
No response
.NET Version info
No response
Anything else?
Considerations:
The global.json could potentially be outside of the actual project's directory. Just like Directory.Build.props or Directory.Packages.props any file that can be reached by searching directories upwards recursively will be used to resolve the Sdk version.
This means updating the global.json from inside the project directory of one Apphost could break a different Apphost by effectifely updating its Sdk version as well.
The same scenario could already happen today with Central Package Management. Breaking a different Apphost by updating another Apphost using the same Directory.Packages.props file.
Is there an existing issue for this?
Describe the bug
When using the
aspire updateto upgrade a solution to the latest version, the sdk version in the global.json file is not updated.This applies especially when the
Apphost.csprojdefines the Aspire.Hosting.Sdk without a version. Like so:<Project Sdk="Aspire.AppHost.Sdk">Then in the global.json have a definition for:
Expected Behavior
I would have expected the version of Aspire to be updated in the
msbuild-sdksproperty of the global.json file.Steps To Reproduce
No response
Exceptions (if any)
No response
.NET Version info
No response
Anything else?
Considerations:
The global.json could potentially be outside of the actual project's directory. Just like
Directory.Build.propsorDirectory.Packages.propsany file that can be reached by searching directories upwards recursively will be used to resolve the Sdk version.This means updating the global.json from inside the project directory of one Apphost could break a different Apphost by effectifely updating its Sdk version as well.
The same scenario could already happen today with Central Package Management. Breaking a different Apphost by updating another Apphost using the same
Directory.Packages.propsfile.