Subscribe: Nick Randolph's .NET Travels
Added By: Feedage Forager Feedage Grade B rated
Language: English
application  forms  library  net standard  net  platform  project  states  visual studio  visual  xamarin forms  xamarin   
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Nick Randolph's .NET Travels

Nick Randolph's .NET Travels

Continually looking for the yellow brick road so I can catch me a wizard....Join me as I explore the world of cool devices, neat technology and uber geeks. I spend most of my time talking about Microsoft related technologies such as the .NET Framework, SQ


PWA Follow Up

Fri, 02 Mar 2018 11:21:59 +0600

It’s clear that talking about Progressive Web Applications (PWAs) is all the rage. I noticed today that fellow Microsoft MVP, Adam Pedley who runs the Xamarin Help website and blog, posted about where PWAs and Xamarin.Forms fit. Whilst I’m not sure I agree with his opening statement about PWAs being started by Google (there is a long legacy of different browsers providing pseudo-offline features which pre-date the term PWA, so the concept itself isn’t new), I will definitely agree that it has been Google that has been championing the cause, with Microsoft adding some behind the curtain support (eg One of the most interesting points that’s worth highlighting is the disconnect between the device features/capabilities that the web and client applications (native, Xamarin or Xamarin Forms) can take advantage of. Whilst the difference is being progressively eroded, there are still plenty of areas where a client application is the way to go. Shout out to



What’s a Progressive Web Applications (PWA) and Why does my website want to be one?

Wed, 28 Feb 2018 13:37:52 +0600

My last couple of posts (App or not to App and Cross-platform applications – PhoneGap/Cordova, Xamarin, PWAs and now Flutter) have been discussing different aspects of build applications. In particular in my previous post I discussed deployment models as being one dimension of applications. In this post I’m going to focus a bit more on the one of the hottest topics going around at the moment, Progressive Web Applications, or just PWA for short. If you’re new to this topic, I’d suggest a quick detour across to the Google developer site where they have an entire section dedicated to PWAs, and it’s a great starting point to understand the importance of PWAs and the experience that a good PWA should deliver.Side note: I had to laugh when I first went to the PWA page on the Google developer site as it talks about “A new way to deliver amazing user experiences on the web”. This is really what happens when you let the marketing get out in front of technology. Unfortunately I’ve see this type of propaganda so many times (Flash, Silverlight, HTML5) that it actually makes me a bit nervous as I start to think about another learning curve.One of the quickest ways to get past the marketing fluff is to click the PWA Checklist button in the top right corner of the PWA page. Here’s a list of some of the other useful links on the Google developer site in relation to PWAs:- PWA Checklist- Lighthouse- PWA Summit videos (a bit dated but still a good place for building familiarity)Now that I’ve assigned you a bit of reading, let’s talk about what all the fuss is about. After scanning through the PWA checklist it becomes very evident that there are a couple of key topics: security, offline, seo and notifications. Let’s break these down, with specific attention to why they’re all important aspects of a great application (not just a PWA).SecurityWhilst not the first topic that comes up in regards to PWAs in the checklist it’s very evident that security first is still a key mantra when building the next generation of applications, which is made clear by the first item in the checklist which indicates that all content should be delivered across HTTPS. In the context of application development there has been an increase flow towards the use of HTTPS (for example the release notes for iOS9 by Apple indicated that all new apps should use HTTPS). Without HTTPS it’s just too easy for any third party to intercept and read/modify the traffic to and from the application.OfflineThis is a biggie when it comes to PWAs and in fact you could argue that this is probably the most significant departure from traditional web development. The introduction of service workers that can intercept requests, cache and dynamical change request behaviour opens the world to building intelligent offline-enabled applications. However, from an offline-ready application development perspective the current thinking in this space seems relatively immature, with most of the priority being placed on caching the components that make up the application (ie the HTML, CSS, JS that make up the application), rather than offline data and synchronisation scenarios.SEOOptimising your application for search has been one of those things that every developer says they’re going to do but rarely do they do it, and seldom is it done well. In terms of application development, one of the challenges faced by developers is how to define a set of deep links that will resolve both on the web and in the app. In structuring an application, it should be possible to provide an external link to any part of the applications, and in an ideal world the the link can be shared via any method, whether it be a link on social media, or via private correspondence such as chat or email. The upshot is that by structuring an application this way, you’re already half way there to making it indexable – you just need to make sure that the web application can be statically crawled so that relevant sections will appear in search results.NotificationsAnother asp[...]

App or not to App

Sun, 25 Feb 2018 04:13:01 +0600

Following my last post there were a couple of interesting tweets that made me revisit (again) the discussion of whether building an app is the right thing to do. For example, @GeoffreyHuntley said:Decision time: - #0 Don't make an app unless you absolutely have to. - #1 React + React Native (insane productivity) - #2 Xamarin (stagnating tbh) - #3 Flutter (innovator - watch this space)To be blunt, options 1-3 are all semi-painful – I’m not going to go into detail as to why, as that’s not the point of this post but needless to say that each one has their pros and cons, and none are what you’d consider an ideal development experience. Option 0 sounds like a great option and with the rapid development of Progressive Web Applications (with service workers being included by both React and Angular) it really does seem that not having to build an app is the way to go.Ok, but in that case, when would we build an application? Before we answer this, I think it’s worth revising what the notion of an “application” or “app” actually means. If you do a search for “App” on Wikipedia you get a number of responses:Mobile app, software designed to run on smartphones and other mobile devices Application software that causes a computer to perform tasks for computer users Web application or web app, software designed to run inside a web browser(And particular note that the term “website” is not included here as according to Wikipedia a website is “a collection of related web pages” – personal opinion: if you still building for the web using the traditional post-back model (yes, looking at you ASP.NET) you’re building a website, not an app).Let’s ignore for the moment the distinction between mobile, web or any other qualifier about the type of an application or the target platform and instead, let’s focus on what an application is. According to Wikipedia an Application is software that causes a computer to perform tasks for a user. This is a pretty wide definition and essentially encompasses most software, whether it be a command line application, browser or window based application. However, if you were to ask most people what they thought an “App” was today, they’d probably give an answer that relates to installing an application from the Apple, Google or Windows Store – it seems like the notion of an App is in somehow attached to the distribution model.If we look further into this, there are a variety of distribution models:- An application that you simply download from the Internet and just run (it might download as a Zip file but the important distinction here is that there’s no installation process and no Store managing the application). This is by far the simplest distribution model. However, these days few applications are distributed this way as most operating systems distrust downloaded files from the Internet and will refuse to run them without them being “unblocked” first.- An application you download from the Internet and then install. For Windows and MacOS historically this was the most common way for applications to be distributed. The operating system didn’t have a built in distribution mechanism, such as a Store, but they did support a model for applications to be installed and uninstalled. The danger of this model, is that, similar to just downloading and running an application, an application that is installed could have wide-reaching access to the host operating system. Over time this model has be adapted and additional security (for example User Account Control on Windows) limited what an installed application could do- An application you install from a Store. Whilst this model did exist prior to the iPhone, it wasn’t really until the App Store launched that the notion of a single curated Store became mainstream. Now, most platforms have a Store where you can browse, search and install apps to suit your every need. Depending on the platform, the process for submitting, certifying and publishing applications varies[...]

Cross-platform applications – PhoneGap/Cordova, Xamarin, PWAs and now Flutter

Mon, 19 Feb 2018 11:32:16 +0600

At Built to Roam we build applications that target a wide array of different platforms, using a wide variety of technologies depending on the project requirements. One of the most challenging things faced by organisation looking to build any form of software is often not what should I build, it’s often what technology should I use to build it. Unfortunately this is also where the most cycles are wasted and the poorest decisions are made. Nirvana would be building the software once, and for it to be available on every platform and device type, able to be instantly updatable and have a rich and engaging user interface (and I’m sure there’s more things that needed to be bolted onto this list of “ideals”). However, the reality is that there are different device types and sizes; there are different technologies with differing capabilities; and different developer and deployment workflows. Rather than being able to make an absolute decision on the best strategy, companies are limited by their own field of influence. Too often this includes Gartner reports, media hype and both internal and contractors with whom the decision makers have a relationship with.In addition to the number of options that are available, the optimum strategy also evolves over time. For example, five years ago in Australia it made sense for organisations to start their investment in mobile apps with a fairly basic iPhone application. Today the market expectation is that a mobile strategy encompasses at least Android and iOS, phone and tablet, and with a comprehensive set of features. In fact some applications, don’t even have a web presence, finding that their mobile apps were sufficient for their business model.So the question is really whether it is possible to define the optimum strategy for a business and is it possible to future proof it? To investigate this a bit further, let’s take a look at the progression of native application development. What’s quite interesting is that businesses have woken up to the fact that maintaining multiple applications written in the preferred technology for each platform is not sustainable. This has led to the emergency of a host of cross platform tools that generate native applications. There are tools such as Xamarin/Xamarin Forms which compile C# so that it can be run on the target platform; There has also been an explosion in Javascript based solutions, such as React Native where it generates the native components for each platform based on HTML mark-up (+CSS, JavaScript etc); More recently again there is Flutter, which aims to provide a user experience that has been drawn from the ground up to be platform agnostic. How do you make a decision between these technologies?More importantly is – are you making the decision about the right thing? It would seem that making a decision about which native application toolset to use would be right but actually the web and some of the hybrid solutions solve so many challenges that native application developers face, it would be foolish to ignore them. Take for example the recent hype around Progressive Web Applications. There are some who believe this is just another round of hype about the newest buzzword to arrive on the scene but in actual fact whilst the name is new, the concept is not. Back even in the days of Windows Vista, there were desktop gadgets that essentially allowed parts of the web to run in a container in an offline capacity. PWAs are just the latest name to be given to this concept.Where PWAs are set to make a difference is that they are being widely backed (eg Google: and Microsoft: and they also arrive at a point in time where devices have browsers and rendering engines that are capable of delivering a high-performance web experience whether in-browser, or in a hosted web application.Do you think the market is ready for PWAs? or are native applications going to rule for the fores[...]

New BuildIt Release for NetStandard 2.0 (General, States and Forms)

Sun, 11 Feb 2018 08:56:44 +0600

A new release of the following libraries is available via NuGet (v1.1.0.134):

- BuildIt.General

- BuildIt.States

- BuildIt.Forms

Whilst not much has changed in terms of features, behind the scenes there was quite a significant change as we adjusted the solution/project structure, and thus the nuget package structure. We took advantage of the ability to multi-target which meant we no longer have to have separate projects/libraries in order to support platform specific features. BuildIt.General, which used to have a UWP specific library, is now a single libary. Same goes for BuildIt.States. BuildIt.Forms has two libraries, down from the 5 that it used to have.

Additionally we also added direct support for netstandard 2.0. As part of the build process, each library is compiled for netstandard 1.0, netstandard 2.0 and then any platforms that have additional features.

In this release we’ve released multiple packages with the same version number, even though there is an interdependency between them (Forms –> States –> General).

Please reach out and let me know if you see any issues in this release with any of these libraries. We’ll be working to release updates to the other BuildIt libraries over the coming weeks.


Building Applications for Platform X

Mon, 01 Jan 2018 18:48:01 +0600

As we get started with a new year it’s time to pause and think about how the app development ecosystem has evolved, what technologies continue or are emerging, and look at the decision matrix that will define what technology your next application is developed in. I’m going to treat this post as a bit of an intro to some of the technologies that I think are worth further investigation.I think the easiest way to do this is to walk the spectrum from web apps through to native platform apps:Web AppsWhen we talk about web apps, there is a natural assumption that these will be responsive web sites that will work across a wide range of devices and browsers. However, they can be divided further into what I would consider traditional web sites and single page applications. Whilst this division can be blurred, for example when you host an Angular application within a .NET core application, the point is that there is a difference in the mindset of the developers building the web app.Of course, this section includes the obvious ASP.NET Core, React and Angular. Whilst ASP.NET is still a valid choice, I specifically left it out of the list as I think most new projects will favour ASP.NET Core unless there is an impediment that requires full ASP.NET.Progressive Web Applications allow web developers to extend their applications to leverage more device capabilities. This is a particularly hot area of development for most platforms as this is seen as one of the best long term solution for minimising mobile development fatigue.HybridNext in the progression are hybrid applications which combine web technologies with a platform specific deployment package – this sounds a bit cryptic but that’s because there are a couple of different models for this.Firstly there’s the Cordova/PhoneGap model where the application is defined using html, css, javascript, and wrapped in a native platform deployment package. The deployment step is required in order for most stores to accept applications. The important thing here is that the layout and logic for the application is packaged with the application and that the platform web rendering engine is used to display the application.The second model is much more interesting and is one that’s being used by React Native and Native Script where the logic and layout is defined in javascript, css and a form of HTML. The HTML actually defines native elements that will be rendered in the correct location.Cross PlatformBefore we get to native platform tools and technologies, we’ll stop in on a long time friend, Xamarin. As with the previous sections there are again two options with Xamarin: traditional Xamarin, and Xamarin Forms. With the traditional Xamarin approach the developer is much closer to the metal and has a higher degree of control. However, the Xamarin Forms option allows for user interfaces to be rapidly developed once, and then feedback/issues are resolved on a platform by platform basis.Native PlatformLastly, we have the Native platform options for developers:AndroidJava, C++ with Eclipse, Android StudioiOSObjective C, Switft, Interface Builder (now part of XCode)UWPC#, XAML, Visual Studio (or Visual Studio for Mac)As this is hopefully one in a sequence of posts on the topic of framework selection, I’d love some feedback on what technology you think will be important to you and those you work with – comments are off but hit me up on twitter @thenickrandolph if you have thoughts on this. [...]

Making MvvmCross with Xamarin Forms Friction Free

Thu, 28 Dec 2017 13:50:01 +0600

My last two posts (part 1 and part 2) outlined all the steps necessary to get a new Xamarin Forms with MvvmCross project setup. What I thought was going to be a simple post ended up being much longer due to all the unnecessary steps to setup both Xamarin Forms and MvvmCross. I’ve recently been contributing a little to MvvmCross and one of my concerns with it is that there are just way to many things that you need to get right in order to get it to work nicely with Xamarin Forms. If you don’t follow one of the introductory posts, such as the one provided by Martjin van Dijk, you’ll probably start hacking around with the numerous extension points in order to get it to work. I spent time over the last day seeing if I could reduce this initial friction to getting started.When you adopt a framework, or any library for that matter, you do so to reduce the need to reinvent the wheel – there’s no point in recreating, or creating something new, if there are existing solutions available. However, I’m of the opinion that you should be able to determine how much the framework influences the way that your code is structured. You should only have to modify your code if the framework offers a clear advantage. If we do a quick review of some of the changes required to take advantage of MvvmCross in our Xamarin Forms project you’ll see that quite a few of these are artificial requirements, mandated by the current MvvmCross implementation, rather than for any specific need. Here are just a couple:App needs to inherit from MvxFormsApplication – this doesn’t add anything other than a couple of events, so unless you want to use those events, this is unnecessaryAll pages need to inherit from the Mvx equivalent (eg MvxContentPage instead of ContentPage) – the Mvx equivalent expose a ViewModel property which can be useful but is not required in order to take advantages of data binding to the corresponding ViewModel since all Forms elements have a BindingContext that’s used for this purpose. The actual requirement here is for views/pages to implement IMvxView but unless you need the ViewModel property this shouldn’t be a requirement.You need to create a class that inherits from MvxApplication which can do things like register services but most importantly defines what the starting ViewModel is going to be. This is kind of unnecessary if the only thing that it’s doing is defining the starting ViewModel, although I do understand the desire to have the starting ViewModel defined somewhere that is independent of the head projects.All ViewModels need to inherit from MvxViewModel or implement IMvxViewModel – again this is somewhat unnecessary since ViewModels should just be a regular class. Now I do agree that in most cases your ViewModel is likely to implement INotifyPropertyChanged, so this additional requirements isn’t a massive addition but needless to say it shouldn’t be a requirement.Ok, so after a bit of experimenting without modifying MvvmCross or MvvmCross.Forms (ie I’m just using the NuGet packages) what I came up with is BuildIt.MvvmCross.Forms (currently in prerelease!) which is a NuGet package which adds a couple of helper classes to get you going just that bit quicker. Here are the steps to get started using BuildIt.MvvmCross.Forms:Start by following the steps outlined in part 1 – this will give you a Xamarin Forms project that’s completely up to date. I’ll call this project LowFrictionNext, follow the early steps in part 2 to add an additional project for your ViewModels, LowFriction.Core, and subsequently add references to MvvmCross (to all projects) and MvvmCross.Forms (to all projects except the Core project).Add a reference to the BuildIt.MvvmCross.Forms NuGet package to all projects except the Core project. A primary requirement here is that the Core project should not have a reference to the view technology, which in this case is [...]

Getting Started: MvvmCross with Xamarin Forms (Part 2)

Wed, 27 Dec 2017 04:28:39 +0600

In my previous post I covered the first part of this post on Getting Started with MvvmCross and Xamarin Forms where I covered the initial steps in getting a new Xamarin Forms project started. In this post I’m going to continue on and show how you can configure a Xamarin Forms solution to make use of MvvmCross.Before I get started with MvvmCross I’m going to add a new project which will contain all my ViewModels. Whilst not entirely necessary, particularly with Xamarin Forms where the views/pages are in a .NET Standard library, it’s good practice to completely separate your ViewModels away from the views/pages to avoid any accidental interdependencies forming. I’ll add a new project based on the .NET Standard class library template.For this library I’m going to adjust the .NET Standard version back to 1.0 – I prefer to start with a low .NET Standard version and increase it only when I need to take advantage of features in the higher versions. This ensures that the library can be referenced by the widest set of targets platforms.I’ll add a reference to the new project to each of the other projects in the solution. The next step is to add a reference to the MvvmCross NuGet package. Currently MvvmCross is still distributed as a set of Portable Class Libraries and if we attempt to add the NuGet package to either our MvvmcrossGettingStarted or MvvmcrossGettingStarted.Core projects, we’ll get an error as they’re both .NET Standard library. What’s annoying about this is that the MvvmCross PCLs are fully compatible with .NET Standard, meaning that it should be possible to add a reference to them. Unfortunately Visual Studio isn’t clever enough to be able to resolve this, and as such we need to adjust the csproj files for both projects before attempting to add a reference to MvvmCross.Add the following line into the first PropertyGroup of the csproj files for both MvvmcrossGettingStarted or MvvmcrossGettingStarted.Core projects. One saving grace is that it’s now easy in Visual Studio to edit a csproj by right-clicking on the project and selecting “Edit .csproj”.$(PackageTargetFallback);portable-net45+win8+wpa81Eg.Next we can go ahead and add a reference to MvvmCross to all our projects. Right-click on the solution node in Solution Explorer and select Manage NuGet Packages for Solution, and then search for mvvmcross. Select the most recent stable version of MvvmCross (this image is a little old as the version is at 5.6.3 at time of writing this)In addition to the main MvvmCross package, we also want to add in the Xamarin Forms support library, MvvmCross.Forms. Note that we do not add this to the MvvmcrossGettingStarted.Core project – this is the separation of concerns we setup at the beginning of this post to ensure there is no dependencies on the viewing technology within our ViewModels.Now that we have added the references to MvvmCross there are a bunch of small changes we need to apply to our application in order to get it all up and running. We’ll start in the MvvmcrossGettingStarted.Core project where we need to create two classes.The first class we’ll create inherits from MvxApplication and is used to setup the application within the ViewModel world. MvvmCross has an opinionated navigation model whereby navigation is defined at a ViewModel level, and simply implemented at a View level. As such the MvxApplication class, in this case GettingStartedApplication, defines the first ViewModel for the application.public class GettingStartedApplication : MvxApplication {     public override void Initialize()     {         RegisterNavigationServiceAppStart();     } }The second class is the ViewModel that matches the f[...]

Getting Started: MvvmCross with Xamarin Forms

Tue, 26 Dec 2017 13:59:58 +0600

Over the past 6-12 months we’ve seen dramatic changes in Xamarin Forms and the support within Visual Studio. The most recent update, which I covered in my previous post, included a number of new features for cross platform developers. However, despite these updates, getting started with cross platform development is still quite complex. In this post I wanted to take the opportunity to reiterate how to start a new Xamarin Forms project. From there I’ll cover adding in MvvmCross and discuss the importance of having a framework that will make development that much easier (for the record MvvmCross isn’t the only option, there are plenty of great alternatives such as Prism and FreshMvvm). Part 1: Getting Started with Xamarin FormsBefore getting started, make sure you’ve run the Visual Studio Installer and have upgraded to the latest stable release of Visual Studio. The team at Microsoft have been putting a lot of focus on stability and performance, so upgrading to the latest version does help (still not perfect but a marked improvement over this time last year!). Upgrading Visual Studio continually can be a bit of a pain, especially since Microsoft haven’t quite worked out how to automatically download updates in the background for VS – meaning that you have to stop whatever you’re doing whilst the updates download and then install. Recommendation is to run the installer periodically at the end of your day, or when you’re heading to a long meeting; hopefully the installation is complete by the time you return.Now that you’re all up to date, let’s create a new solution by selecting the Cross-Platform App (Xamarin Forms) template from the New Project dialog. Note that if you don’t see this template, you may have to adjust the workloads you selected in the VS Installer so that you have all the cross-platform development components selected.After clicking OK you should be presented with a second dialog that allows you to specify parameters for how your cross platform project should be setup. As you can see from the image, I recommend always selecting all three platforms (even if you’re only planning on targeting one or two of them initially); In this case we’re going with Xamarin.Forms with a simple Blank App; The last option I’m particularly passionate about – do NOT select Shared Project – for the good of your project, the team and general good programming practice, please select the .NET Standard option for Code Sharing Strategy. At time of writing the .NET Standard option is only available in the preview build of Visual Studio; the stable build uses a Portable Class Library, which is still preferable over using a Shared Project.This time clicking OK will create a new solution. Unexpected Error when Creating SolutionUnfortunately, at time of writing this post there is also a bug in the current cross platform template that results in the following error:If you see this error, a quick Google will yield the following bugzilla issue ( which describes the issue, along with how to fix it yourself – you just need to edit the Android csproj file and remove the " from around the TargetFrameworkVersion ie:replace:"v8.0"with v8.0 After fixing up the csproj file you’ll need to add the existing projects into the solution file.Assuming you didn’t run into any issues creating the solution, or you were able to fix up the Android csproj file, you should be able to build and run each of the head projects:UWPNote: When building the UWP project I was seeing a build warning stating “warning APPX0108: The certificate specified has expired.” which I thought was a bit odd since I had just created the project and normally the[...]

Xamarin Development with Visual Studio 2017 Version 15.5

Tue, 05 Dec 2017 02:46:32 +0600

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 - 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 (…-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 ). 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 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! [...]

Authentication Redirection Loop with Angular Application and Azure Active Directory

Sun, 19 Nov 2017 18:23:24 +0600

Recently we ran in to some difficulty with an Angular application that was being retrofitted into a different environment. During the initial development the Angular application had been pushed to Azure for testing. However, the final resting place for the application was on a on-premises sever. Whilst the switch was relatively painless, with the only major change being to a persistent file storage instead of blob storage, we also had to shift from our development Azure AD tenant (the Angular application, and the associated services, uses Azure AD to authenticate and authorize users), to the client’s Azure AD tenant. This shift required creating two new application registrations within the client’s Azure AD tenant.Unfortunately after creating the new registrations, and updating the Angular application (and the corresponding services), any attempt to log in with valid credentials resulted in a continual loop between the Angular application and the Azure AD login prompt. In this case we were only using Azure AD to authenticate users and other than controlling access to the application services there weren’t any other permissions that users would have to agree to. In the past I’ve posted about how administrators have to grant permission to users within their tenant to access an application (see Usually there is an Azure AD login error when users attempt to sign in. In this case, for some reason we either missed the error message or it was being obscured by the automatic redirection between the Angular application and the Azure AD login prompt. We did end up finding the solution, thanks to the Azure AD team at Microsoft, who quickly identified the error in our Fiddler trace. The critical request/response was:RequestGET ResponseHTTP/1.1 302 Found Location: Object moved

Object moved to Styling the MediaPlayerElement and MediaTransportControls in a Universal Windows Platform (UWP) Application

Sun, 05 Nov 2017 04:50:45 +0600

In my previous post, Building Media Applications for the Universal Windows Platform (UWP) using the MediaPlayerElement, I covered the basics of building a UWP media application using the MediaPlayerElement. Towards the end of the post I showed how you can override some of the built in behaviour but I was yet to show you how you can adjust the visual style of the player or the controls. In this post I’ll do just that, I’ll show you where to find the built in styles and how to start customizing them, including some gotchas that you should be aware of.Ok, let’s get started by looking for the built in styles. Whilst Microsoft now do a good job of documenting the built in styles online (for example the styles and templates for the MediaTransportControls element is defined at, there is nothing like looking at what ships in the platform. For this we go to generic.xaml, typically located at C:\Program Files (x86)\Windows Kits\10\DesignTime\CommonConfiguration\Neutral\UAP\10.0.16299.0\Generic – Note that this may vary based on which platform SDK you have installed. Inside generic.xaml I’m going to locate the Style for the MediaPlayerElement: