Builds are significantly slower with Internet access

[BlueRaja]

Description

When I start VS + Android Emulator with my internet cord unplugged, my builds are almost 10x faster.

Here are some actual timings I took:

	No Internet	With Internet
Launch on Android Emulator with no changes:	18.1s	137.5s
...with a simple change to a .cs file:	26.4s	156.0s
...with a simple change to a .xaml file	21.3s	139.3s

I tried this multiple times, and was able to reproduce every time.

Steps to Reproduce

1. Run VS like normal, with Internet connected, and pre-launch the emulator.
2. Choose "Debug" mode, with the Android project selected.
3. Hit the "play" button to build +deploy the project.
4. Close VS + the emulator
5. Disconnect your internet cable
6. Relaunch VS + the emulator
7. Hit the "play" button again

Expected results: Build + Deploy take the same amount of time

Actual results: Build is 6x slower with Internet connected. Sometimes the first build after disconnecting the Internet is still slow, but subsequent builds are fast. No build is ever fast with Internet connected - my 20s build was the first time MAUI ever took me under 2 minutes to build+deploy.

Interestingly, when the builds are slow, the status bar says "Building..." for a long time, even when you didn't make any changes. However when builds are being fast, it never says "Building..." and goes straight to "Deploying"

Link to public reproduction project repository

No response

Version with bug

8.0.7 SR2

Is this a regression from previous behavior?

Yes, this used to work in Xamarin.Forms

Last version that worked well

Unknown/Other

Affected platforms

Android, I was not able test on other platforms

Affected platform versions

Visual Studio Version 17.10.0 Preview 1.0 Emulator is Android 13 - API 33 - Pixel 5

Did you find any workaround?

If you launch VS + the emulator while the Internet is disconnected and build the app once, builds will continue to be fast even after reconnecting the Internet until you restart VS.

Relevant log output

No response

[jfversluis]

Does this also happen when you do builds from the command-line? Is this specific to .NET MAUI or also for other projects?

This might be something that is caused by Visual Studio and needs to be reported there.

[BlueRaja]

Is this specific to .NET MAUI or also for other projects?

This problem is specific to MAUI. Non-MAUI projects do not attempt to do a full rebuild (which I assume is what's happening here) when no changes have occurred, with or without Internet.

Does this also happen when you do builds from the command-line?

I'm not sure how to do the equivalent of the VS "play" button from the command-line. How do I tell it to "build the project, but only the parts in need of a rebuild; then publish to the device, run the program, and attach the debugger"?

[BlueRaja]

I played around with it some more:

(No Internet) → Start VS → (Connect Internet) → Launch Emulator → Hit 'play' button → Builds are slow
(No Internet) → Start VS → Build solution → (Connect Internet) → Launch Emulator → Hit 'play' button → Builds are fast

So apparently the issue happens when you have Internet during the first build after launching VS.

[ewerspej]

Could this be related to restoring nuget packages?

[jpobst]

If you build using Diagnostic verbosity or creating a binlog it will provide a lot more information telling you exactly what is running.

It should also end with a build performance summary to show how long each step takes, eg:

1>Task Performance Summary:
1>     1010 ms  LinkApplicationSharedLibraries             1 calls
1>     1252 ms  GenerateJavaStubs                          1 calls
1>     1315 ms  CompileNativeAssembly                      1 calls
1>     1443 ms  CallTarget                                 6 calls
1>     1701 ms  ManifestMerger                             1 calls
1>     1852 ms  ResolveLibraryProjectImports               1 calls
1>     1982 ms  LinkAssembliesNoShrink                     1 calls
1>     2111 ms  Csc                                        1 calls
1>     3744 ms  ProcessAssemblies                          1 calls
1>     4591 ms  Javac                                      1 calls
1>    17043 ms  D8                                         1 calls

[elparasite]

Just an idea reading the thread, maybe an online verification of some CRL or OCSP during the signing process can cause this issue. If the OCSP server doesn't respond or is very slow it may provokes this kind of issue.

[asi-evin]

So turns out my issue was actually something else: https://youtrack.jetbrains.com/issue/RSRP-495224

And apparently the one time I disabled the internet tricked Resharper into not fiddling with the obj files... sorry for the accidental tangent. I've deleted my posts so OP gets the attention he needs.

[swlasse]

FWIW, following the proposed workaround on the linked ReSharper issue worked for me:

WORKAROUND: disable ReSharper | Options | Environment | General | Read solution model directly.. option.

Now, the solution no longer rebuilds on every build which naturally speeds up development a lot.

[paulohloblin]

I think in case of Visual Studio it's related to NuGet package restore. This significantly slows down my builds, so I went Tools > Options > NuGet Package Manager > General and disabled Automatically check for missing packages during build

[dotnet-policy-service[bot]]

Hi @BlueRaja. We have added the "s/needs-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[mattleibow]

Are things working faster now? Is this issue safe to close?

[dotnet-policy-service[bot]]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. If it is closed, feel free to comment when you are able to provide the additional information and we will re-investigate.