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.

Sign up for GitHub

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

Jump to bottom

[msbuild] Fix creating Build.zip. #16445

Merged
merged 1 commit into from
Oct 25, 2022
Merged

[msbuild] Fix creating Build.zip. #16445

merged 1 commit into from
Oct 25, 2022

Conversation

rolfbjarne
Copy link
Member

We recently switched from building the msbuild tasks with 'msbuild' to use
'dotnet build' instead.

One difference between the two methods is that 'dotnet build' doesn't copy
referenced assemblies to the output path.

This turns out to be a problem because we zip up the output from the
Xamarin.Messaging.Build project, and expect it to contain everything required
to load the Xamarin.Messaging.Build assembly (this zip file is shipped with
our VS (Windows) support, and during remote execution copied to the connected
mac and then the build from Windows will load the assembly on the Mac in order
to do stuff on the Mac).

Another problem is that we include MSBuild assemblies from the
'$(MSBuildBinPath)' location, which is now different (we used to pick up
Mono's MSBuild assemblies, and that changed when we started building with
.NET).

In other words: because the Build.zip file stopped containing all the required
files to load Xamarin.Messaging.Build.dll, remote builds from VS stopped
working.

Ref: #16418

Here we attempt to fix this by:

  • Setting 'CopyLocalLockFileAssemblies=true'. This will copy referenced
    assemblies to the output directory.
  • Explicitly referencing Mono's MSBuild assemblies instead of relying upon
    finding them in '$(MSBuildBinPath)'. At this point I believe it's fine to
    hardcode Mono's path, since it's unlikely we'll get any new Mono updates.

@rolfbjarne
[msbuild] Fix creating Build.zip.
fc471a6 
We recently switched from building the msbuild tasks with 'msbuild' to use
'dotnet build' instead.

One difference between the two methods is that 'dotnet build' doesn't copy
referenced assemblies to the output path.

This turns out to be a problem because we zip up the output from the
Xamarin.Messaging.Build project, and expect it to contain everything required
to load the Xamarin.Messaging.Build assembly (this zip file is shipped with
our VS (Windows) support, and during remote execution copied to the connected
mac and then the build from Windows will load the assembly on the Mac in order
to do stuff on the Mac).

Another problem is that we include MSBuild assemblies from the
'$(MSBuildBinPath)' location, which is now different (we used to pick up
Mono's MSBuild assemblies, and that changed when we started building with
.NET).

In other words: because the Build.zip file stopped containing all the required
files to load Xamarin.Messaging.Build.dll, remote builds from VS stopped
working.

Ref: xamarin#16418

Here we attempt to fix this by:

* Setting 'CopyLocalLockFileAssemblies=true'. This will copy referenced
  assemblies to the output directory.
* Explicitly referencing Mono's MSBuild assemblies instead of relying upon
  finding them in '$(MSBuildBinPath)'. At this point I believe it's fine to
  hardcode Mono's path, since it's unlikely we'll get any new Mono updates.
@rolfbjarne rolfbjarne added the not-notes-worthy Ignore for release notes label Oct 25, 2022
@vs-mobiletools-engineering-service2
Copy link
Collaborator

✅ API diff for current PR / commit

Legacy Xamarin (No breaking changes)
  • iOS (no change detected)
  • tvOS (no change detected)
  • watchOS (no change detected)
  • macOS (no change detected)
NET (empty diffs)
  • iOS: (empty diff detected)
  • tvOS: (empty diff detected)
  • MacCatalyst: (empty diff detected)
  • macOS: (empty diff detected)

✅ API diff vs stable

Legacy Xamarin (No breaking changes)
.NET (No breaking changes)
Legacy Xamarin (stable) vs .NET

✅ Generator diff

Generator diff is empty

Pipeline on Agent
Hash: fc471a62dcea61c34f7e6037e385e9e86796946c [PR build]

@vs-mobiletools-engineering-service2
Copy link
Collaborator

📚 [PR Build] Artifacts 📚

Packages generated

View packages

Pipeline on Agent XAMBOT-1107.Monterey'
Hash: fc471a62dcea61c34f7e6037e385e9e86796946c [PR build]

@vs-mobiletools-engineering-service2
Copy link
Collaborator

❌ [PR Build] Tests on macOS M1 - Mac Big Sur (11.5) failed ❌

Failed tests are:

  • linksdk

Pipeline on Agent
Hash: fc471a62dcea61c34f7e6037e385e9e86796946c [PR build]

@vs-mobiletools-engineering-service2
Copy link
Collaborator

🚀 [CI Build] Test results 🚀

Test results

✅ All tests passed on VSTS: simulator tests.

🎉 All 223 tests passed 🎉

Tests counts

✅ bcl: All 69 tests passed. Html Report (VSDrops) Download
✅ cecil: All 1 tests passed. Html Report (VSDrops) Download
✅ dotnettests: All 1 tests passed. Html Report (VSDrops) Download
✅ fsharp: All 7 tests passed. Html Report (VSDrops) Download
✅ framework: All 8 tests passed. Html Report (VSDrops) Download
✅ generator: All 2 tests passed. Html Report (VSDrops) Download
✅ interdependent_binding_projects: All 7 tests passed. Html Report (VSDrops) Download
✅ install_source: All 1 tests passed. Html Report (VSDrops) Download
✅ introspection: All 8 tests passed. Html Report (VSDrops) Download
✅ linker: All 65 tests passed. Html Report (VSDrops) Download
✅ mac_binding_project: All 1 tests passed. Html Report (VSDrops) Download
✅ mmp: All 2 tests passed. Html Report (VSDrops) Download
✅ mononative: All 12 tests passed. Html Report (VSDrops) Download
✅ monotouch: All 23 tests passed. Html Report (VSDrops) Download
✅ msbuild: All 2 tests passed. Html Report (VSDrops) Download
✅ mtouch: All 1 tests passed. Html Report (VSDrops) Download
✅ xammac: All 3 tests passed. Html Report (VSDrops) Download
✅ xcframework: All 8 tests passed. Html Report (VSDrops) Download
✅ xtro: All 2 tests passed. Html Report (VSDrops) Download

Pipeline on Agent
Hash: [PR build]

emaf
emaf approved these changes Oct 25, 2022
View reviewed changes
Copy link
Contributor

@emaf emaf left a comment

Choose a reason for hiding this comment

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

The Build agent looks good!

@rolfbjarne rolfbjarne merged commit 18e2bef into xamarin:main Oct 25, 2022
@rolfbjarne rolfbjarne deleted the fix-build.zip-take-2 branch October 25, 2022 20:29
rolfbjarne added a commit to rolfbjarne/xamarin-macios that referenced this pull request Jan 16, 2023
@rolfbjarne
[msbuild] Fix creating Build.zip. (xamarin#16445)
16d84bd 
We recently switched from building the msbuild tasks with 'msbuild' to use
'dotnet build' instead.

One difference between the two methods is that 'dotnet build' doesn't copy
referenced assemblies to the output path.

This turns out to be a problem because we zip up the output from the
Xamarin.Messaging.Build project, and expect it to contain everything required
to load the Xamarin.Messaging.Build assembly (this zip file is shipped with
our VS (Windows) support, and during remote execution copied to the connected
mac and then the build from Windows will load the assembly on the Mac in order
to do stuff on the Mac).

Another problem is that we include MSBuild assemblies from the
'$(MSBuildBinPath)' location, which is now different (we used to pick up
Mono's MSBuild assemblies, and that changed when we started building with
.NET).

In other words: because the Build.zip file stopped containing all the required
files to load Xamarin.Messaging.Build.dll, remote builds from VS stopped
working.

Ref: xamarin#16418

Here we attempt to fix this by:

* Setting 'CopyLocalLockFileAssemblies=true'. This will copy referenced
  assemblies to the output directory.
* Explicitly referencing Mono's MSBuild assemblies instead of relying upon
  finding them in '$(MSBuildBinPath)'. At this point I believe it's fine to
  hardcode Mono's path, since it's unlikely we'll get any new Mono updates.
@rolfbjarne rolfbjarne mentioned this pull request Jan 16, 2023
Merged
vs-mobiletools-engineering-service2 pushed a commit to vs-mobiletools-engineering-service2/xamarin-macios that referenced this pull request Jan 16, 2023
@rolfbjarne
[msbuild] Fix creating Build.zip. (xamarin#16445)
e75cf90 
We recently switched from building the msbuild tasks with 'msbuild' to use
'dotnet build' instead.

One difference between the two methods is that 'dotnet build' doesn't copy
referenced assemblies to the output path.

This turns out to be a problem because we zip up the output from the
Xamarin.Messaging.Build project, and expect it to contain everything required
to load the Xamarin.Messaging.Build assembly (this zip file is shipped with
our VS (Windows) support, and during remote execution copied to the connected
mac and then the build from Windows will load the assembly on the Mac in order
to do stuff on the Mac).

Another problem is that we include MSBuild assemblies from the
'$(MSBuildBinPath)' location, which is now different (we used to pick up
Mono's MSBuild assemblies, and that changed when we started building with
.NET).

In other words: because the Build.zip file stopped containing all the required
files to load Xamarin.Messaging.Build.dll, remote builds from VS stopped
working.

Ref: xamarin#16418

Here we attempt to fix this by:

* Setting 'CopyLocalLockFileAssemblies=true'. This will copy referenced
  assemblies to the output directory.
* Explicitly referencing Mono's MSBuild assemblies instead of relying upon
  finding them in '$(MSBuildBinPath)'. At this point I believe it's fine to
  hardcode Mono's path, since it's unlikely we'll get any new Mono updates.
Merged
vs-mobiletools-engineering-service2 pushed a commit to vs-mobiletools-engineering-service2/xamarin-macios that referenced this pull request Jan 16, 2023
@rolfbjarne
[msbuild] Fix creating Build.zip. (xamarin#16445)
92cab30 
We recently switched from building the msbuild tasks with 'msbuild' to use
'dotnet build' instead.

One difference between the two methods is that 'dotnet build' doesn't copy
referenced assemblies to the output path.

This turns out to be a problem because we zip up the output from the
Xamarin.Messaging.Build project, and expect it to contain everything required
to load the Xamarin.Messaging.Build assembly (this zip file is shipped with
our VS (Windows) support, and during remote execution copied to the connected
mac and then the build from Windows will load the assembly on the Mac in order
to do stuff on the Mac).

Another problem is that we include MSBuild assemblies from the
'$(MSBuildBinPath)' location, which is now different (we used to pick up
Mono's MSBuild assemblies, and that changed when we started building with
.NET).

In other words: because the Build.zip file stopped containing all the required
files to load Xamarin.Messaging.Build.dll, remote builds from VS stopped
working.

Ref: xamarin#16418

Here we attempt to fix this by:

* Setting 'CopyLocalLockFileAssemblies=true'. This will copy referenced
  assemblies to the output directory.
* Explicitly referencing Mono's MSBuild assemblies instead of relying upon
  finding them in '$(MSBuildBinPath)'. At this point I believe it's fine to
  hardcode Mono's path, since it's unlikely we'll get any new Mono updates.
Merged
vs-mobiletools-engineering-service2 pushed a commit to vs-mobiletools-engineering-service2/xamarin-macios that referenced this pull request Jan 16, 2023
@rolfbjarne
[msbuild] Fix creating Build.zip. (xamarin#16445)
0491afd 
We recently switched from building the msbuild tasks with 'msbuild' to use
'dotnet build' instead.

One difference between the two methods is that 'dotnet build' doesn't copy
referenced assemblies to the output path.

This turns out to be a problem because we zip up the output from the
Xamarin.Messaging.Build project, and expect it to contain everything required
to load the Xamarin.Messaging.Build assembly (this zip file is shipped with
our VS (Windows) support, and during remote execution copied to the connected
mac and then the build from Windows will load the assembly on the Mac in order
to do stuff on the Mac).

Another problem is that we include MSBuild assemblies from the
'$(MSBuildBinPath)' location, which is now different (we used to pick up
Mono's MSBuild assemblies, and that changed when we started building with
.NET).

In other words: because the Build.zip file stopped containing all the required
files to load Xamarin.Messaging.Build.dll, remote builds from VS stopped
working.

Ref: xamarin#16418

Here we attempt to fix this by:

* Setting 'CopyLocalLockFileAssemblies=true'. This will copy referenced
  assemblies to the output directory.
* Explicitly referencing Mono's MSBuild assemblies instead of relying upon
  finding them in '$(MSBuildBinPath)'. At this point I believe it's fine to
  hardcode Mono's path, since it's unlikely we'll get any new Mono updates.
Merged
rolfbjarne added a commit that referenced this pull request Jan 19, 2023
@rolfbjarne
[release/7.0.1xx] [msbuild] Build the solution using .NET instead of …
542de09 
…msbuild. (#17256)

Mono has a networking bug that NuGet often triggers, leading to build failures like this:


      [...]
      GET https://pkgs.dev.azure.com/dnceng/9ee6d478-d288-47f7-aacc-f6e6d082ae6d/_packaging/825db618-e3eb-4426-ba54-b1d6e6c944d8/nuget/v3/flat2/system.threading.tasks.extensions/index.json
      GET https://pkgs.dev.azure.com/dnceng/9ee6d478-d288-47f7-aacc-f6e6d082ae6d/_packaging/49e5305d-d845-4a14-9d69-6f5dbfb9570c/nuget/v3/flat2/system.threading.tasks.extensions/index.json
      GET https://pkgs.dev.azure.com/xamarin/6fd3d886-57a5-4e31-8db7-52a1b47c07a8/_packaging/bcd6855c-070e-4cb7-a698-ac197b93cd87/nuget/v3/flat2/system.threading.tasks.extensions/index.json
      NotFound https://pkgs.dev.azure.com/dnceng/9ee6d478-d288-47f7-aacc-f6e6d082ae6d/_packaging/9d6ecda8-a4ca-4c13-8c0c-939b925b1f31/nuget/v3/flat2/system.runtime.serialization.primitives/index.json 263ms
    Retrying 'FindPackagesByIdAsync' for source 'https://pkgs.dev.azure.com/xamarin/6fd3d886-57a5-4e31-8db7-52a1b47c07a8/_packaging/bcd6855c-070e-4cb7-a698-ac197b93cd87/nuget/v3/flat2/system.threading.tasks.extensions/index.json'.
    Cannot access a disposed object.
    Object name: 'System.Net.Sockets.Socket'.
      GET https://pkgs.dev.azure.com/xamarin/6fd3d886-57a5-4e31-8db7-52a1b47c07a8/_packaging/bcd6855c-070e-4cb7-a698-ac197b93cd87/nuget/v3/flat2/system.threading.tasks.extensions/index.json
    Retrying 'FindPackagesByIdAsync' for source 'https://pkgs.dev.azure.com/xamarin/6fd3d886-57a5-4e31-8db7-52a1b47c07a8/_packaging/bcd6855c-070e-4cb7-a698-ac197b93cd87/nuget/v3/flat2/system.threading.tasks.extensions/index.json'.
    Cannot access a disposed object.
    Object name: 'System.Net.Sockets.Socket'.
      GET https://pkgs.dev.azure.com/xamarin/6fd3d886-57a5-4e31-8db7-52a1b47c07a8/_packaging/bcd6855c-070e-4cb7-a698-ac197b93cd87/nuget/v3/flat2/system.threading.tasks.extensions/index.json
      OK https://pkgs.dev.azure.com/dnceng/9ee6d478-d288-47f7-aacc-f6e6d082ae6d/_packaging/45bacae2-5efb-47c8-91e5-8ec20c22b4f8/nuget/v3/flat2/system.runtime.serialization.primitives/index.json 261ms
      NotFound https://pkgs.dev.azure.com/dnceng/9ee6d478-d288-47f7-aacc-f6e6d082ae6d/_packaging/2a281e02-c7a8-4a75-8582-3407d441de57/nuget/v3/flat2/system.runtime.serialization.primitives/index.json 272ms
      [...]

This is very annoying when it happens on our bots, because we have to retry
the build until it works.

I initially tried to fix this by simplify building the msbuild solution with
.NET, and while that worked (the random network errors in NuGet disappeared),
another issue surfaced (ref: #16418).

This other issue was fixed in main (#16445), but on the release branches the
original fix was reverted instead, since that was the safest approach (better
to have random network errors on the bots than ship a something that doesn't
work 100% of the time).

However, due to the number of release branches we currently have (and they're
unlikely to decrease in number any time soon), the random network errors on
the bots are getting more and more disruptive, so let's try the fix again on
our release branches.

Ref: #16445, #16428.
rolfbjarne added a commit that referenced this pull request Jan 19, 2023
@vs-mobiletools-engineering-service2 @rolfbjarne
[release/7.0.1xx-xcode14.2] [msbuild] Build the solution using .NET i…
184ff33 
…nstead of msbuild. (#17257)

Mono has a networking bug that NuGet often triggers, leading to build failures like this:


      [...]
      GET https://pkgs.dev.azure.com/dnceng/9ee6d478-d288-47f7-aacc-f6e6d082ae6d/_packaging/825db618-e3eb-4426-ba54-b1d6e6c944d8/nuget/v3/flat2/system.threading.tasks.extensions/index.json
      GET https://pkgs.dev.azure.com/dnceng/9ee6d478-d288-47f7-aacc-f6e6d082ae6d/_packaging/49e5305d-d845-4a14-9d69-6f5dbfb9570c/nuget/v3/flat2/system.threading.tasks.extensions/index.json
      GET https://pkgs.dev.azure.com/xamarin/6fd3d886-57a5-4e31-8db7-52a1b47c07a8/_packaging/bcd6855c-070e-4cb7-a698-ac197b93cd87/nuget/v3/flat2/system.threading.tasks.extensions/index.json
      NotFound https://pkgs.dev.azure.com/dnceng/9ee6d478-d288-47f7-aacc-f6e6d082ae6d/_packaging/9d6ecda8-a4ca-4c13-8c0c-939b925b1f31/nuget/v3/flat2/system.runtime.serialization.primitives/index.json 263ms
    Retrying 'FindPackagesByIdAsync' for source 'https://pkgs.dev.azure.com/xamarin/6fd3d886-57a5-4e31-8db7-52a1b47c07a8/_packaging/bcd6855c-070e-4cb7-a698-ac197b93cd87/nuget/v3/flat2/system.threading.tasks.extensions/index.json'.
    Cannot access a disposed object.
    Object name: 'System.Net.Sockets.Socket'.
      GET https://pkgs.dev.azure.com/xamarin/6fd3d886-57a5-4e31-8db7-52a1b47c07a8/_packaging/bcd6855c-070e-4cb7-a698-ac197b93cd87/nuget/v3/flat2/system.threading.tasks.extensions/index.json
    Retrying 'FindPackagesByIdAsync' for source 'https://pkgs.dev.azure.com/xamarin/6fd3d886-57a5-4e31-8db7-52a1b47c07a8/_packaging/bcd6855c-070e-4cb7-a698-ac197b93cd87/nuget/v3/flat2/system.threading.tasks.extensions/index.json'.
    Cannot access a disposed object.
    Object name: 'System.Net.Sockets.Socket'.
      GET https://pkgs.dev.azure.com/xamarin/6fd3d886-57a5-4e31-8db7-52a1b47c07a8/_packaging/bcd6855c-070e-4cb7-a698-ac197b93cd87/nuget/v3/flat2/system.threading.tasks.extensions/index.json
      OK https://pkgs.dev.azure.com/dnceng/9ee6d478-d288-47f7-aacc-f6e6d082ae6d/_packaging/45bacae2-5efb-47c8-91e5-8ec20c22b4f8/nuget/v3/flat2/system.runtime.serialization.primitives/index.json 261ms
      NotFound https://pkgs.dev.azure.com/dnceng/9ee6d478-d288-47f7-aacc-f6e6d082ae6d/_packaging/2a281e02-c7a8-4a75-8582-3407d441de57/nuget/v3/flat2/system.runtime.serialization.primitives/index.json 272ms
      [...]

This is very annoying when it happens on our bots, because we have to retry
the build until it works.

I initially tried to fix this by simplify building the msbuild solution with
.NET, and while that worked (the random network errors in NuGet disappeared),
another issue surfaced (ref: #16418).

This other issue was fixed in main (#16445), but on the release branches the
original fix was reverted instead, since that was the safest approach (better
to have random network errors on the bots than ship a something that doesn't
work 100% of the time).

However, due to the number of release branches we currently have (and they're
unlikely to decrease in number any time soon), the random network errors on
the bots are getting more and more disruptive, so let's try the fix again on
our release branches.

Ref: #16445, #16428.


Backport of #17256

Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
rolfbjarne added a commit that referenced this pull request Jan 19, 2023
@vs-mobiletools-engineering-service2 @rolfbjarne
[release/7.0.2xx] [msbuild] Build the solution using .NET instead of …
ab50aaf 
…msbuild. (#17258)

Mono has a networking bug that NuGet often triggers, leading to build failures like this:


      [...]
      GET https://pkgs.dev.azure.com/dnceng/9ee6d478-d288-47f7-aacc-f6e6d082ae6d/_packaging/825db618-e3eb-4426-ba54-b1d6e6c944d8/nuget/v3/flat2/system.threading.tasks.extensions/index.json
      GET https://pkgs.dev.azure.com/dnceng/9ee6d478-d288-47f7-aacc-f6e6d082ae6d/_packaging/49e5305d-d845-4a14-9d69-6f5dbfb9570c/nuget/v3/flat2/system.threading.tasks.extensions/index.json
      GET https://pkgs.dev.azure.com/xamarin/6fd3d886-57a5-4e31-8db7-52a1b47c07a8/_packaging/bcd6855c-070e-4cb7-a698-ac197b93cd87/nuget/v3/flat2/system.threading.tasks.extensions/index.json
      NotFound https://pkgs.dev.azure.com/dnceng/9ee6d478-d288-47f7-aacc-f6e6d082ae6d/_packaging/9d6ecda8-a4ca-4c13-8c0c-939b925b1f31/nuget/v3/flat2/system.runtime.serialization.primitives/index.json 263ms
    Retrying 'FindPackagesByIdAsync' for source 'https://pkgs.dev.azure.com/xamarin/6fd3d886-57a5-4e31-8db7-52a1b47c07a8/_packaging/bcd6855c-070e-4cb7-a698-ac197b93cd87/nuget/v3/flat2/system.threading.tasks.extensions/index.json'.
    Cannot access a disposed object.
    Object name: 'System.Net.Sockets.Socket'.
      GET https://pkgs.dev.azure.com/xamarin/6fd3d886-57a5-4e31-8db7-52a1b47c07a8/_packaging/bcd6855c-070e-4cb7-a698-ac197b93cd87/nuget/v3/flat2/system.threading.tasks.extensions/index.json
    Retrying 'FindPackagesByIdAsync' for source 'https://pkgs.dev.azure.com/xamarin/6fd3d886-57a5-4e31-8db7-52a1b47c07a8/_packaging/bcd6855c-070e-4cb7-a698-ac197b93cd87/nuget/v3/flat2/system.threading.tasks.extensions/index.json'.
    Cannot access a disposed object.
    Object name: 'System.Net.Sockets.Socket'.
      GET https://pkgs.dev.azure.com/xamarin/6fd3d886-57a5-4e31-8db7-52a1b47c07a8/_packaging/bcd6855c-070e-4cb7-a698-ac197b93cd87/nuget/v3/flat2/system.threading.tasks.extensions/index.json
      OK https://pkgs.dev.azure.com/dnceng/9ee6d478-d288-47f7-aacc-f6e6d082ae6d/_packaging/45bacae2-5efb-47c8-91e5-8ec20c22b4f8/nuget/v3/flat2/system.runtime.serialization.primitives/index.json 261ms
      NotFound https://pkgs.dev.azure.com/dnceng/9ee6d478-d288-47f7-aacc-f6e6d082ae6d/_packaging/2a281e02-c7a8-4a75-8582-3407d441de57/nuget/v3/flat2/system.runtime.serialization.primitives/index.json 272ms
      [...]

This is very annoying when it happens on our bots, because we have to retry
the build until it works.

I initially tried to fix this by simplify building the msbuild solution with
.NET, and while that worked (the random network errors in NuGet disappeared),
another issue surfaced (ref: #16418).

This other issue was fixed in main (#16445), but on the release branches the
original fix was reverted instead, since that was the safest approach (better
to have random network errors on the bots than ship a something that doesn't
work 100% of the time).

However, due to the number of release branches we currently have (and they're
unlikely to decrease in number any time soon), the random network errors on
the bots are getting more and more disruptive, so let's try the fix again on
our release branches.

Ref: #16445, #16428.


Backport of #17256

Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
rolfbjarne added a commit that referenced this pull request Jan 19, 2023
@vs-mobiletools-engineering-service2 @rolfbjarne
[release/6.0.4xx-xcode14.2] [msbuild] Build the solution using .NET i…
12fc6c4 
…nstead of msbuild. (#17259)

Mono has a networking bug that NuGet often triggers, leading to build failures like this:


      [...]
      GET https://pkgs.dev.azure.com/dnceng/9ee6d478-d288-47f7-aacc-f6e6d082ae6d/_packaging/825db618-e3eb-4426-ba54-b1d6e6c944d8/nuget/v3/flat2/system.threading.tasks.extensions/index.json
      GET https://pkgs.dev.azure.com/dnceng/9ee6d478-d288-47f7-aacc-f6e6d082ae6d/_packaging/49e5305d-d845-4a14-9d69-6f5dbfb9570c/nuget/v3/flat2/system.threading.tasks.extensions/index.json
      GET https://pkgs.dev.azure.com/xamarin/6fd3d886-57a5-4e31-8db7-52a1b47c07a8/_packaging/bcd6855c-070e-4cb7-a698-ac197b93cd87/nuget/v3/flat2/system.threading.tasks.extensions/index.json
      NotFound https://pkgs.dev.azure.com/dnceng/9ee6d478-d288-47f7-aacc-f6e6d082ae6d/_packaging/9d6ecda8-a4ca-4c13-8c0c-939b925b1f31/nuget/v3/flat2/system.runtime.serialization.primitives/index.json 263ms
    Retrying 'FindPackagesByIdAsync' for source 'https://pkgs.dev.azure.com/xamarin/6fd3d886-57a5-4e31-8db7-52a1b47c07a8/_packaging/bcd6855c-070e-4cb7-a698-ac197b93cd87/nuget/v3/flat2/system.threading.tasks.extensions/index.json'.
    Cannot access a disposed object.
    Object name: 'System.Net.Sockets.Socket'.
      GET https://pkgs.dev.azure.com/xamarin/6fd3d886-57a5-4e31-8db7-52a1b47c07a8/_packaging/bcd6855c-070e-4cb7-a698-ac197b93cd87/nuget/v3/flat2/system.threading.tasks.extensions/index.json
    Retrying 'FindPackagesByIdAsync' for source 'https://pkgs.dev.azure.com/xamarin/6fd3d886-57a5-4e31-8db7-52a1b47c07a8/_packaging/bcd6855c-070e-4cb7-a698-ac197b93cd87/nuget/v3/flat2/system.threading.tasks.extensions/index.json'.
    Cannot access a disposed object.
    Object name: 'System.Net.Sockets.Socket'.
      GET https://pkgs.dev.azure.com/xamarin/6fd3d886-57a5-4e31-8db7-52a1b47c07a8/_packaging/bcd6855c-070e-4cb7-a698-ac197b93cd87/nuget/v3/flat2/system.threading.tasks.extensions/index.json
      OK https://pkgs.dev.azure.com/dnceng/9ee6d478-d288-47f7-aacc-f6e6d082ae6d/_packaging/45bacae2-5efb-47c8-91e5-8ec20c22b4f8/nuget/v3/flat2/system.runtime.serialization.primitives/index.json 261ms
      NotFound https://pkgs.dev.azure.com/dnceng/9ee6d478-d288-47f7-aacc-f6e6d082ae6d/_packaging/2a281e02-c7a8-4a75-8582-3407d441de57/nuget/v3/flat2/system.runtime.serialization.primitives/index.json 272ms
      [...]

This is very annoying when it happens on our bots, because we have to retry
the build until it works.

I initially tried to fix this by simplify building the msbuild solution with
.NET, and while that worked (the random network errors in NuGet disappeared),
another issue surfaced (ref: #16418).

This other issue was fixed in main (#16445), but on the release branches the
original fix was reverted instead, since that was the safest approach (better
to have random network errors on the bots than ship a something that doesn't
work 100% of the time).

However, due to the number of release branches we currently have (and they're
unlikely to decrease in number any time soon), the random network errors on
the bots are getting more and more disruptive, so let's try the fix again on
our release branches.

Ref: #16445, #16428.


Backport of #17256

Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@stephen-hawley stephen-hawley stephen-hawley approved these changes

@emaf emaf emaf approved these changes

@dalexsoto dalexsoto dalexsoto approved these changes

@mauroa mauroa Awaiting requested review from mauroa mauroa is a code owner

Assignees
No one assigned
Labels
not-notes-worthy Ignore for release notes
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@rolfbjarne @vs-mobiletools-engineering-service2 @dalexsoto @emaf @stephen-hawley