Xamarin Forms should be an easy sell.
But there’s a shadow that hangs over Xamarin, one shared by most mobile dev platforms: FIDDLINESS.
Getting everything working can be curiously painful. Full disclosure, I’m talking about the following setup:
This seems to be an Android code generation thing, as I’ve seen it in Cordova projects as well.
In Cordova, the fix is to point at a temporary build directory where everything can be built with short paths.
In Xamarin, the same options exist.
Can shorten folder names under VS’s control i.e. Project folder and subfolders:
<PropertyGroup> <UseShortFileNames>True</UseShortFileNames> </PropertyGroup>
Chances are this won’t help, so the main option is: NOTE: Must end in slash
<PropertyGroup> <IntermediateOutputPath>C:\Projects\MyApp\</IntermediateOutputPath> </PropertyGroup>
It should be noted that these options didn’t work for me. They definitely solved this particular problem but created numerous and seeminly un-replicatable problems.
I’ve included these for completeness, but I’ve gone through them in another post (at the bottom).
The biggest bit out of those is that the build architecture defaults were incorrect, and the simulator needs to be started prior to running the first time (it takes a while to start up)
Upgrading Nuget packages and getting running again is painful. Xamarin Forms nuget packages are tightly bound to some of the other Microsoft packages, and while those packages are also getting updated, it doesn’t realise. You can probably force it, or go Prerelease (must have been a dependency somewhere), but then I couldn’t get anything running again due to depencency issues across the board. This also seems to be due to .NET Standard support which leads us to…
It seems that this relates to the Microsoft Store not supporting .NET 2.1 yet, and occured after upgrading some Nuget Packages to a Pre-release version (to try to get around the above issues). Solution was to run as Debug (non-store related configuration). As aluded to above, I was still unable to get things running, but this wasn’t the reason.
Debug mode, why this betrayal? Turns out it’s another case of bad defaults.
BoxViewis a strangely named control, used for squares and rectangles, and contains no content. In WPF, it would be
StackPanel), but the different controls are a bit interesting to get used to
contentattribute. On reflection, it’s likely because there’s fewer general components. Instead of having a
TextBlock, one essentially an implementation of the other, there’s just