Uh oh!
There was an error while loading. Please reload this page.
Bump versions of maintenance-packages dependencies consumed in machin… - #7274
Bump versions of maintenance-packages dependencies consumed in machin…#7274carlossanlop wants to merge 3 commits into
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@## main #7274 +/- ##
==========================================
+ Coverage 68.80% 68.90% +0.09%
==========================================
Files 1461 1467 +6 Lines 272400 274380 +1980 Branches 28176 28642 +466 ==========================================
+ Hits 187436 189066 +1630 - Misses 77729 77983 +254 - Partials 7235 7331 +96
Flags with carried forward coverage won't be shown. Click here to find out more. |
carlossanlop
left a comment
There was a problem hiding this comment.
Update to latest versions
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
carlossanlop
commented
Oct 31, 2024
@michaelgsharp there are several dead-lettering failures. Can you take a look? Maybe the VM queues need updating? |
michaelgsharp
commented
Nov 4, 2024
/azp run |
|
Azure Pipelines successfully started running 2 pipeline(s). |
ericstj
commented
Nov 4, 2024
The new version of |
carlossanlop
commented
Nov 4, 2024
I found these two lines hardcoding the package version, which should now be 4.6.0: |
ericstj
commented
Nov 4, 2024
Those are just for testing the analyzer. Here the problem is due to RemoteExecutor. The .dll.config has the correct redirect. If you download the helix payload and examine <dependentAssembly>
<assemblyIdentityname="System.Memory"publicKeyToken="cc7b13ffcd2ddd51"culture="neutral" />
<bindingRedirectoldVersion="0.0.0.0-4.0.2.0"newVersion="4.0.2.0" />
</dependentAssembly>But that .dll.config isn't being reused with RemoteExecutor. |
ericstj
commented
Nov 4, 2024
This same issue was hit here: dotnet/runtime#104647@ViktorHofer mentions that it should be handled with https://github.com/dotnet/arcade/blob/fc2f7ce8372a55725aab7b48c25bad7327a9769d/src/Microsoft.DotNet.RemoteExecutor/src/build/Microsoft.DotNet.RemoteExecutor.targets#L8-L33 -- it looks like ML.NET doesn't use that remote executor, but still uses it's own which may not have the fix. So that's the "right fix" here -- make the ML.NET remoteexecutor honor the tests redirects. If I look at the assembly refs here, most are coming from the |
michaelgsharp
commented
Nov 5, 2024
We don't use the RemoteExecutor in arcade because it doens't support NetFX, so we still have our custom one. Let me take a look at @ViktorHofer's fix and see what it would take to adopt it as well. |
@michaelgsharp RemoteExecutor in Arcade supports .NET Framework. A lot of the tests in runtime target framework and depend on RemoteExecutor. |
michaelgsharp
commented
Nov 11, 2024
Closing as #7295 takes care of it and the remote executor update. |
dotnet/runtime depends on these packages that we are now publishing from dotnet/maintenance-packages:
Bumping their versions to consume the new preview versions, available in the dotnet-libraries feed: https://dnceng.visualstudio.com/public/_artifacts/feed/dotnet-libraries
Related PRs: