Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move nuget from version 6.4.2 to 6.4.3 #14509

Merged
merged 11 commits into from
Feb 29, 2024
Merged

Conversation

chcosta
Copy link
Member

@chcosta chcosta commented Feb 23, 2024

@chcosta
Copy link
Member Author

chcosta commented Feb 23, 2024

Test failure needs investigation. Closing this PR and moving the issue to the backlog, it will need to be picked up by someone else.

… are caused by this setting or by some kind of issue with the version of the SDK actually downloaded.

If the issue is with the actual SDK install operation then it is expected that the 7.0.116 version of the SDK will not exist and we should see a different type of failure message like directory not found.
NOTE: When the value is hard coded all test for the CI build passed. However, I don't believe we should be hard coding this value to address the build breaks and should instead discover where the incorrect 8.0 value settings are coming from.
Forcing the value of DotNetCliVersion to be empty to see how the system behaves if valid package type is set or there is no known version information for the package type parameter is passed in.

The expectation is having a empty value will result in some kind of null reference error when trying to access .Net Core SDK data.

If the value does not control the actual SDK install and or use it will also let us know if the version test script that is failing is doing a simple string comparison as opposed to examining the actual SDK being used. If it IS doing a simple string comparison the expectation is that the output of the failure will not show an empty value for the current .Net CORE SDK in the mismatch error rather than SDK version that is actually installed.
Hard coding the DotNetCliVersion value when DotNetCliPackageType is RUNTIME.

If the tests pass it will let us know our root issue involves the setting for BundledNETCoreAppPackageVersion being passed in to the process.
Hard Coding DotNetCliVersion for SDK package types to '7.0.116'.

Because hard coding the value for RUNTIM package types failed with the same version mismatch error the expectation is that this CI build should pass all tests, which will confirm that the root issue is the passed in value for NETCoreSdkVersion.
…Type is set to SDK to restore the DotNetCli.props file to its original state.

Based on the tests performed the bad .Net Core SDK state occurs when the this props file is used with the DotNetCliPackageType set to SDK and NETCoreSdkVersion set to 8.0.200.
… for SDK packages per guidance from Christopher Costa
global.json Outdated
@@ -1,4 +1,8 @@
{
"sdk": {
"version": "7.0.116",
"rollForward": "disable"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit, to be more consistent w/ at least release/6.0 (where we've avoided this issue):

Suggested change
"rollForward": "disable"
"rollForward": "latestFeature"

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also suggest porting this update to release/8.0 and main. we'll be scratching our heads again too soon otherwise

…be consistent with other branch settings based on guidance from Christopher Costa.
@chcosta
Copy link
Member Author

chcosta commented Feb 29, 2024

🚢

@davfost davfost merged commit 0f00762 into dotnet:release/7.0 Feb 29, 2024
19 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants