Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
# Steps to reproduce
When Opening a Xamarin.Forms solution, it takes much more time, than a normal WinForms Solution having the same number of projects as class library, also when compiling (I am not talking about running) only compiling, it will take a long time, compared to compiling a WinForms solution.
As you can see in the link for the App8.zip solution.
I have a solution that has 55 projects, and its taking a very long time to load, now neglecting if it’s a bad design or not, it does not have a lot of classes, only many projects, and takes several minutes, from 3:30~4+ minutes.
And to re-build(re-compile) the hole solution, from 1~2 minutes.
Now the deployment in debug mode for android(setting the .Droid project as startup) and pressing the debug button on [5” Marshmallow (6.0.0) XHDPI Phone (Android 6.0 – API 23)], will take 1+ minute, and I did not count the launch of the emulator, as the emulator is running before the debug session, and also the solution was run in debug mode, then stopped, then again run in debug mode, without any modification of the code, but its still the same long time.
# Expected Behavior:
I think it should be looked into it, so it will be faster, at least comparable in loading/compiling/deployment (PCL vs Normal Class Library).
Its very slow in Loading the solution and its projects especially if they are two many, and slow in compiling and in deployment.
Shared Solution “App8.zip” + “testSyncfusion.zip”, in Google drive:
Note: All nuggets have been downloaded, so the nugget restoring is not the problem.
HDD: Samsung SSD 850 Pro 256GB
CPU: i7-2600 3.4GHz
OS: win 10
IDE: VS 2015 update 2 + VS 2015 update 2 cumulative update: vs14-kb3151378.exe
Add-Ons: There is NO, I repeat no plug-ins like resharper or refactor installed, only plain VS, and even if they are, the loading of a solution having 55 normal class library projects, is faster than a solution having 55 PCL projects.
Xamarin: installed 22.214.171.1240
Solution using Xamarin.Forms nuget 126.96.36.199
# Needed installations:
Syncfusion Essential Studio 2016 Vol 1 Xamarin u1 --> community edition: https://www.syncfusion.com/products/whatsnew
Visual Studio Emulator for Android 2.2: https://www.visualstudio.com/en-us/features/msft-android-emulator-vs.aspx
this was also written here:
as i don't know if this should be reported to Xamarin or Microsoft.
**The Working Startup projects are only**:
And i am experiencing the problems with the testSyncfusion.Droid project.
Can you try Update 3? I moved this to the VS team.
Opening the solution
Yes I tried it, it took almost 4 minutes to open the solution, and this is even after doing the first two from this url:
* Disabling Full Solution Diagnostics
* Disabling CodeLens
Also To prevent NuGet from restoring packages during build, I unchecked 'Allow NuGet to download missing packages during build.' from the options of VS.
I think what the MS Team did, is optimize the "Normal Class Library" project types, and that the Xamarin PCL project types, have something that makes them very slow in comparison, and they did not look at it.
maybe if there is a log that logs the operations + the timing of opening each project in the solution, it will help you a lot.
And it took 1 minutes and 5 seconds to Rebuilding the whole solution, and here is the rebuild output:
Hi, we have been working on several perf improvements that will be available in the next Cycle alpha release that should help to decrease loading solution time. Could you please give a try and let us know if the experience is now better?
As we've added several improvements to our build system and deploying/debugging mechanism since the bug was reported, I'm resolving it tentatively as Fixed.
That said, if you're still facing this issue with current bits, please feel free to reopen the bug.