Web API Tutorials Part 5 : Azure Deployment from Visual Studio

Microsoft have made it extremely easy, almost trivial to deploy your web applications to the Azure cloud from Visual Studio.  Cloud capability is incredibly powerful for scalability, particularly in enterprise level applications and affords Developers with the option to make their infrastructure as Agile as their Software.

Outcome

By the end of this tutorial, we’ll have deployed our Web Application directly into a Web Site in Azure using their Platform as a Service offering (PaaS), meaning we don’t need to worry about a Virtual Machine, updates, and a myriad of other concerns. Continue reading “Web API Tutorials Part 5 : Azure Deployment from Visual Studio”

Morse Coder Part 8 : Windows 10 Migration

I’m sure you’re probably all aware that Windows 10 is out, (if not in the news then the nagging to upgrade), I recently took the plunge and upgraded my PC and tablet and have to say I’m rather impressed.  Along with the Operating System I also upgraded my development environment to Visual Studio 2015 Community to start taking a look at Windows 10 Apps, (and maybe start dabbling in Xamarin now that it’s so accessible).  In light of this, now seems as good a time as any to start looking at implementing our Morse Coder App as a Windows 10 Universal App.

Outcome

Windows 10 Universal Apps differ from Windows 8.1 and Windows Phone 8.1 apps in that they require only a single Project for the UI, where the 8.1 apps would have had Windows, Windows Phone, and a Shared Project; Windows 10 requires only a single project.  By the end of this post we should have a functioning Windows 10 app, with all the current functionality from the existing Desktop Version, running on both the Phone Emulator and the Desktop (and everything in between).

Continue reading “Morse Coder Part 8 : Windows 10 Migration”

Universal App Gotchas : Namespaces must exist in all Platform Projects

In certain circumstances Visual Studio will quite happily suggest to add namespaces into Shared Projects that will then fail to compile.  It’s an obvious issue to resolve, with the bottom line being that the Namespaces must exist in all Platform Projects in order for it to be referenced by the Shared Project.
Continue reading “Universal App Gotchas : Namespaces must exist in all Platform Projects”

Universal App Gotchas : NullReferenceException in Blend Opening Views from Visual Studio with MVVM Light

TL;DR: open the whole solution in blend*.

*for my scenario.

On using the Open In Blend menu option from right clicking a view in Visual Studio…

OpenInBlend
Open In BlendBlendNullReferenceException.png

…I was experiencing the following System.NullReferenceException when opening the view in the Designer…

BlendNullReferenceException.png
System.NullReferenceException

…on further investigation “The Resource “Locator” Could not be resolved.”

Explanation

When you right click Open in Blend, it will open the project that your view resides in, along with the View itself in the design window. What it won’t do however, is bring with it any resources it requires from other projects at design time. In this case, my App.xaml file located within the .Shared project, and NOT the platform specific project being loaded was defining my static resources and as such it could not be resolved due to not currently being loaded in Expression Blend. As mentioned in a previous post, the shared folder for all intents and purposes is part of the platform specific projects at compile time.

 Resolution

My resolution was simple, open the entire Solution in Blend allowing it to be resolved!

Seems obvious now but I was stumped for a little while there! Hopefully this will come in handy to someone.