Forum› General
Xamarin should start to make the platform stable again before adding new stuff.
PaulSinnema
NLMember ✭✭✭
NLMember ✭✭✭
I don't know if I'm the only one suffering from the bad performing Xamarin development platform but my guess is I'm not. Progress has gone down to a crawl and I would like to get on with my job. My assignment is taking way too long at the moment.
Here's a short list of problems I've met these last few months:
- Load of solution make VS2017 hang. I've analyzed this and it again is the google-services.json on Android.
- VS studio freezes up all the time. On deploy to iOS or debug to iOS VS just simply has to be killed and restarted before I can get on.
- Deployment to Android devices are incomplete after changes in PCL. It looks like keys and values don't match up anymore leading to Firebase not working, wrong strings in menuitems, etc.
Designer for Android is just plain bad:
- Sync from designer to properties does not work correctly
- Properties show wrong values
- Some values just can not be entered (I think string <-> int mismatches).
- Embedding components in a View via the menu. I've never seen that to work at all.
- Very often get exceptions and have to reload. F.i. when deleting a component an exception is thrown. The delete however has been done correctly as I can see after reload.
Builds are terribly slow. I have a fast PC with SSD and lot's of memory but it will not perform. Turn-arround times are therefore just plain bad.
- Mac looses connection frequently
- Wrong caching of Apple profiling files caused me to loose a days work. I just couldn't get VS to deploy to my iPad. Caching of generated files in general is a big problem on iOS and Android.
There are more problems I can't think of right now. Feel free to mention more here when you think they are relevant.
I urge Xamarin to get their act together and help us make the tool great again!
Tagged:
9
Answers
Have you reported all these problems? One problem Xamarin do have is people complain about an issue but never report it. They can't fix what they don't know...
@PaulSinnema i know all your xamarin+vs pain for 3 years. Try JetBrains Rider IDE. You will be surprised how it can be. "Significantly" is the word I think. and magic ))
My 180 projects solution loads for 5-8 seconds, solution reloading doesn't scare me, no trick hacks like "cleaning all the stuff scripts", no freezes at all (loading bar - that's all). You can edit your program during execution. It's not runtime code changing but very useful. Instant Full-Search as default, git/tfs integration.
If you use Resharper plugin than you will be in heaven - it's all resharper analysic and all the stuff.
If you dont use, than you will be surprised how IDE can be clever.
There will be cons:
But it's very fast growing project and it's amazing already.
Hi Paul,
Let's talk about some of the issues you've outlined:
This is a current issue and it's being investigated. https://bugzilla.xamarin.com/show_bug.cgi?id=56108
There is a workaround for including the strings yourself until this
BuildActiongets fixed.I'm not sure of any outstanding issues here as this can vary from machine to machine. Some steps you will want to check are included in the following documentation:
https://developer.xamarin.com/guides/ios/getting_started/installation/windows/connecting-to-mac/troubleshooting/
You can also get the Stack Trace of the VS instance via the following:
https://kb.xamarin.com/customer/portal/articles/2232835-how-do-i-collect-the-call-stack-of-visual-studio-s-main-thread-
Can you elaborate on this item? Does this refer to items in the PCL not getting deployed? Have you tried a clean rebuild by deleting your
obj/binfolders?Are you inspecting your .xml/.axml source after making a change to a property to ensure it's generating the correct XML?
Which properties show wrong values? We want to know exactly which properties are providing wrong values so we can fix them.
This can happen with types changing and enums changing. Again, we will want to know exactly which value cannot be entered here.
There are changes in this area on the horizon. The toolbox has always been an area of improvement.
What exceptions are you encountering? We would be interested in making these scenarios better overall.
See my post on Stack Overflow regarding how to diagnose these further:
https://stackoverflow.com/questions/40523414/slow-app-build-xamarin-for-visual-studio/40615665#40615665
Typically we want to figure out what
Taskis responsible for a hang.Back to the documentation: https://developer.xamarin.com/guides/ios/getting_started/installation/windows/connecting-to-mac/troubleshooting/
This can be an issue with your local network reliability. You can also try using a wired connection.
I believe there are areas of improvement overall in these areas. Ideally if you ever encounter a situation like this, you can always re-create these items via our documentation:
https://developer.xamarin.com/guides/ios/getting_started/installation/device_provisioning/manual-provisioning/#Requesting_a_Development_Certificate
https://developer.xamarin.com/guides/ios/getting_started/installation/device_provisioning/manual-provisioning/#Creating_a_Development_Provisioning_Profile
https://developer.xamarin.com/guides/ios/getting_started/installation/device_provisioning/manual-provisioning/#Downloading_Profiles_and_Certificates_in_Xcode
As a general rule of thumb, we always promote developers to log any issues they encounter with the Xamarin tooling to a location. To find the proper location for your issues, please see our support options page:
https://developer.xamarin.com/guides/cross-platform/troubleshooting/support-options/
The situations you've described above best fit in the "I believe this problem is caused by a defect in the Xamarin source code." which should be filed in our Bugzilla Tracker. I encourage you to file these issues in our bugzilla tracker so we can get eyes on these outstanding issues to be fixed in an upcoming Xamarin release. Otherwise, if I can get more information from you to the point of reproducing each issue or understanding each issue thoroughly; I will file them on your behalf.
We are always listening and value your feedback. Thank you for bringing this to our attention!
Thank you for your constructive thinking. I've started this in the 'General' section because I would like to have a fundamental discussion about the quality of the product. Not to pinpoint all the mentioned problems in detail (I've already started several threads in other sections). Your remarks, be it to the point and concrete are just exactly what I mean. We as developers are constantly confronted with bugs introduced by Xamarin and then we have to report them and just hope something will be repaired. If Xamarin developers are using the tools I bet they feel the same pain as we do. Listen to them. I've been developing for more than 35 years now on many different kinds of projects but this one is really different. With different I mean frustrating, annoying and painful. A lot of my time at the moment is spent analyzing problems with the environment, looking for a work around, cleaning solutions (including removing obj/bin directories), rebuilding, waiting and hope, pray for the best to happen. The outcome of the building process is too unpredictable. It's just not stable enough for me to have fun programming mobile apps. Most of the time I'm a patient constructive guy and would like to help to make a platform better than it is. But the problems just keep poring in and even old ones return from time to time. We all love new stuff getting into the product but please, please stop that for a while and make this product stable again and use and test, test, test it yourselves thoroughly.
They would know if they would use and test it themselves, wouldn't they? Some of the mentioned problems are just always there and very hard to mis, wouldn't you agree? Testing is not easy, I know, I've been there, done that. But it's imperative you test your solutions thoroughly before releasing it to the users. My paying customer is also happy when I do the job right. And don't just test it yourself. Let other do that. By the way. I do think Xamarin should blame no one but themselves. I've seen problems reported that date back more than a year without a solution. But let's not start the blame game and get this show back on the road.
@PaulSinnema
You are not the only one... I have to confirm your posting fully...
I have posted similar problems in Mai 2015 (with a lot of reactions) -> nothing have changed:
https://forums.xamarin.com/discussion/41588/how-to-make-forms-stable/p1
(note: the thread is preventing from pop by new messages, so it's a "dead thread")
I have done various further attempts to help advance the processes.
Unfortunately, I have wasted my time and gave up a longer time ago...
So.. (very unfortunately) the only conclusion... take it or leave it
I certainly agree, installing new versions of Xamarin is always a gamble. Although I must say, it has gotten somewhat better than it used to be. Maybe Xamarin should encourage their developers to work on their own projects using Xamarin during some hours a week. There has been some bugs which are so impactful I can't believe they actually use the product themselves.
It feels like they sometimes just ignores bug reports as well. What's up with this, reported in 2015? https://bugzilla.xamarin.com/show_bug.cgi?id=36593
Maybe @JonDouglas knows anything?
@JonDouglas: Jon, can you confirm Xamarin is using it's own tools? If so don't the developers encounter the same problems we all have? If not shouldn't you be using them even if only for testing purposes? My client is paying me to do the job right but with the current status of the tools this is becoming very difficult. Switching to another tool is courageous but may not be an option considering the amount already spent on Xamarin development. What can Xamarin do for us so we can all be happy again? Maybe Xamarin should take a long hard look at their internal processes. Are they still bringing what was intended or should they be changed? My gut feeling is that there's a gap between the creators of the tools and the developers using them that is not bridged. The tool-developers don't feel the pain we as developers have using the tools. Considering how long this tool has already been around it should be stable by now but it isn't. What is causing that?
I haven't moved from VS2015 (SP3) and Cycle9, last stable release, in between a lot of stable fundamental stuff broke.
VS2017 needs an easier patch approach for Xamarin or they need to release fixes more often, I'd blame Microsoft.
Some approach Xamarin (Microsoft) has taken has changed quality of the product. I do remember VS2015 with Xamarin being pretty stable indeed. VS2017 just isn't. Maybe a downgrade would help me. On the other hand. It would probably break a lot of the code I have written.
Took a good look at Jetbrain Rider today. Loading the solution was easy and rebuilding it went without problems. Just couldn't get deploy to work. Got an error and found no solution on the internet (found this: https://stackoverflow.com/questions/43593847/cant-run-empty-android-app-on-jetbrains-ride) which seems to be the same problem. Environment looks pretty stable and fast. I'm bit reluctant to leave the VS platform but who knows.
@PaulSinnema
I use VS Android Emulator with no problems (Vs has no problems too). You can try real device to check emulator is a problem.
I can deploy all my Droid and iOS apps (very big different projects).
@JonDouglas
About Mac connection.
Xamarin is amazing product and all of us took an risk to propose it to our customers, bosses ....
) , what is not true, but hope it will be true in near future.
Who could have already lost their patience if You adverised it that You will get 2 apps in price/time of one (I haven't done that
Newer the less I had as same many issues to solve as j2ee developer
, Xamarin is much stable than it was year ago.
Less is more
I mistakenly mentioned the Android designer where I should have said the iOS designer, sorry about that.
@PaulSinnema
There is no doubt that the development of the Xamarin cross-development environment in general and Xamarin.Forms in particular is driven by corporate pressure to embrace/promote the Microsoft technologies and cloud and not by an engineering drive to achieve "code quality" (i.e. less bugs).
Take a look at this very simple one for example - you cannot even display a basic WebView on Microsoft's own Windows 10 if you provide an HTML string:
https://bugzilla.xamarin.com/show_bug.cgi?id=57451
This is just plain wrong and Microsoft will most likely cause major damage to the Xamarin cross-development environment and we will most likely see the evolution of Jetbrains Rider IDE (or something similar supported by AWS or Google) for real cross-development. Visual Studio is now turning into an an Azure services selling store front.
My recommendation is to wait at least two minor releases before upgrading Xamarin versions and completely shy away from non basic programming in the Xamarin environment. And do not even go into Xamarin provided components like Xamarin.Auth where documentation is horrible and code quality is poor.
But the future is bright. We all know the tremendous value of cross-development with minimal pain. Someone will address this soon - we will see better IDE's and will be able to use or license better components.
@PaulSinnema
Xamarin team is using their tools (in alpha, beta and stable channels). Xamarin team hits the same problems like developers. The difference in most cases is experience with tools and platforms.
Testing is tough on Xamarin team too. Xamarin.Forms tools and libs must be tested on N platforms.
I have never seen Xamarin team blaming others, but sole criticism and not constructive criticism in open source is not very fair.
I can confirm Xamarin team is using the same tools - Xamarin tools. How would Xamarin.Forms, Xamarin.Auth, Xamarin.Social be written? Phonegap, ReactNative?
Xamarin technology is reactive, not proactive in the sense when Apple or Google release some/most things must be done reactively - ASAP. Apple ha partner program, so alphas and betas are available and most of the things can be prepared early enough. Google partner program is different, so most of the things are done after change notifications (various repos).
Other cause of problems is that Xamarin is piggybacking iOS and Android tools and SDKs and Xamarin is not changing those. Can you confirm there is no errors bugs in iOS and/or Android tools and SDKs? The problem is that often those are not surfaced to the developers (sometimes not known to Xamarin tool writers, to be handled) and other problem is that if the problem is surfaced developer has problems solving it because of lack of knowledge/experience.
@HalilDoganBolak
From your comment seem like you are using and are familiar with some components. Please can you provide more info/insights? What would be the ideal budget/size of Xamarin.Auth team for you?
@moljac - I would budget a team of three - senior developer/architect (overall direction, critical code) - junior developer (samples, easier code) and a tester/documentation writer for a period of 6 weeks from the current state of Xamarin.Auth to what it should be. Given the need for a stable and easy to use social networks and beyond OAuth based authentication mechanism in almost any cross platform app development, your component should actually be part of the "base" Xamarin. And the reason that is not is most likely due to the "blind" product strategists at Redmond. Do you agree ?
@moljac
You're right I shouldn't have done that. I apologize. My reaction came from frustration and that's a bad incentive. It's a tough job Xamarin is doing but for some reason the quality has gone down and that hurts a lot of developers and customers too. Once you go the Xamarin way you have to rely on it fully it makes you dependent.
This seems like a managers solution to me. Add more/different people to the mix and problems will disappear automagically. I have no insights in the processes at hand so it's hard for me to say if that would really solve the problems. I fully believe in Agile approaches so I would take into that direction but again I have no insights enough.
@PaulSinnema,
I totally agree with your facing issues. My choice is living with it, unfortunately. Xamarin was more stable than it's now.
Cheers.
The latest update of VS2017 (VisualStudio.15.Release/15.3.1+26730.8) has made things a bit more stable.
Good work!
@PaulSinnema
No need to apologise, we are all frustrated sometimes. My strategy is very often to work in parallel so I can switch to something else and wait for couple of days for answers or patches/fixes. Yes, I have access to internal information and this comparison might not be fair (there are deadlines too).
@HalilDoganBolak
Yes this (3 persons for 6 weeks w/o new features) would be in ideal world and our world is not ideal.
... and Xamarin.Auth has nothing to do with Redmond... It is open source and it is good-will of Xamarin (Microsoft) - actually team members - to continue maintenance of such libraries.
Here is [my personal] story that will give you feeling about "how it works"...
I work on components team (used to be international contractor) and during Xamarin.iOS Unified (64b) push (project conversions I picked N libraries from spreadsheet (Google Docs). I cannot recall the number N I think 20+. Among those 20+ libraries it was Xamarin.Auth, Xamarin.Social, Salesforce SDK, SAP etc. Since that day (when I picked those libs) I was listed as "maintainer". I never planned and wanted to be OAuth expert, but the number of comments, mails, issues ending up in my mailbox was growing. I had 2 options - forget it and let Xamarin.* libs to die without support or start digging through the code (I inherited the code) and save the libs and invested engineering effort. I chose 2nd option, but I had to postpone all my other plans. Xamarin.Auth was copied/pasted (baked) in Xamarin.Social, Salesforce SDK in 2012-2013. After I prepared nugets I had clear path to remove that code from those libs and make them dependant on Xamarin.Auth nuget. So always the latest code. This part was done in 2016.
It was not fun to get mails, comments etc 2-3 times per week about "Google said embedded web views will not be allowed". Why? Because I knew that from day 1. Some forum users were pasting those questions all over the forums in different threads forcing me to answer them and when I asked them not to do so (spamming the forums) they marked my answers as spam. Answering every question (PR with community) needs context-switching for me from writing code and docs and after some level of granularity it becomes problematic like multitasking for processors.
Since March I added Native UI support which is completely another beast and not trivial AND Xamarin.Forms support which was not planned (and I was afraid that I will not be able to manage maintenance).
There were angry users (with reason) that were flaming Xamarin.Auth "management team" and their decisions while praising devs for their work on some features like Native UI. The problem is - there is no devS, but only dev and dev team is the same as management team. Bottom line - there is one (1) person working on Xamarin.Auth which is trying to become OAuth "expert".
Xamarin.Auth is far from ideal, but there are also some other libs and issues I work on. Xamarin.Auth is far from ideal, but I'm working on it. Reviving Xamarin.Auth brought influx of new feature requests (in the direction of OpenId) and there are still a lot of issues and stuff that must be done before new features. I have roadmap doc that reflects my point of view based on user feedback, but I'm open for discussion...
Basically - forget 3 people. OK only if someone jumps in with PRs then it is possible. Otherwise you'll need to talk to me.
... and I still need more info about "bad code"... (I completely agree with missing/incomplete docs, but I needed rest, so I took vacation inlast few weeks)
This is how it looks like in not-so-ideal world...
This is my issue... I have been using Xamarin for almost 4 years now... and it's nowhere near as stable as it used to be.....
Take me back to 2 years ago when the Android AXML designer used to work perfectly and never crash or hang on loads... Now when I double click on a layout file I can only hope will it load or not...
I agree. Both the Android and iOS designers don't work very stable at the moment. Even for iOS I'm starting to use the XML. I only use the editor to add new components and position them because the XML is rather complex with mapping of ID's and position of the element within it but I edit my properties in in the XML because the editor is simply buggy. For Android I hardly use the editor anymore, sparing me the frustrations of crashes, hangs and all the other irritating stuff. Some of the features do work but most of them hang, crash the editors. For instance the sync of the iOS editor with the properties window and Document Outline effectively doesn't work anymore. You're constantly confused about which components property you're working on and can't rely on it at all.
What I don't understand is that these errors are very hard to mis. Even for the smallest of forms you design the editors show all their flaws meaning no one is using them so no one is reporting these errors anymore. The focus must be on XAML. I haven't used that editor for Xamarin yet but I bet it is more stable.
They may be hard to miss, but if only one person is working on each component, they also have to meet deadlines and implement new features are otherwise dependent on pull requests.
I believe the Xamarin staff is way too small and the aquisition by Microsoft should have had the effect that they had way more resources now, but that doesn't seem to be the case. Which is disappointing.
But you need to remember that from my understanding, whether we talk about the iOS designer or the android designer or the Mac connection or the slow build times, that there is no "team" assigned to this. And there can be no management issue inside the team, if there is only one person per project or even multiple projects per person. There is only one management issue, at the very top...
That is a sad conclusion. I assume you have inside information about the size of the team? I would expect MS to charish this product since they said mobile development is very important to them. Is it in your opinion a resource problem (and with that a knowledge problem too I guess)?
Today I'm also joining this complaint thread.
I just discovered today that .netstandard 2.0 is NOT supported on the stable Xamarin.Android on VS 15.3.
It is only on Xamarin.Android 7.5 and the stable ver. is Xamarin.Android 7.4.
I changed my .netstandard on VS 15.3 to 2.0 and tried to build Android App and no avail.
I spent about it 2 days and didn't understand why it worked on .netstandard 1.1-1.4 and not on 2.0 (2.0 should support all versions...no?...)
I thought that if Microsoft bringing .netstandard 2.0 to VS , it should be everywhere, no?
So , No. Xamarin.Android on VS 15.3 is NOT supporting .netstandard 2.0 and you should build class libraries <2.0.
Why there is no doc about it?
How microsoft can release half product for .net but not for Xamarin?
Annoying!
@zahikramer Yes that is correct given
netstandard 2.0was recently released. The documentation onnetstandard20being finalized shows the exact versions of Xamarin SDK support. This has been documented since early August:https://github.com/dotnet/announcements/issues/24
Specific commit: https://github.com/dotnet/docs/commit/3abd091e004cc1aff4f0427f47726b8849a670df
This is also outlined in the
.Net Standarddocumentation online:https://docs.microsoft.com/en-us/dotnet/standard/net-standard
Just to recap:
netstandard 1.0->1.6is supported in the current Stable release which is also known as 15.3.netstandard 2.0support is coming when 15.4 is released to the Stable channel. It is currently in the Preview channel if you want to use it today..netstandard 2.0is incremental by nature in the sense that although the standard is final; many platforms, NuGets, tooling, and much more will need work done to support the new standard. Xamarin already includes this support in the current Preview. Other platforms like UWP cannot target the new standard until OS changes release.Based on release history:
https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes-v15.2
https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes
You should expect 15.4 to go stable in about a month.
I hope this helps! Please do not hesitate to ask any further questions about
netstandard! I would highly recommend asking in the following issue for a faster response time:https://github.com/dotnet/standard/issues/439
Sorry @JohnDuglas , you are wrong.
The announcement of .net Core 2.0 and .netstandard 2.0 didn't emphasize it:
https://blogs.msdn.microsoft.com/dotnet/2017/08/14/announcing-net-standard-2-0/
https://blogs.msdn.microsoft.com/dotnet/2017/08/14/announcing-net-core-2-0/
The big announcement is "Visual Studio 15.3 has .Net Standard 2.0 and you can use it and forget all the problems of compatibility"
Yes, it saying there the xamarin platform versions that it would work there, but
It Didn't say that Visual Studio 15.3 will NOT work for xamarin users - what is
the point for creating .netstandard 2.0 class library if i can't use it on Xamarin.Android/ios ????
I gladly installed 15.3 and changed all my .netstandard libs to 2.0 for "launch and forget" all the compatibility problems and only after 2 days on not succeeding to work on Android App i started to look and finally found this.
Xamarin/Microsoft should be more transparent to their developers and put this warning with BIG FONT LETTERS!
Well, I don't know exactly what is going on.
Apparently , Xamarin.Android 7.4 IS working with .netstandard 2.0.
I updated eShopOnContainers Demo project on netcore2 branch, compiled and run on emulator and IT IS WORKING with netstandard 2.0 on VS 15.3.
The only problem was XF 2.4.X.pre is not full compatible with netstandard 2.0 so XAMLC was not working good and corrupted the code.
After removal of XAMLC my app work like in netstandard 1.4.
So what is going on???
It is essentially compatible, but the tooling is not complete and it's not officially ready.
@JohnDouglas @TobiasSchulz.9796 @PaulSinnema
I have been working with Xamarin for 4 years now, established the Dutch Mobile .NET Developers meetup (500+ members) and in general promoted the platform tirelessely.
But I have to confirm that (at least when working in Visual Studio on Windows) the IDE has longstanding productivity killing issues. Especially in Android builds with a lot of image resources and when using the Android support libraries and things like google-services.json. I recognize practically all the issues mentioned above.
These issues are common. Any team doing real-world App work wil encounter many of them.
VS freezes for minutes at a time at the slightest touch (in VS 2015 and in VS 2017) when adding a project item, updating a NuGet package, doing a clean.... and when it does, my CPU is at <5%, low network traffic, low disk activity, lots of memory and HD space left. I use fast SSD, wired network to Mac, anything I can do to increase the crawling pace...
I mean really... add an empty C# class file -> "VS is busy" for minutes? What is this software doing? What is it waiting for while my machine and I are idling away, losing my focus? This has been the case for all VS 2015 and 2017 versions, stable and preview, for most of the past year (now at VS2017 15.4 Preview 2)
My recommendation to Microsoft would be: have a team continuously build and maintain (meaning upgrade to latest tools and nugets) a real-world sized app on all platforms, and publish their development productivity metrics, and work to achieve a reasonable productivity level.
Metrics such as :how long for a build, clean, how often "VS is busy" for how long, does debugging work, does deploy work - all these things that are fundamental to being productive with this great technology. Things like the Xamarin Live Player may help a lot too, but also there - just 2 great guys working on it a small part of their time. Put a dedicated team on it!
I am sure the Xamarin teams are working their asses off to give us what we have today. They are capable and motivated people.
At Evolve 2016 I spoke with Xamarin team members (including some very prominent ones) and heard just how small certain teams were. However after the Microsoft take-over I expected that this would be scaled up tremendously with experienced IDE developers. However even at that time Xamarin team members told me that if was more them helping the regular VS teams with mobile / crossplatform than the other way around.
And it sounds like this has not changed significantly today.
So please Microsoft, expand the Xamarin teams a LOT and practise real-world sized dogfooding for apps. Get the Xamarin part of VS at the same great productivity level as the rest of Visual Studio!
@VincentHoogendoorn.4333 Hoi Vincent, Thank you for your contribution to this topic. The latest updates have made things better but it is still very buggy in VS2017. I am going to develop more apps but I'm unsure if that is going to be with Xamarin.Forms or native. I fear the possible bugs in Forms as well as the difficulties I may encounter writing my own renderers for special cases. I have no experience with X-Code and Android development other then this C# entrance so I'm sticking with Xamarin for the moment I guess.
I castigated one of our team for frequently reinstalling all packages or restarting his machine to try to get the project (which builds fast on Mac) to build with VS2015. Until I tried it myself. A real struggle and unpredictable productivity on Windows.
@JohnDouglas @JamesLavery I recognize this - for years I've had the nagging feeling that Visual Studio on Windows is a second class citizen for the Xamarin teams; the Mac tooling always seem to be better tested, better quality.
I tried using Xamarin Studio and Visual Studio on a Mac for Xamarin development, but as you do more development besides apps-only (e.g. also backend services), and you work in enterprise environments, you just want the power of the flagship product, the frictionless integration of the Windows platform, and all the development tools that are available on Windows. So I switched back.
Visual Studio for Windows is arguably one of the most productive and capable IDE's on the planet, it leads in innovation at a great pace for many years now, while also delivering great stability and performance. This is a huge achievement and there is no way another IDE product on Mac is ever going to catch up, let alone keep up, with that.
Building a lightweight IDE for the Mac for mobile/cloud development is a great initiative, and I applaud it for increasing Xamarin adoption by more groups of developers. But it does not target the Enterprise developer.
I cannot imagine that Microsoft(!) really wants enterprise mobile developers abandoning their own flagship IDE because they keep prioritizing building a lightweight IDE for the Mac.
Microsoft should put their effort into making Xamarin development in VS on Windows just as productive (stable, performant) as non-Xamarin development - which should be at least as productive as in VS for Mac.
I hope someone at Microsoft (@MigueldeIcaza, @NatFriedman, @DavidOrtinau ?) takes notice and responds to the needs of enterprise developers.
And if we are heard, please provide some transparency on what actions will be taken - resources, dogfooding approach (Windows or Mac, lightweight or real-world apps, if any?)
I'll tell you my story.
Big C# and .NET fan. I work in a small team that writes mostly desktop C# projects. When I joined the team, we used to work with VS2013. Being a small team, I have a voice in choosing the tooling. I was a big proponent of buying licenses for VS2017 because C# 7 and Roslyn and all that goodness. Done. Never looked back.
While on VS2013, I tried halfheartedly to write a cross platform project just to test Xamarin because I had heard all those good things about it and I had high hopes for it. I had all sorts of issues, I don't even remember what, because it was just a halfhearted try anyway. Disappointing, but I blamed the almost antiquated VS2013 and didn't think much of it. During this try I found out that there was no designer for Xamarin forms. Heartbreakingly disappointing. I also found out there used to be one. Now this is just ******* ridiculous.
I don't remember if I tried again on a VS2015 community edition before we got the VS2017 licenses. If I did, I don't remember the outcome. I would assume it was bad as well.
Then, the time came where we were asked for an Android project. The perfect occasion to put the mighty Xamarin to work since we would get a project running on both mobile platforms that matter plus my Windows mobile with the same codebase. So I pushed and I pushed and we decided to give Xamarin a go. How cool is that?
Well, not that cool since it didn't work. With a new project. With default settings. With no modifications from the default project template.
Let me see if I remember how it went, because I have never seen so many errors and problems and unfixable warnings in my life.
First you should know I'm one of those guys who REALLY trusts his tools and especially his compiler. When the compiler gives a warning, I fix it. Warnings stink and I like to smell only clean code.
With Xamarin it was impossible to get rid of all the errors AND warnings.
So, I went for the full cross platform: Android, iOS and Windows 10 mobile.
At first, Android would not build. It just wouldn't. It did work on Windows. But, then again, the Windows project is basically just a UWP project so of course it worked.
I wasted days searching for the reason why it didn't work, pulling my hair and banging my head against the desk. No luck. Wanted to contact Xamarin. No luck; there is no easy way to do that. Luckily some guy on the team had some vague experience with Xamarin from a previous job and managed to find out that there was some checkbox in the settings to automatically download nuget packages or something like that on project loading or creation or something. Without it, xamarin just wouldn't create a valid project for android and ios. It would work on windows, because that was made by Microsoft, not xamarin, so of course it would work.
Yay! Android would build now. Ok, time to create a new project just to see if the damn thing works now. New project, all works, many warnings. Will get back to those.
I tried using live player. No luck. Maybe it was the corporate network, I don't know, I don't care. I tried using some 3rd party extension, livexaml or something like that. Worked like a charm. I mean, it's a ****** way to live, but hey, if xamarin cannot make a damn gui designer, that's the best you can get. Then I discovered the newer extension livereload or something from xamarin. Holy moly, I mean if the third party worked, this should surely work like a charm. WRONG! It never worked. I even tried the ports that the 3rd party used. Nothing worked. Apparently they had this covered in the official documentation for livereload and they had the following solution that they called "easy" or "simple" or something like that: use a 3rd party MQTT server in a Ubuntu linux virtual machine running on Azure. ARE YOU ******* KIDDING ME?! The 3rd party livexaml extension just ******** worked and xamarin, the maker of this **** needs a 3rd party mqtt server running in a Ubuntu virtual machine on ******** azure?! Jesus Christ!
**** it, I will just buy the 3rd party extension.
Let's get back to the warnings.
Started picking the warnings one by one. At some point, there was one warning that was mentioning some target platform mismatch or some crap. I searched and I searched and there was only one way of getting rid of it. I have no idea why it didn't just make the change itself. Whatever. Maybe xamarin folks just like pissing everybody off. Before doing the change I had the horrible idea of updating all the nuget packages in the solution just to see if the warning would still be there. Holy ******** ****. Big BIG mistake. From that point on, nothing built. Not this project, not any other new cross platform project, not any android-only project, nothing.
At this point I was so exhausted, I just gave in and did what my boss kept telling me to do: install Android Studio.
Now, don't get me wrong. I don't blame xamarin.
It is in xamarin's DNA to be an open source ball of mud.
I blame Microsoft. When they bought Xamarim and decided to put them in Visual Studio, as a full-featured development framework, seemingly on par with their traditional frameworks, they should have first fixed this ****show that is Xamarin.
So, no, I don't care about the feelies of xamarin developers. Their product sucks. Their product has bad tooling. AND THEIR PRODUCT DOESN'T EVEN WORK WITH THEIR OWN EMPTY PROJECTS.
It is that bad.
But it is all Microsoft's fault.
@ORLY I can read a lot of pain from your post specially where put your head on the block when you pushed for Xamarin development and I agree with a lot of your findings (I don't like the F-word though). I've contacted Scott Guthrie about this and he confirmed our pain but no action has been taken since then it seems. I would avoid using Xamarin at the moment. The platform is just too unstable. At a former job I worked on 1 App for 2 platforms (Android and IoS) for more than 8 months. The App itself wasn't very complicated but all the fuzz around Xamarin just made it very hard to make progress. I'm now at another job using ASP.Net and 'normal' development stuff so I'm out of the Xamarin loop for the moment. It is painful to say but I am avoiding jobs that involve Xamarin at the moment although I would love to do mobile development. Guess I have to learn the native languages.
It’s just so slow and I thought I would solve the problem by getting a monster that has PCIe SSD, GTX 1080, 4 x Quad Core Xeons, 128GB of RAM
The results are unbelievable, the solution load time or app build time is almost the exact same as my other machine running a single QC Core i7, SSD and 16GB of RAM.
When checking the Task Manager, the VS seems reluctant to consume even a tenth of the available computing resources!
Now, should I try a server with 2TB RAM and 4 x Octa Core Xeons, wait for next VS release or simply switch to NativeScript/ReactNative for good?