Update SDK to 9.0.100-alpha.1.23421.9 #49911

halter73 · 2023-08-07T23:24:16Z

No description provided.

ghost · 2023-08-07T23:24:29Z

Hey @dotnet/aspnet-build, looks like this PR is something you want to take a look at.

halter73 · 2023-08-08T00:09:14Z

.dotnet/sdk/8.0.100-rc.1.23407.2/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(90,5): error NETSDK1210: (NETCORE_ENGINEERING_TELEMETRY=Restore) IsAotCompatible is not supported for the target framework. Consider multi-targeting to a supported framework to enable ahead-of-time compilation analysis, and set IsAotCompatible only for the supported frameworks. For example:
true

Both this and the efcore SDK update PR are failing to build with this NETSDK1210 error. All of our IsAotCompatible/IsTrimmable projects that have non-net8.0 targets (so netstandard2.0 and net462) fail to build with this error with this SDK update. I'm not sure what change triggered it.

Assuming that these NETSDK1210 errors are legitimate, I could update all our <IsTrimmable> usage to be <IsTrimmable Condition="'$(TargetFramework)' == '$(DefaultNetCoreTargetFramework)'"> or perhaps $([MSBuild]::IsTargetFrameworkCompatible('$(TargetFramework)', $(DefaultNetCoreTargetFramework))) like the error message suggests, but that would be noisy and might mess up the LinkabilityChecker.

wtgodbe · 2023-08-08T00:10:50Z

@sbomer are you aware of any relevant recent changes?

JamesNK · 2023-08-08T00:21:30Z

.dotnet/sdk/8.0.100-rc.1.23407.2/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(90,5): error NETSDK1210: (NETCORE_ENGINEERING_TELEMETRY=Restore) IsAotCompatible is not supported for the target framework. Consider multi-targeting to a supported framework to enable ahead-of-time compilation analysis, and set IsAotCompatible only for the supported frameworks. For example:
true

We don't have IsAotCompatible property anywhere in our source code. Is it implicitly set to true when PublishAot is true?

It's confusing to have an error message about a property that isn't present in source code. SDK should complain about PublishAot if it is what is set.

@eerhardt

halter73 · 2023-08-08T00:29:01Z

The Windows build servers are also failing with a seemingly unrelated error when trying to build some ANCM vcxproj's:

Directory.Build.props(95,31): error MSB4242: (NETCORE_ENGINEERING_TELEMETRY=Restore) SDK Resolver Failure: "The SDK resolver "Microsoft.DotNet.MSBuildSdkResolver" failed while attempting to resolve the SDK "Microsoft.DotNet.Arcade.Sdk". Exception: "System.IO.FileNotFoundException: Could not find file 'D:\a_work\1\s.dotnet\sdk-manifests\8.0.100-rc.1\microsoft.net.workload.emscripten.current\WorkloadManifest.json'.
File name: 'D:\a_work\1\s.dotnet\sdk-manifests\8.0.100-rc.1\microsoft.net.workload.emscripten.current\WorkloadManifest.json'
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share)
at Microsoft.NET.Sdk.WorkloadManifestReader.SdkDirectoryWorkloadManifestProvider.<>c__DisplayClass7_0.b__0()
at Microsoft.NET.Sdk.WorkloadManifestReader.ReadableWorkloadManifest.OpenManifestStream()
at Microsoft.NET.Sdk.WorkloadManifestReader.WorkloadResolver.LoadManifestsFromProvider(IWorkloadManifestProvider manifestProvider)
at Microsoft.NET.Sdk.WorkloadManifestReader.WorkloadResolver.Create(IWorkloadManifestProvider manifestProvider, String dotnetRootPath, String sdkVersion, String userProfileDir)
at Microsoft.NET.Sdk.WorkloadMSBuildSdkResolver.CachingWorkloadResolver.Resolve(String sdkReferenceName, String dotnetRootPath, String sdkVersion, String userProfileDir)
at Microsoft.DotNet.MSBuildSdkResolver.DotNetMSBuildSdkResolver.Resolve(SdkReference sdkReference, SdkResolverContext context, SdkResultFactory factory)
at Microsoft.Build.BackEnd.SdkResolution.SdkResolverService.TryResolveSdkUsingSpecifiedResolvers(IList1 resolvers, Int32 submissionId, SdkReference sdk, LoggingContext loggingContext, ElementLocation sdkReferenceLocation, String solutionPath, String projectPath, Boolean interactive, Boolean isRunningInVisualStudio, SdkResult& sdkResult, IEnumerable1& errors, IEnumerable`1& warnings)""

I'm not sure why ANCM would need an emscripten workload or why it's missing.

eerhardt · 2023-08-08T03:06:30Z

.dotnet/sdk/8.0.100-rc.1.23407.2/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(90,5): error NETSDK1210: (NETCORE_ENGINEERING_TELEMETRY=Restore) IsAotCompatible is not supported for the target framework. Consider multi-targeting to a supported framework to enable ahead-of-time compilation analysis, and set IsAotCompatible only for the supported frameworks. For example:
true

We don't have IsAotCompatible property anywhere in our source code. Is it implicitly set to true when PublishAot is true?

It's confusing to have an error message about a property that isn't present in source code. SDK should complain about PublishAot if it is what is set.

@eerhardt

@sbomer - I believe this is caused by dotnet/sdk#34077. Can you take a look?

sbomer · 2023-08-08T16:24:54Z

It is probably due to EnableAOTAnalyzer being set - I filed dotnet/sdk#34505 about the warning message. The recommendation is to enable the analyzer with IsAotCompatible instead (you could get rid of this workaround: https://github.com/dotnet/aspnetcore/blob/1d6e871b4a171a1d3cd34460d745b8722642b5d5/Directory.Build.targets#L4C1-L5). Then IsAotCompatible will need to be turned on selectively only for the supported TFMs.

halter73 · 2023-08-08T18:00:34Z

I updated Directory.Build.Targets to unset IsTrimmable when not targeting DefaultNetCoreTargetFramework. I tried just conditioning EnableAOTAnalyzer on the target framework or IsAotCompatible without overriding IsTrimmable, but then I still got NETSDK1195 errors.

I'm worried I might disable something important if I remove the workaround at https://github.com/dotnet/aspnetcore/blob/1d6e871b4a171a1d3cd34460d745b8722642b5d5/Directory.Build.targets#L4C1-L5, so I'm leaving that for a follow up.

f0d399e (#49911)

I made a similar change in EF, but for IsAotCompatible instead of IsTrimmable.

dotnet/efcore@1b7f488 (#31423)

halter73 · 2023-08-08T18:14:10Z

We're still getting the following error I mentioned yesterday:

Directory.Build.props(95,31): error MSB4242: (NETCORE_ENGINEERING_TELEMETRY=Restore) SDK Resolver Failure: "The SDK resolver "Microsoft.DotNet.MSBuildSdkResolver" failed while attempting to resolve the SDK "Microsoft.DotNet.Arcade.Sdk". Exception: "System.IO.FileNotFoundException: Could not find file 'D:\a_work\1\s.dotnet\sdk-manifests\8.0.100-rc.1\microsoft.net.workload.emscripten.current\WorkloadManifest.json'

I noticed there was a workload-related failure in the last SDK update (#49761) for a different wasm linking workload, but that seems to have had a different cause. Does anyone know what's going on here? @radical @lewing @joeloff @marcpopMSFT

joeloff · 2023-08-08T18:21:24Z

We're still getting the following error I mentioned yesterday:

Directory.Build.props(95,31): error MSB4242: (NETCORE_ENGINEERING_TELEMETRY=Restore) SDK Resolver Failure: "The SDK resolver "Microsoft.DotNet.MSBuildSdkResolver" failed while attempting to resolve the SDK "Microsoft.DotNet.Arcade.Sdk". Exception: "System.IO.FileNotFoundException: Could not find file 'D:\a_work\1\s.dotnet\sdk-manifests\8.0.100-rc.1\microsoft.net.workload.emscripten.current\WorkloadManifest.json'

I noticed there was a workload-related failure in the last SDK update (#49761) for a different wasm linking workload, but that seems to have had a different cause. Does anyone know what's going on here? @radical @lewing @joeloff @marcpopMSFT

Do you know which workloads are present? Wasm has a dependency on EMSDK and that should get installed as part of installing wasm-tools.

halter73 · 2023-08-08T19:33:07Z

Do you know which workloads are present? Wasm has a dependency on EMSDK and that should get installed as part of installing wasm-tools.

I just ran restore.cmd before and after this SDK update and I noticed a difference to the location where emscripten's WorkloadManifest.json is installed. Before it was .dotnet\sdk-manifests\8.0.100-rc.1\microsoft.net.workload.emscripten.current\WorkloadManifest.json, but after the SDK update it's .dotnet\sdk-manifests\8.0.100-rc.1\microsoft.net.workload.emscripten.current\8.0.0-rc.1.23377.1\WorkloadManifest.json.

Noticed the new 8.0.0-rc.1.23377.1 directory between microsoft.net.workload.emscripten.current and WorkloadManifest.json. And this change isn't limited to just the emscripten workload. It's now like that for every 8.0.100-rc.1 sdk-manifest albiet with different version numbers.

Is this intentional?

joeloff · 2023-08-08T19:38:04Z

It is intentional. The new path is related to workload sets (version and grouping) that's being introduced. @dsplaisted as an FYI

marcpopMSFT · 2023-08-08T20:14:22Z

Are you building using VS/fullframework and what version of VS is used in the builds? We had to make a fix in 17.7-preview5 and it just released 17.7.0 today which may affect this. Can you update to a preview image of VS?

halter73 · 2023-08-08T22:47:20Z

This definitely has something to do with this SDK update and not just the environment considering the main branch and other PRs are still building fine. The latest failing Build.native.binlog for Windows_Test_Logs shows MSBuild version = "17.6.3+07e294721".

This is the first SDK update that the aspnetcore repo has consumed where the WorkloadManifest.json files have been moved to a versioned subfolder, and this appears to be causing arcade's _IsProjectRestoreSupported target to fail for all of our ANCM vcxproj's.

Is MSBuild version 17.6.3 is too old to get the latest changes to SdkDirectoryWorkloadManifestProvider that cause it to look in versioned subfolders for the workload manifests? How do we update it?

@dsplaisted

joeloff · 2023-08-08T22:51:37Z

I believe you need 17.7 and the only way to get that is to move to a different OS image.

halter73 · 2023-08-08T23:06:15Z

Since this is failing in the azure pipeline before we get the chance to see how this affects our helix tests, should I update default-build.yml here?

aspnetcore/.azure/pipelines/jobs/default-build.yml

Lines 124 to 131 in 0b35f03

    
           ${{ if eq(parameters.agentOs, 'Windows') }}: 
        
             ${{ if eq(variables['System.TeamProject'], 'public') }}: 
        
               name: $(DncEngPublicBuildPool) 
        
               demands: ImageOverride -equals 1es-windows-2022-open 
        
             ${{ if eq(variables['System.TeamProject'], 'internal') }}: 
        
               name: $(DncEngInternalBuildPool) 
        
               # Visual Studio Enterprise - contains some stuff, like SQL Server and IIS Express, that we use for testing 
        
               demands: ImageOverride -equals 1es-windows-2022

It looks like we're currently using 1es-windows-2022 and 1es-windows-2022-open. What should we be using?

Will Helix.Common.props need a similar update?

marcpopMSFT · 2023-08-08T23:43:23Z

We use Windows.Amd64.VS2022.Pre.Open for our test runs which pulls in preview versions of VS. For our builds, we don't use full framework so use the same images that you use. Not sure if there is a version with VS as an alternative.

halter73 · 2023-08-09T01:06:23Z

We queue jobs to more than just Windows.Amd64.VS2022.Pre.Open:

aspnetcore/eng/targets/Helix.Common.props

Lines 33 to 34 in 12b48e6

    
           <HelixAvailableTargetQueue Include="Windows.11.Amd64.Client.Open" Platform="Windows" /> 
        
           <HelixAvailableTargetQueue Include="Windows.Amd64.VS2022.Pre.Open" Platform="Windows" />

I'm not sure if the additional Windows Helix queues will be an issue, but first we need to figure out how to get arcade working on the dnceng 1ES agent pools. Right now, it looks like every job using a Windows AzDO agent is failing with this workload resolution error.

wtgodbe · 2023-08-09T16:46:28Z

We only need to update

aspnetcore/.azure/pipelines/jobs/default-build.yml

Lines 124 to 131 in 0b35f03

    
           ${{ if eq(parameters.agentOs, 'Windows') }}: 
        
             ${{ if eq(variables['System.TeamProject'], 'public') }}: 
        
               name: $(DncEngPublicBuildPool) 
        
               demands: ImageOverride -equals 1es-windows-2022-open 
        
             ${{ if eq(variables['System.TeamProject'], 'internal') }}: 
        
               name: $(DncEngInternalBuildPool) 
        
               # Visual Studio Enterprise - contains some stuff, like SQL Server and IIS Express, that we use for testing 
        
               demands: ImageOverride -equals 1es-windows-2022

for now, since the error is just in the build. The tests may be OK. Let's start with that, and additionally run https://dev.azure.com/dnceng-public/public/_build?definitionId=85 against this PR to make sure all our windows test queues are fine. If not we can update those too.

wtgodbe · 2023-08-09T16:47:34Z

One sec, let me figure out what to update to

wtgodbe · 2023-08-09T17:00:24Z

Helix-matrix: https://dev.azure.com/dnceng-public/public/_build/results?buildId=368490&view=results

wtgodbe · 2023-08-09T17:13:14Z

Looks like windows.vs2022preview.amd64.open doesn't have 17.7 yet. @dotnet/dnceng is there an image we can use that will have 17.7, outside of the scouting one? I'd prefer waiting to update the SDK over using the scout queue for our official builds

wtgodbe · 2023-08-28T16:11:31Z

To make things a little bit more interesting, it appears that the PR merging release/8.0 -> main, which contains the SDK update, does not have any of the failures that we are seeing here: #50281.

Perhaps using the preview image pool here wasn't the right idea.

In any case, I'm inclined to let the forward port PR linked above flow and then try another SDK update after that....

I think this is because the breaking change is in main but not 8.0 in the SDK - we'll still be blocked on going to a 9.0 SDK until we can get images with 17.7. @ilyas1974 is there any update on that?

garath · 2023-08-29T18:21:52Z

@ilyas1974 is there any update on that?

No updates yet.

Highlighting a point @dougbu made:

it's [unexpected] to imagine 17.7 GA solving a problem that continues into 17.8p1.

Has that been considered? Is there something in 17.7 that is expected to allow this to work that's not present in 17.8?

wtgodbe · 2023-08-29T19:33:26Z

Checking to see if the error was the same in the 1es images vs the Scout images

wtgodbe · 2023-08-29T19:35:01Z

1es updated from 17.6 to 17.7 yesterday, so this might just work now - I think we need the combination of VS 17.7 (or newer), plus the windows toolsets/native components on the 1es images

wtgodbe · 2023-08-29T19:52:43Z

/azp run

azure-pipelines · 2023-08-29T19:53:16Z

Azure Pipelines successfully started running 3 pipeline(s).

wtgodbe · 2023-08-29T21:32:40Z

Wait until after #50386 is in to resolve the conflict, but it looks like this should work now

wtgodbe · 2023-08-29T23:12:47Z

/azp run

azure-pipelines · 2023-08-29T23:13:03Z

Azure Pipelines successfully started running 3 pipeline(s).

dougbu · 2023-08-29T23:17:24Z

@wtgodbe to confirm: you're not expecting a need for VS 17.7 in the build pools DNCEng provides i.e., the 1es images should now work here❔

wtgodbe · 2023-08-29T23:19:46Z

You're not expecting a need for VS 17.7 in the build pools DNCEng provides i.e., the 1es images should now work here❔

That's right, sorry for the confusion - I mixed up the initial workload error w/ the missing components error. Now that 1es has updated to 17.7 we are good to go

wtgodbe · 2023-08-30T16:30:20Z

Down to a couple test failures:

Microsoft.AspNetCore.WebSockets.Test.WebSocketMiddlewareTests.WebSocket_Abort_Interrupts_Pending_ReceiveAsync

Assert.IsType() Failure
Expected: Microsoft.AspNetCore.Connections.ConnectionAbortedException
Actual: System.ArgumentNullException

   at Microsoft.AspNetCore.WebSockets.Test.WebSocketMiddlewareTests.<>c__DisplayClass16_0.<<WebSocket_Abort_Interrupts_Pending_ReceiveAsync>b__0>d.MoveNext() in /_/src/Middleware/WebSockets/test/UnitTests/WebSocketMiddlewareTests.cs:line 550
--- End of stack trace from previous location ---
   at Microsoft.AspNetCore.WebSockets.Test.KestrelWebSocketHelpers.<>c__DisplayClass0_0.<<CreateServer>b__5>d.MoveNext() in /_/src/Middleware/WebSockets/test/UnitTests/KestrelWebSocketHelpers.cs:line 30
--- End of stack trace from previous location ---
   at Microsoft.AspNetCore.WebSockets.Test.KestrelWebSocketHelpers.<>c__DisplayClass0_0.<<CreateServer>b__5>d.MoveNext() in /_/src/Middleware/WebSockets/test/UnitTests/KestrelWebSocketHelpers.cs:line 38
--- End of stack trace from previous location ---
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequests[TContext](IHttpApplication`1 application) in /_/src/Servers/Kestrel/Core/src/Internal/Http/HttpProtocol.cs:line 676
   at Microsoft.AspNetCore.WebSockets.Test.KestrelWebSocketHelpers.<>c__DisplayClass0_0.<<CreateServer>b__4>d.MoveNext() in /_/src/Middleware/WebSockets/test/UnitTests/KestrelWebSocketHelpers.cs:line 83
--- End of stack trace from previous location ---
   at Microsoft.AspNetCore.WebSockets.Test.WebSocketMiddlewareTests.WebSocket_Abort_Interrupts_Pending_ReceiveAsync() in /_/src/Middleware/WebSockets/test/UnitTests/WebSocketMiddlewareTests.cs:line 576
--- End of stack trace from previous location ---

Microsoft.AspNetCore.WebSockets.Test.WebSocketMiddlewareTests.WebSocket_AllowsCancelling_Pending_ReceiveAsync_When_CancellationTokenProvided

Assert.True() Failure
Expected: True
Actual: False

   at Microsoft.AspNetCore.WebSockets.Test.WebSocketMiddlewareTests.<>c__DisplayClass17_0.<<WebSocket_AllowsCancelling_Pending_ReceiveAsync_When_CancellationTokenProvided>b__0>d.MoveNext() in /_/src/Middleware/WebSockets/test/UnitTests/WebSocketMiddlewareTests.cs:line 614
--- End of stack trace from previous location ---
   at Microsoft.AspNetCore.WebSockets.Test.KestrelWebSocketHelpers.<>c__DisplayClass0_0.<<CreateServer>b__5>d.MoveNext() in /_/src/Middleware/WebSockets/test/UnitTests/KestrelWebSocketHelpers.cs:line 30
--- End of stack trace from previous location ---
   at Microsoft.AspNetCore.WebSockets.Test.KestrelWebSocketHelpers.<>c__DisplayClass0_0.<<CreateServer>b__5>d.MoveNext() in /_/src/Middleware/WebSockets/test/UnitTests/KestrelWebSocketHelpers.cs:line 38
--- End of stack trace from previous location ---
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequests[TContext](IHttpApplication`1 application) in /_/src/Servers/Kestrel/Core/src/Internal/Http/HttpProtocol.cs:line 676
   at Microsoft.AspNetCore.WebSockets.Test.KestrelWebSocketHelpers.<>c__DisplayClass0_0.<<CreateServer>b__4>d.MoveNext() in /_/src/Middleware/WebSockets/test/UnitTests/KestrelWebSocketHelpers.cs:line 83
--- End of stack trace from previous location ---
   at Microsoft.AspNetCore.WebSockets.Test.WebSocketMiddlewareTests.WebSocket_AllowsCancelling_Pending_ReceiveAsync_When_CancellationTokenProvided() in /_/src/Middleware/WebSockets/test/UnitTests/WebSocketMiddlewareTests.cs:line 637
--- End of stack trace from previous location ---

wtgodbe · 2023-08-30T16:31:23Z

@adityamandaleeka could you assign someone to take a look at the WebSocketMiddleware test failures above? Hopefully it's a trivial fix

JamesNK · 2023-08-30T23:53:42Z

I took a look, and the tests passed locally. I added some logging to get information about where the ArgumentNullExceptions originated.

JamesNK · 2023-08-31T00:55:12Z

This is the error message:

[0.007s] [Microsoft.AspNetCore.WebSockets.Test.WebSocketMiddlewareTests] [Error] Unexpected error.
System.ArgumentNullException: Value cannot be null. (Parameter 'buffer.Array')
   at System.Net.WebSockets.WebSocketValidate.ValidateArraySegment(ArraySegment`1 arraySegment, String parameterName)
   at System.Net.WebSockets.ManagedWebSocket.ReceiveAsync(ArraySegment`1 buffer, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.WebSockets.ServerWebSocket.ReceiveAsync(ArraySegment`1 buffer, CancellationToken cancellationToken) in /_/src/Middleware/WebSockets/src/ServerWebSocket.cs:line 58
   at Microsoft.AspNetCore.WebSockets.Test.WebSocketMiddlewareTests.<>c__DisplayClass16_0.<<WebSocket_Abort_Interrupts_Pending_ReceiveAsync>b__0>d.MoveNext() in /_/src/Middleware/WebSockets/test/UnitTests/WebSocketMiddlewareTests.cs:line 528

It looks like what is happening is the test is calling WebSocket.ReceiveAsync with a byte[]. The byte[] is implicitly converted to ArraySegment<byte>. However, for some reason, the inner buffer.Array value in the segment is still null, causing this error.

All the other tests in this file explicitly create the segment, e.g. new ArraySegment<byte>(new byte[1024]), instead of relying on an implicit conversion. I've made that change to the two failing tests, but the bug with the implicit conversion should be looked at.

Moving the buffer to where it is used fixed this. I don't know the cause, but something about the previous method shape caused the error. Probably JIT related.

Edit: Created an issue: dotnet/roslyn#69777
Edit 2: The error is still there. More investigation needed.
Edit 3: Moving the buffer to where it is used - ServerWebSocket.ReceiveAsync - fixed this. An underlying fix should still be made in dotnet/runtime with this dotnet/roslyn#69777

Update SDK to 8.0.100-rc.1.23407.2

fd75dec

halter73 requested review from wtgodbe and a team as code owners August 7, 2023 23:24

ghost added the area-infrastructure Includes: MSBuild projects/targets, build scripts, CI, Installers and shared framework label Aug 7, 2023

Condition IsTrimmable on TargetFramework

f0d399e

Update CodeGen.proj to account for conditional IsTrimmable metadata

71bb235

wtgodbe added 2 commits August 9, 2023 09:49

Update default-build.yml

d3bea24

Update default-build.yml

e15561c

wtgodbe added 2 commits August 29, 2023 12:20

Merge branch 'main' into halter73/update-sdk

1d26266

Update default-build.yml

7869c54

wtgodbe approved these changes Aug 29, 2023

View reviewed changes

wtgodbe enabled auto-merge (squash) August 29, 2023 23:20

JamesNK changed the title ~~Update SDK to 8.0.100-rc.1.23407.2~~ Update SDK to 9.0.100-alpha.1.23421.9 Aug 29, 2023

More logging

d1bc7a9

JamesNK requested review from Tratcher and BrennanConroy as code owners August 30, 2023 23:48

wtgodbe disabled auto-merge August 31, 2023 00:47

Fix

2555a0c

JamesNK mentioned this pull request Aug 31, 2023

ArraySegment<byte> in async method leaves Array null dotnet/roslyn#69777

Closed

Retry?

07836d8

JamesNK merged commit a42669b into main Aug 31, 2023

JamesNK deleted the halter73/update-sdk branch August 31, 2023 04:03

ghost added this to the 9.0-preview1 milestone Aug 31, 2023

Update SDK to 9.0.100-alpha.1.23421.9 #49911

Update SDK to 9.0.100-alpha.1.23421.9 #49911

Conversation

halter73 commented Aug 7, 2023

ghost commented Aug 7, 2023

halter73 commented Aug 8, 2023 • edited Loading

wtgodbe commented Aug 8, 2023

JamesNK commented Aug 8, 2023

halter73 commented Aug 8, 2023

eerhardt commented Aug 8, 2023

sbomer commented Aug 8, 2023

halter73 commented Aug 8, 2023 • edited Loading

halter73 commented Aug 8, 2023

joeloff commented Aug 8, 2023

halter73 commented Aug 8, 2023

joeloff commented Aug 8, 2023

marcpopMSFT commented Aug 8, 2023

halter73 commented Aug 8, 2023

joeloff commented Aug 8, 2023

halter73 commented Aug 8, 2023

marcpopMSFT commented Aug 8, 2023

halter73 commented Aug 9, 2023

wtgodbe commented Aug 9, 2023

wtgodbe commented Aug 9, 2023

wtgodbe commented Aug 9, 2023

wtgodbe commented Aug 9, 2023

wtgodbe commented Aug 28, 2023

garath commented Aug 29, 2023

wtgodbe commented Aug 29, 2023

wtgodbe commented Aug 29, 2023

wtgodbe commented Aug 29, 2023

azure-pipelines bot commented Aug 29, 2023

wtgodbe commented Aug 29, 2023

wtgodbe commented Aug 29, 2023

azure-pipelines bot commented Aug 29, 2023

dougbu commented Aug 29, 2023

wtgodbe commented Aug 29, 2023

wtgodbe commented Aug 30, 2023

wtgodbe commented Aug 30, 2023 • edited Loading

JamesNK commented Aug 30, 2023

JamesNK commented Aug 31, 2023 • edited Loading

halter73 commented Aug 8, 2023 •

edited

Loading

halter73 commented Aug 8, 2023 •

edited

Loading

wtgodbe commented Aug 30, 2023 •

edited

Loading

JamesNK commented Aug 31, 2023 •

edited

Loading