Nick's .NET Travels

Continually looking for the yellow brick road so I can catch me a wizard....

Unboxing Xamarin.Forms Shell in Visual Studio 2019

In my previous post, Unboxing Visual Studio 2019 for Xamarin.Forms, I covered creating a new Xamarin.Forms project in Visual Studio 2019. The Xamarin.Forms project template hasn’t really changed much and the default application you get is the same as what we were seeing in the most recent updates for Visual Studio 2017. However, there are some big updates coming down the line for Xamarin.Forms developers, not the least is Shell, which is covered in the introductory post.

I’m going to take Shell for a bit of a spin, and to do so, I’m going to use the new project templates that are available for download – These will only install into Visual Studio 2019, so if you want to try them out, you’ll first need to install Visual Studio 2019

image

An hours or so later…

image

After installing the new templates I went about creating a new project

image

It seems that the new templates must have completely replaced the previous templates – not a great start, considering I’m likely to want to be able to create a non-shell based Xamarin.Forms application.

image

Ummm…. Where’s the UWP support? Seriously, as if UWP wasn’t failing hard enough as it is, the fact that there doesn’t appear to be UWP support in the initial Shell release it a bid depressing.

After that the new project screens all look familiar, so the next thing we’re looking at is the default solution structure.

image

My first comment (as usual) is that the view models are stuck in the same project as all the UI elements – I consider this to be incredibly bad practice as it means you end up with a mess of dependencies and it’s way to easy to break the separation of concerns between view and view models. Having said that, this is a getting started templates, so I guess if they’d added another project it would probably alienate other developers who prefer to have everything in a single project.

The great thing is that I can select either iOS or Android as my startup project and hit run – a minute or two later after the emulator has started up the app has been deployed and is running.

Side Note: This post actually took me a couple of sessions because I got interrupted and it took a couple of days for me to get back to it. When I did, I accidentally opened the XamShell app I’d created in Visual Studio 2017, where it builds and runs without issue. Of course I don’t have the Shell templates.

Here are a couple of screenshots from the running app – Firstly I love that they’re replaced the Xamarin logo added to the new project, as shown in the splashscreen. Note that this is not actually a splashscreen and that in fact they’re setting the background on the main activitiy. There’s so debate about whether this is best practice, or whether it’s still good to use a splashscreen to improve the perceived boot time of the app.

image

This is the master-details template, so we get things like the burger menu. The main screen includes a basic list and an add button in the navigation bar – pretty stock look and feel.

image

The about page is a little more interesting but again nothing mind-blowing.

image

If we look in the main XamShell project we notice that in addition to the usual App.xaml, which is required for Xamarin Forms, there is now also an AppShell.xaml. At this point I did in fact switch back to Visual Studio 2019 because opening AppShell.xaml in VS2017 seemed to be a bit of a broken experience.

Opening AppShell.xaml the first thing I noticed is that styles have been setup and a combination of implicit and explicit styles defined – yes!!! this is great to see in a template. Next I noticed that two pages have been defined: Browse and About – this confused me as there are actually 4 pages included in the project. On checking the code, it appears that the other pages are dynamically created as needed. The introductory documentation on Shell provides a good overview of the key elements that make up the Shell hierarchy.

My initially impressions are that this is going to be great for jump starting basic mobile applications. I’m interested to see how far this can be taken and how it can handle more complex navigation patterns and applications. I’ll explore further the various aspects of Shell but I’d encourage all Xamarin Forms developers to give Shell a chance – let’s see whether this can be made into something amazing by providing constructive feedback to the XF team.

Unboxing Visual Studio 2019 for Xamarin.Forms

I’ve just installed the preview for Visual Studio 2019 and wanted to share the experience of creating a new Xamarin.Forms application.

Firstly, the startup screen. Whilst I’m disappointed not to have the news feed, the new startup screen gives you a quick launching pad for whatever it is you want do in VS2019.

image

Let’s go with “Create a new project”. The search/filtering works well to quickly find the right project template

image

Now let’s provide some generic project information.

image

Ah and now we’re back to a familiar dialog for creating Xamarin.Forms applications. Hooray!!! there’s no option to use a shared library any more – good riddance. As you’ll see we get a .NET Standard 2.0 project where our XF pages and other logic will go.

image

And now we have the usual solution structure for an out of the box XF application containing the project that’ll house the pages (ie VS2019XFProject) and then head projects for iOS, Android and UWP.

image

Let’s hit run and check out the newly created project – notice I picked the Master-Detail template early so we get a basic layout with a hamburger button in top left.

image

And that’s it. BTW the chrome around the edge of the coding window seems to be progressively shrinking with each progressive release of Visual Studio. Eventually it’ll be carved back to what Visual Studio Code offers.

Android Emulator Exception after updating to Visual Studio 15.9 preview 3

I noticed earlier this evening that there was an update available for Visual Studio 15.9. Normally I wait a few days to update as I’m not in any particular hurry but I noticed in the blog post and release notes that work had been done on the Android build and execution. I also remembered that I hadn’t updated Visual Studio or my emulator images since updating my Surface Book 2 to the latest Windows update – it contains a fix for the awful performance of the Android emulator running on Windows hypervisor. Anyhow, the upshot is that I updated Visual Studio to the latest preview….

I decided to drop my existing emulator images and create new ones. Unfortunately this was a bad idea as I was then unable to start the new emulator images. When I attempted to start the emulator I would get an error stating “The requested operation requires elevation. (Exception from HRESULT: 0x800702E4)".

image

Turns out I’m not the only person seeing this, as someone had already reported this issue.

It also turns out that there’s a simple solution…. close the Android Device Manager and just hit Run from within Visual Studio. Turns out that this causes the emulator image to boot, deploy and run the application. And all the updates seem to do the trick, debugging is back to an acceptable speed.

Debugging Not Working for .NET Standard library in UWP Application

I was attempting to debug some code in a .NET Standard library that was being referenced from a Xamarin.Forms base UWP application. Unfortunately, it didn’t matter where I set the breakpoint in the library, they were never hit. Initially I thought that this was related to it being a multi-targeted project but it turns out this same issue applies to a regular .NET Standard library.

The only hint I had was when the application was running there was a yellow warning triangle on my breakpoint which a pretty unhelpful, yet accurate, message.

image

Now you’d have thought that since this project was included in the same solution as the application, that it was being built by Visual Studio as part of building and running the application, that you wouldn’t have to do anything special to get step through debugging to work. This is not the case – it appears that debug symbols can’t be loaded – huh! I mean seriously, we expect better.

I had also recently installed the first preview of Visual Studio 2017 15.9 so I thought that might be the issue but no, even opening it in 15.8 still showed the same issue.

So it turns out that there is an issue with the default build configuration – open project properties for the .NET Standard library and click on Advanced under the Build tab

image

The default “Debugging information” value of Portable is what the issue is. Change this to Full or Pdb-only

image

Doing this will set the debugging settings for the currently selected target framework and platform. For example for my project it generated:

<PropertyGroup Condition="'$(Configuration)|$(TargetFramework)|$(Platform)'=='Debug|netstandard2.0|AnyCPU'">
   <DebugType>pdbonly</DebugType>
   <DebugSymbols>true</DebugSymbols>
</PropertyGroup>

I simplified this so that it would always use these debugging settings when doing a Debug build

<PropertyGroup Condition="'$(Configuration)'=='Debug'">
   <DebugType>pdbonly</DebugType>
   <DebugSymbols>true</DebugSymbols>
</PropertyGroup>

And there you have it – step through debugging should now work. I’m not sure why it’s so hard for Visual Studio to either use this option by default, or at least provide a useful warning that directs the developer to either documentation, or actually switches the setting automatically.

Xamarin Development with Visual Studio 2017 Version 15.5

Normally I don’t bother posting anything about the progressive updates that roll out for Visual Studio 2017 but version 15.5 adds a bunch of new features that are set to make app development using Xamarin just that little bit nicer. Pierce has a great post covering a lot of the relevant updates - https://blog.xamarin.com/whats-new-visual-studio-2017-version-15-5/ 

Over the last 6-12 months the debugging experience for Xamarin applications on both iOS and Android has got significantly better. I posted recently about my discovery that the Google Android emulator was actually quite good (https://nicksnettravels.builttoroam.com/post/2017/10/11/Hey-who-moved-my…-Visual-Studio-Emulator-for-Android.aspx), and whilst the build and deploy process is still painfully slow on Android, it’s definitely getting better. Now with Live XAML Previewing supported in the emulator, at least the iteration whilst making UI changes will be quicker.

I’ve also been using the remote iOS simulator – particularly at home where I use a remote build server that is on the other side of the room, it’s painful to have to deploy to a real device. I have seen some issues where debugging with the remote iOS simulator seems to just lock up but I think that was only an issue in the preview of VS mixed with the latest Windows Insider build (unfortunately neither team seems to care much about stability with their preview builds Sad smile).

Whilst I’m talking about doing iOS development, the other significant improvement in 15.5 is the messaging regarding connecting to the Mac build agent. In the past this has been limited to success/fail; if you wanted any more details you really had to go hunting in the log files (usually it ended up being a result of a mis-match of SDK versions between the build agent machine and the machine with VS installed). The dialog for connecting to the Mac build agent has a nice progress information pane at the bottom that shows what step the connection manager is at and reports any issues – nice work MS, this is really, really useful!

Ok, I can’t end this post without pointing to the fact that Microsoft has finally worked out how to get the elephant out of the corner of the room, and by this I mean the support for PCLs v’s .NET Standard for new projects. Prior to this release if you created a new Xamarin project it would create a PCL for your shared code (and yes, I’m ignoring the Shared Project option, cause this should never be selected), and it was rather painful to have to upgrade it to .NET Standard (see https://nicksnettravels.builttoroam.com/post/2017/08/26/Getting-Started-Xamarin-Forms-with-NET-Standard.aspx if you’re still on an older version of Visual Studio). Now when you create a new Xamarin project you get a .NET Standard library and you can pick which target platform(s) you want to target (I would encourage you to pick all, unless you have a particular reason not to!).

Grab the latest version of Visual Studio 2017 and get coding!

Hey, who moved my… Visual Studio Emulator for Android?

A while ago, in response to a common frustration from Xamarin developers, Microsoft released the Visual Studio Emulator for Android and it even made it into the Visual Studio installer:

image

As a long-serving Windows Phone developer I embraced this decision as the emulator was based on Hyper-V which meant that it played nicely with the Windows Phone emulators – I could now do cross platform development, even when I didn’t have real devices with me. Unfortunately, Microsoft have indicated that the emulator is no longer going to receive updates, so anyone wanting to dev/test on more recent builds of Android are out of luck. This was really frustrating as the emulator was both quick (relative to the out of the box emulators from Google – historically) and didn’t require another emulator sub-system (as it worked on Hyper-V).

Recently, Microsoft have actively discounted Windows Phone, making it very hard to justify any developer resources on building for Windows Phone…. it also makes me question the value proposition of UWP over WPF, but that’s a topic for a different post. The upshot is that there is no longer a reason for me to have the Windows 10 Mobile emulators installed, which means I have no need for Hyper-V, which means I can use any one of the great Android emulators out there that don’t play nice wiht Hyper-V.

What’s really cool is that Microsoft have included the Google Android Emulator in the Visual Studio installer. You need to make sure that both the Google Android Emulator and the Intel Hardware Accelerated Execution Manager are installed.

image

After installing the Google emulator you can launch your application on the emulator the same way you would to a real device – it appears in the devices dropdown. You can also access the different emulator images via the Android Emulator Manager.

image

Whilst the Android Emulator Manager is not a great looking dialog, it does allow you to customise and launch the different emulators.

image

I was so surprised when I launched the updated emulator. I was expecting an old, slow, crappy looking emulator but was surprised with an updated emulator shell with all the features that I’d come to expect from an emulator.

image

I’m a convert – Whilst I’ll still use a real device for most development work, having a good emulator is critical for those times when I don’t have a device with me. Cudos to Microsoft for firstly pushing Google to build a better developer experience and secondly making the Visual Studio installer so simple to install the emulator.

Sidenote: I did have to update one component from the Android SDK. Make sure you read the build output window in Visual Studio if you are running into issues as it pointed me to an out of date component.

Visual Studio or Blend Exception When Using XAML Designer

Today we ran into a nasty issue with the XAML design experience in Visual Studio and/or Blend throwing an exception:

image

Exceptions in the designer a quite often a result of code being run by the designer that is insufficiently protected using try-catch, or has assumptions that some app startup code has run, resulting in an exception that bubbles up and causes the designer to fail. For these exceptions, I recommend checking out the post How to Debug the XAML Designer by Travis Illig, which uses another instance of Visual Studio to debug and hopefully identify the code that isn’t playing nice.

Unfortunately in our case, this didn’t help because Visual Studio (and same in Blend) was failing to resolve an assembly reference.

image

One thing that Travis point out is that there is a ShadowCache folder located at C:\Users\yourusername\AppData\Local\Microsoft\VisualStudio\15.0_317bf9c1\Designer\ShadowCache (note that you’ll need to change both “yourusername” to be your username and perhaps even the 15.0…. to reflect the current version of Visual Studio. Change VisualStudio to Blend if you’re using Blend). Within the ShadowCache folder there will be folders created for each application where you use the designer, and then a series of “bin” sub folders that will contain assemblies referenced by your application.

image

The issue we found was that we were referencing a nuget package that includes both a UWP dll as well as a .NET Standard dll. Whilst the UWP dll was being copied into a bin folder, the .NET Standard dll was not. Our fix for getting the designer to work was to copy the .NET standard dll into the same folder as the UWP dll.

Unfortunately whilst this gets the designer to work, it is a sub-optimal experience as it appears that it needs to be done every time Visual Studio is run, or when the designer process is restarted.

Microsoft Continues the Integration Between Blend and Visual Studio

Years after Microsoft attempted to lure designers into the world of app development by giving them a tool where they could assist with the designing of applications, it appears that Microsoft still recognises that design and development, whilst different roles, go hand in hand as part of the development process. In Visual Studio 2015 the integration between Visual Studio and Blend for Visual Studio becomes even more apparent. The changes range from the simple things, like the link to open Blend from within Visual Studio being renamed to “Design in Blend,” through to intellisense in the XAML editor in Blend and better alignment of the various tool windows.

image