Fix VS.Redist versions

[wtgodbe]

Update from 7.0 to 8.0 Doing this on top of #14340 and in a separate branch - if I did it in that PR, darc would overwrite the changes on the next update.

[radical]

Builds are failing with:

 dotnet-install: Attempting to download using primary link https://dotnetcli.azureedge.net/dotnet/Runtime/7.0.0-rc.1.22427.1/dotnet-runtime-7.0.0-rc.1.22427.1-linux-x64.tar.gz
  curl: (22) The requested URL returned error: 404 
  dotnet-install: The resource at primary link 'https://dotnetcli.azureedge.net/dotnet/Runtime/7.0.0-rc.1.22427.1/dotnet-runtime-7.0.0-rc.1.22427.1-linux-x64.tar.gz' is not available.
  dotnet-install: Attempting to download using legacy link https://dotnetcli.azureedge.net/dotnet/Runtime/7.0.0-rc.1.22427.1/dotnet-debian.9-x64.7.0.0-rc.1.22427.1.tar.gz
  curl: (22) The requested URL returned error: 404 
  dotnet-install: The resource at legacy link 'https://dotnetcli.azureedge.net/dotnet/Runtime/7.0.0-rc.1.22427.1/dotnet-debian.9-x64.7.0.0-rc.1.22427.1.tar.gz' is not available.
  dotnet-install: Attempting to download using primary link https://dotnetbuilds.azureedge.net/public/Runtime/7.0.0-rc.1.22427.1/dotnet-runtime-7.0.0-rc.1.22427.1-linux-x64.tar.gz
  curl: (22) The requested URL returned error: 404 
  dotnet-install: The resource at primary link 'https://dotnetbuilds.azureedge.net/public/Runtime/7.0.0-rc.1.22427.1/dotnet-runtime-7.0.0-rc.1.22427.1-linux-x64.tar.gz' is not available.
  dotnet-install: Attempting to download using legacy link https://dotnetbuilds.azureedge.net/public/Runtime/7.0.0-rc.1.22427.1/dotnet-debian.9-x64.7.0.0-rc.1.22427.1.tar.gz
  curl: (22) The requested URL returned error: 404 
  dotnet-install: The resource at legacy link 'https://dotnetbuilds.azureedge.net/public/Runtime/7.0.0-rc.1.22427.1/dotnet-debian.9-x64.7.0.0-rc.1.22427.1.tar.gz' is not available.
  dotnet_install: Error: Could not find `.NET Core Runtime` with version = 7.0.0-rc.1.22427.1
  dotnet_install: Error: Refer to: https://aka.ms/dotnet-os-lifecycle for information on .NET Core support

[radical]

The latest rc1 listed on dotnet/installer is 7.0.0-rc.1.22431.11. Does the version here need to be updated from 7.0.0-rc.1.22427.1 to this?

[marcpopMSFT]

It was failing during the runtime install step of the sdk tests. I'm not sure why the build was fine but tests weren't with this version of rc1 so I switched to the latest one on the download page rather than the latest one in the feeds. Hopefully that one is new enough to have the linker fix and is available for the install scripts.

[lewing]

Target framework from test: net7.0\r\n
Runtime identifier: win10-x64\r\nRuntime Assembly Informational Version: 7.0.0-rc.1.22423.16+430c42acb0eb0481f58d1acb172af346363e2edc\r\n
The execution of a hello world app generated a diff in the number of warnings the app produces\r\n
\r\n
Test output contained the following extra linker warnings:\r\n
+ ILLink : Trim analysis warning IL2026: Internal.Runtime.InteropServices.InMemoryAssemblyLoader.LoadInMemoryAssembly(IntPtr, IntPtr): Using member 'Internal.Runtime.InteropServices.InMemoryAssemblyLoader.LoadInMemoryAssemblyInContextImpl(IntPtr, IntPtr, AssemblyLoadContext)' which has 'RequiresUnreferencedCodeAttribute' can break functionality when trimming application code. C++/CLI is not trim-compatible. https://aka.ms/dotnet-illink/nativehost [D:\a\_work\1\s\artifacts\tmp\Debug\dotnetSdkTests\ILLink_verify---50627DEE\AnalysisWarningsOnHelloWorldApp\AnalysisWarningsOnHelloWorldApp.csproj]\r\n
\r\n
Expected: True\r\n
Actual:   False

cc @jkoritzinsky

[kasperk81]

for 7.0, LoadInMemoryAssembly is changed to LoadInMemoryAssemblyInContextWhenSupported
see fourth commit in dotnet/sdk#27786
@jkurdek

[marcpopMSFT]

@dotnet/source-build-internal the last tarball build failed with the below error. Can you take a look?
/tarball/tools-local/init-build.proj(6,3): warning MSB4011: "/tarball/git-info/AllRepoVersions.props" cannot be imported again. It was already imported at "/tarball/Directory.Build.props (219,3)". This is most likely a build authoring error. This subsequent import will be ignored.

[lewing]

for 7.0, LoadInMemoryAssembly is changed to LoadInMemoryAssemblyInContextWhenSupported see fourth commit in dotnet/sdk#27786 @jkurdek

It is possible I'm confused but it looks like that suppression change went into runtime main but here it is being run (as a tool) against net7 runtime from rc1? Either way something is still wrong

Target framework from test: net7.0\r\n
Runtime identifier: win10-x64\r\n
Runtime Assembly Informational Version: 7.0.0-rc.1.22423.16+430c42acb0eb0481f58d1acb172af346363e2edc\r\n
The execution of a hello world app generated a diff in the number of warnings the app produces\r\n
\r\n
Test output contained the following extra linker warnings:\r\n
+ ILLink : Trim analysis warning IL2026: Internal.Runtime.InteropServices.InMemoryAssemblyLoader.LoadInMemoryAssembly(IntPtr, IntPtr): Using member 'Internal.Runtime.InteropServices.InMemoryAssemblyLoader.LoadInMemoryAssemblyInContextImpl(IntPtr, IntPtr, AssemblyLoadContext)' which has 'RequiresUnreferencedCodeAttribute' can break functionality when trimming application code. C++/CLI is not trim-compatible. https://aka.ms/dotnet-illink/nativehost [D:\a\_work\1\s\artifacts\tmp\Debug\dotnetSdkTests\ILLink_verify---9EAED457\AnalysisWarningsOnHelloWorldApp\AnalysisWarningsOnHelloWorldApp.csproj]\r\n
\r\n
Expected: True\r\n
Actual:   False

[sbomer]

Yes, these tests are running against an older rc1 runtime, with SDK test bits (containing the update by @jkurdek) that expect a newer rc1 runtime. Is there a reason we can't use a consistent version here?

If not, we might be able to get around it by disabling this test (I don't think it represents a product issue), but I don't know what other issues might come up due to the version mismatch. cc @vitek-karas

[marcpopMSFT]

Because rc1 is internal, it wasn't clear what rc1 build we could use. I originally used a newer build but the dotnet-install script couldn't find that build. Once rc1 ships, we can update to the shipping version so we could wait for that.

[lewing]

does rc1 have the runtime change at all?

[lewing]

1. If Remove redundant trimmer warning suppressions runtime#73238 is the change it appears to only be in runtime main
2. Ignoring that, looking at the tests I think both runtimes would pass if the old version was still included in the net7 pass (but I haven't looked closely)
3. I assume those tests should also have a net8.0 case very soon?

[sbomer]

Ah sorry, I was wrong - you're right, looks like the runtime change isn't in rc1. I think mismatch is actually due to using newer main (not rc1) SDK test bits, that are expecting the latest runtime changes from main, while running against an rc1 runtime.

I assume those tests should also have a net8.0 case very soon?

Yes, I think so.

In the SDK repo, those tests are checking linker warnings with a net7.0 framework, even though the framework bits really seem to be the 8.0 bits from main. Is this PR the one that defines the net8.0 TFM? Maybe what needs to happen is:

• Disable the SDK test temporarily because it is getting 8.0 runtime bits when specifying net7.0
• Wait for the net8.0 TFM to be defined and for that to flow into the SDK repo
• Re-enable the test and add a case for net8.0

[lewing]

I opened dotnet/sdk#27866 if that works in sdk I think it will work here (and handle net8.0 for those tests), if not lets disable the test?

[lewing]

waiting for an official build with the change now. @dotnet/source-build-internal tarball build likely still has problems

https://dev.azure.com/dnceng/internal/_build/results?buildId=1992255&view=results

[kasperk81]

i have an idea

• disable source-build ci job and merge this pr to main (without waiting for another run)
• merge main into [main] Update dependencies from dotnet/sdk #14340 and enable source-build ci job

it's been a month since the last daily build. source-build can wait another day or two..

[MichaelSimons]

i have an idea

• disable source-build ci job and merge this pr to main (without waiting for another run)
• merge main into [main] Update dependencies from dotnet/sdk #14340 and enable source-build ci job

it's been a month since the last daily build. source-build can wait another day or two..

I discussed this with the source-build team and we are ok with disabling the tarball build leg. @lbussell will do this shortly and log a follow-up issues to address the current issue and re-enable CI.

[RussKie]

🎉

[kasperk81]

congrats! took a month and last year it took two (#12850). it is an improvement :)

making a new release should not be more complicated than rebranding pr to sdk and the regular coherency update.

[marcpopMSFT]

Looking at the list of work to be done for this, I think we still have templating updates and switching to the shipping 7.0.0 versions once those are available (as well as updating from the rc1 builds we picked):
https://github.com/dotnet/sdk/blob/main/documentation/general/UpdateToNewTargetFramework.md

@wtgodbe @radical @lewing @sbomer @MichaelSimons are there any other steps we should add to the new framework document that are different from last time around (there were some linker and watch test updates as well as having to disable source build temporarily)?

FWIW, I told runtime folks not to ask me about this for a month so I think my estimate was about right. The main problem here is that the SDK would prefer not to fork until October (when most 7.0 work has settled) but runtime needs to fork in August as they need a place to make 8.0 changes.

[sbomer]

I think the root cause of the linker test issue was this logic which replaces the KnownFrameworkReference version when running SDK tests: https://github.com/dotnet/sdk/blob/34d5562b9598ec790d64072c5d22bf4f3ff5c478/src/Layout/toolset-tasks/OverrideAndCreateBundledNETCoreAppPackageVersion.cs#L111-L112.

Before the 8.0 KnownFrameworkReference was defined (and after 8.0 bits flowed from runtime -> SDK), dotnet/sdk tests targeting net7.0 were actually running against 8.0 runtime bits. That doesn't seem like the right thing to do in general. Maybe next time, when flowing the first 9.0 bits from runtime -> SDK, we could temporarily inject a new KnownFrameworkReference for 9.0, instead of overriding the 8.0 version?