Joseph Michael Pesch
VP Programming

Piranha CMS for MVC Installation

by 22. February 2015 05:44

When I first installed Prianha CMS for MVC I was having issues running it.  I started over and installed via NuGet package manager console in the following order:

PM > Install-Package PiranhaCMS.Core

PM > Install-Package PiranhaCMS.WebPages

PM > Install-Package PiranhaCMS.MVC

PM > Install-Package PiranhaCMSMVC



C# | MVC

Convert Standard MVC Website to SPA (Single Page Application) Using Sammy.js

by 19. February 2015 07:17

Step One: The Layout Page

For MVC the layout page is a template that ASP.NET uses to render a single HTML document by merging it with the markup in a view page.  In a SPA, the Layout becomes a shell page into which the view's markup is loaded via AJAX calls. The Layout page's lifespan is now the user's session, rather than just the lifespan of the page, so be careful what you scope at this level; the safety net of a page refresh that cleans up after us is gone, and browser memory leaks are distinctly counter-excellent in nature.

To convert a standard MVC website to SPA we'll use NuGet to add Sammy.js to our project. Sammy (among other things) is a jQuery-dependent JavaScript framework which lets us add URL routing to the client side of our app.

Once we've brought in Sammy, we'll add it to a bundle (along with jQuery) in BundleConfig.RegisterBundles:

bundles.Add(new ScriptBundle("~/js/mvc-spa").Include(

Then we'll render the bundle at the bottom of our Layout page:


We'll also need to designate the area of the Layout where the view content will be loaded by finding the element we are currently calling RenderBody and giving it a unique id. For this example, let's go with "page".

<!-- ... -->
<section id="page">
<!-- ... -->    

Step Two: Go Partial

Next, we need to go through our views, and, with the exception of the Home/Index view, convert each to a Partial View.

Unlike vanilla MVC Views, Partial Views are not merged with the Layout page to render as complete HTML documents. When you make a controller request that returns a Partial View, the response is merely an HTML fragment–precisely what we're looking for in a SPA page.

To convert a View to a Partial, simply change the View call to a call to PartialView in its corresponding Controller Action:

public class SpaFtwController : Controller {
    public ActionResult Index() {
        return PartialView();

As I may have mentioned above, do not convert your default view to a partial. This view is the "single page" in "single-page application", and it still needs to render as a complete HTML document, just the once. However, we should move this Index view's content into a separate Partial View, and replace it with some sort of splash content that will only display while our app is still loading. More on that in the next step.

Step Three: One Route to rule them all

The typical usage of Sammy is to describe multiple hash-based routes, along with the js to be executed when the user navigates to them. What we're going to do in this case, though, is create a solitary Sammy route that acts as a pass-through to the existing MVC routing already in place on the server-side.

For example, a request to /#/spaftw would load the content from /SpaFTW into our app. Using fragment identifiers for routing is a classic SPA technique; it changes the browser's URL without causing a whole page request, while also allowing the back button to still work as expected, and enables deep-linking into the app.

Here is a module that contains the code to do just this. We'll add it to our project in a file named Routing.js.

var Routing = function (appRoot, contentSelector, defaultRoute) {
function getUrlFromHash(hash) { var url = hash.replace('#/', ''); if (url === appRoot) url = defaultRoute; return url; }
return { init: function () { Sammy(contentSelector, function () { this.get(/\#\/(.*)/, function (context) { var url = getUrlFromHash(context.path); context.load(url).swap(); }); }).run('#/'); } }; }

Let's unpack that. See the this.get call about two-thirds of the way down? That's Sammy's bread and butter. We're using a regular expression to describe a route URL that captures any href beginning with '/#'. When a request is made for a URL matching this expression, Sammy intercepts it and runs the function that we've passed as get's second parameter. This function grabs this path, strips out the hash, makes an AJAX request for the Partial View for that URL, and swaps it into the element designated by contentSelector. Which, of course, will be our content area in the Layout page.

Finally, we need to wire this into our Layout page. Add Routing.js to our bundle, after Sammy.js:

bundles.Add(new ScriptBundle("~/js/mvc-spa").Include(

Then, add the following script block to the Layout page, after rendering the bundle:

$(function () {
    var routing = new Routing('@Url.Content("~/")', '#page', 'welcome');

This instantiates a Routing instance with the root URL for the application (this becomes important if our app is deployed anywhere other than '/'), the selector of our content area ('#page'), and the route to default to when the user navigates to the root of the app. This should be the Partial View that inherited the original content from our Home/Index view, in step two.

Original version of this modified post published here:



C# | MVC

Restore NUGET Packages in Visual Studio Online TFS Continuous Integration Builds

by 16. February 2015 13:25

  • Step 1 - Enable NuGet Package Restore


        Projects that use MSBuild-Integrated package restore typically contain a .nuget folder with three files:

    • NuGet.Config
    • NuGet.exe
    • NuGet.targets

Since the presence of a NuGet.targets file determines whether NuGet will continue to use the MSBuild-Integrated approach, this file must be removed. Also, as the .nuget\NuGet.exe file is not used by Automatic Package Restore, it likewise can be removed. By default, the NuGet.Config file instructs NuGet to bypass adding package binaries to source control. Automatic Package Restore will honour this as long as you leave this file in place. Note that NuGet.Config only has an effect when using Visual Studio to integrate with Team Foundation Server (TFS). In addition to these files, NuGet modifies the project files in the solution to reference the NuGet.targets file so it can participate in the build process. When migrating to Automatic Package Restore, these references must also be removed.

       Remove the NuGet.exe and NuGet.targets files from the solution's .nuget folder. Make sure the files themselves are also removed from the solution workspace.
       Retain the NuGet.Config file to continue to bypass adding packages to source control.

  • Step 2 – Close Down Visual Studio

        Each project in your solution that has picked up any of the below listed tags in the project properties will need to be removed. Open the project in Notepad and look for the below tags, remove these tags…

1. ------------------- 

2. -------------------
<Import Project="$(SolutionDir)\.nuget\nuget.targets" />  

3. --------------------
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">  
        <ErrorText>This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them.  For more information, 
see The missing file is {0}.</ErrorText>
    <Error Condition="!Exists('$(SolutionDir)\.nuget\NuGet.targets')" Text="$([System.String]::Format('$(ErrorText)', '$(SolutionDir)\.nuget\NuGet.targets'))" />
  • Step 3 – Open the solution and check in the changes

        Once you have made the above listed changes, you are good to check in the changes.

Trigger the  build now, the build server should now be able to successfully resolve the package references…

More details here…


ASP.Net | TFS | Visual Studio