Conflicts with Umbraco 7 install and ReSharper.

Im currently working on a project that abstracts Umbraco away from the customer facing UI AKA front end. We are effectively utilising Umbraco as a service rather than as a platform. Because as a CMS, its incredibly powerful and functional but these benefits come at a cost for the customers interacting with the front end. Typically its performance but there are a whole heap of issues that effect large sites that im not going to go into on this particular blog.

This post is about Umbraco 7 installation. Its an obscure one so I thought I would mention it here to aid folk in the future.

Basically when you install Umbraco from NuGet and you come across the following error.

       
Install failed. Rolling back...
install-package : Expected "$(_PublishProfileSet)" to evaluate to a boolean instead of "", in condition "$(_PublishProfileSet) And '$(PublishProfileName)' 
=='' And '$(WebPublishProfileFile)'==''".  C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.targets
At line:1 char:1
+ install-package umbracocms
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Install-Package], InvalidProjectFileException
    + FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PowerShell.Commands.InstallPackageCommand
       
 

It's a known conflict error between Resharper and the install. Further details can be found here. But in brief. Disable Resharper and try again.

Worked for me. I believe the issue is resolved in v9 of ReSharper but further comments would be appreciated.

To disable/Suspend ReSharper

Navigate to:  Tools -> Options -> ReSharper -> Suspend Now

Suspend ReSharper

Intro into the OWIN specification and a Hello world example of Katana

Getting Started with OWIN and Katana

Firstly, lets start by trying to identify what the OWIN specification is. The following text is taken from owin.org.

OWIN defines a standard interface between .NET web servers and web applications. The goal of the OWIN interface is to decouple server and application, encourage the development of simple modules for .NET web development

Or in other words; Katana, the Microsoft implementation of OWIN, is basically an answer to node.js just like the ASP.NET MVC framework was the answer to Ruby on Rails.

This is evident when we compare the two hello world web server implementations;

1. Node Web server initiation

	var http = require('http');
	http.createServer(function (req, res) {
	res.writeHead(200, {'Content-Type': 'text/plain'});
	res.end('Hello World\n');
	}).listen(1337, '127.0.0.1');
	console.log('Server running at http://127.0.0.1:1337/');

view raw nodejs-hello-world hosted with ❤ by GitHub

2. Katana self hosting web server

	using (WebApp.Start<Startup>("http://localhost:1234"))
	{
	Console.WriteLine("Listening on port: 1234");
	Console.ReadLine();
	}

view raw katana-selfhost-helloworld hosted with ❤ by GitHub

Now this is evidently a high level comparison between the 2 but it suggests my point.

Katana, is a collection of projects for supporting and implementing the OWIN specification. The value here is that it creates an abstraction between the web server and application. Meaning it completely decouples server dependencies away from our application. This then introduces the concept of, use what we need and nothing more.

Significantly it includes OWIN support for System.Web and System.Net.HttpListener.

This is an obvious benefit when you review a typical .NET application and notice the dependent reference System.Web.dll; which is over 2.5MB and includes over 10 years of retrofitted development.

Where node uses Node Package Manager, Microsoft uses NuGet to manage these modules.

For this blog post, this is where the comparison stops between these two technologies. I dont want to dwel upon it, however for further readings checkout this performance comparison article; NB. At the time of this blog publication the article was over a year old so the result will no doubt vary.

MSFT's decision to open source their forthcoming ONE ASP.NET platform has meant the open source community has supported the Katana implementation well. Significant support that you can pull down today includes;

• Web API
• SignalR
• Nancy

I've used a couple of these projects on a basic hello world application. Its a self hosted project running from a console app. But a follow up post will include a Linux host. This is available on GitHub for downloading, forking, or contributing.

View on GitHub





Thanks for reading. As always I would really appreciate any comments.