Converting an existing Windows Store app to using the Prism Framework

I began converting an existing Windows Store App to using the Prism Framework provided by Microsoft. However, I'm running into the following error:

The primary reference "Microsoft.Practices.Prism.StoreApps" could not be resolved because it was built against the ".NETCore,Version=v4.5.1" framework. This is a higher version than the currently targeted framework ".NETCore,Version=v4.5".

This post on stackoverflow.com recommends installing the Microsoft Build Tools 2013 package, which is available here:
http://www.microsoft.com/en-ca/download/details.aspx?id=40760

That didn't work.

I later realized that I had installed Prism with NuGet, so I went and checked the publishing dates on the versions. The latest (and default, which I had installed) was 1.1.0. The date on 1.0.1 was much older, and after reverting to that version, I was able to get my program to compile and run with a few modifications to the steps in this tutorial. The modifications are as follows:

• Change the return type of the App.OnLaunchApplication method to 'void' to match the 1.0.1 version of the Prism.StoreApps library.
• In the App.OnLaunchApplication method, ensure that there's a call to :
• NavigationService.Navigate("Main", null); where "Main" is the initial page name, and there's a MainPage class in your Views folder.
• Move the existing MainPage class into the Views folder in the root of the project.

Creating my first Windows 8 store app

As you may or may not be aware, there are multiple types of applications that can be created for Windows 8:

• Windows store apps, which use the new Metro interface
• Desktop-based apps which are like those created for previous versions of Windows that can still run in the Desktop app.

I'm quite familiar with creating WPF apps for Windows, but Metro apps are new, and those are what I'll be working on. With that in mind, Microsoft provides the Prism framework which helps provide additional classes, interfaces, events etc to help people develop Windows Store apps that keep consistent with Windows 8 design principles and help the apps perform properly. I'll be starting with the MSDN link here.

Beginning to work with Windows Store apps

I really hate Windows 8. I think the majority of the applications that have been written for it are complete pieces of shit, for the following reasons:

• The developers who wrote them didn't pay any attention to Microsoft's best practices and they :
• perform poorly
• don't follow UI conventions and are hard to understand as a result
• crash 
• don't always save data properly
• Many are piss-poorly written and adapted by third party developers for first-party systems because those first-parties don't want to write software in a competing ecosystem, and instead want to force users to use their ecosystem, which has their own set of flaws and deficiencies. Case in point: Google. At the time of this writing, there are no native Windows 8 applications put out by Google. There's no native YouTube app for Windows 8 (which there damn well should be), presumably because those fuckers couldn't find a good way to generate advertising revenue in a Windows 8 app. (can't really blame them for that because if I see ads in an app, I immediately delete it from my device without hesitation. I can't stand that shit.)
• Windows 8 is a shit operating system. It was built on the new Modern interface (aka Metro), and initially had piss-poor integration with the desktop paradigm on which all previous incarnations of Windows were based. Add to this the fact that Microsoft didn't give people an easy choice of which paradigm they wanted to use right off the bat, and the fact that in successive iterations like Windows 8.1 they've tacked on hacky additions to make the Metro interface more like the previous desktop interface, you end up with a shitty operating system that's a pain to use; this pain stems from the fact that it's a horrible amalgamation of multiple user interface paradigms. 

As long as Microsoft continues to force their shitty iterations of Windows on the world, I, as a software developer, will be forced to deal with it because of the immense investment most employers have in Microsoft technology. With that in mind, I'm going to start learning Windows 8 applications so that I can make myself more marketable to employers everywhere. I'm going to document my learning here for my usual reasons:

1. So that I have a reference for myself for the future
2. So that others may learn more easily what I have learned.

Journey to robust web services: my clients are unable to connect!

I've been testing out some web services I've been working on extensively on my own machine, but the time has finally come where I want to start making clients that aren't running on the same machine. In one case, I have a WCF service running on Windows 7, but the client I want to connect to that service is running on Windows 8 on a separate machine. When I tried to connect, I would get a variety of errors, the most common of which being that the socket on the server was forcibly closed. I Googled around a bit, and the most common cause of this problem that I found was that the server's quota's were being reached and therefore the client was being rejected, however this shouldn't have been the case for me since there was no way my quota's could have been reached. After further research, I found that since I don't want security (yet), I had to apply some settings in order for clients that weren't on my localhost to connect. In order to allow external clients to connect, I had to change the following :

1. In my , I had to change my base address to use the network name of my computer (rather than localhost) in the base address URL.
2. In the net.tcp and ws2007HttpBindings for my services, I had to go to the the child element of the elements, and explicitly set mode="None" on those elements, otherwise they may assume some form of security by default depending on the type of the binding.

Now, I did mention above that I don't want to add security (*YET*) being the important qualifier of that statement. Security is of course always paramount, and should always be baked into a product as early as possible. As soon as I get to it, I'll add a post about all the steps required to add security to your WCF clients and services, along with links to the relevant MSDN articles (and any other useful ones that I may find.