Visual Studio

Add Git Ignore to existing Visual Studio Project

Last week I mentioned adding a .gitignore file to keep a configuration file from causing issues across machines. Visual Studio make it super easy to add, but the next time I made a change to the project the configuration file showed up in my changes again. Turns out that if Git is already tracking a file adding it to the ignore file will not do anything. I am going to walk through adding an ignore file and then cover the one of the processes that can be used to stop Git from tracking files that are in your ignore file.

Using Visual Studio to add a .gitignore file

Inside of Visual Studio open the Team Explorer window. If you don’t already have it open use the quick launch in the upper right hand side of the window to search for it. If it is not already on the Home page click the house icon in the top of the Team Explorer window.


Click the settings option.


Then click Repository Settings.


Now click the add link next to the Ignore File description. This will add the .gitignore file will all the defaults set for things that should be ignored. You could add the file manually, but then you would not get the nice set of default values. If you do decide to add the file manually this repo contains all the defaults that should be ignored for a project using .NET/Visual Studio.

Now that the file exists check it in.

Stop tracking files that should be ignored

To stop tracking the files in the ignore file open a command prompt and navigate to the directory that contains your solution file (.sln) and run the following commands.

git rm -r --cached . 
git add .
git commit -am "Remove ignored files"

That seemed to do the trick for me. The git commands I found here. If you click on that link you will see there are lots of options on which commands to use for this process. If the above doesn’t work for you one of the other answers should meet your needs.

In the future I will be making sure my ignore file exists first just to avoid any issues.

Unable to start process dotnet.exe

This morning I did a sync of a repo using of Visual Studio and then tried to run a web application I was going start working when I got this error:

Unable to start process C:\Program Files\dotnet\dotnet.exe. The web server request failed with status code 500, Internal Server Error. The full response has been written to C:\Users\ericl\AppData\Local\Temp\HttpFailure_11-01-57.html.

As directed by the error message I opened up the referenced html file. The file stated the requested page cannot be access because the related configuration data for the page is invalid. Along with the path to the configuration file. Here is a screen shot of the rendered file.


I checked the config file referenced in the error message and I saw nothing wrong. It is the default generated file with no changes.

Since this project ran fine on another computer the day before I thought I would search for my profile name on from the other computer on the one having issues. This led me to the .vs/config folder found at the solution level of my application which contained the applicationhost.config file.

The solution

applicationhost.config has a lot of information in it, but the section I needed to change was under the sites tag. The physical path was set to the directory where the project was located on my other computer. I changed the path to match the path on my current computer and all worked fine. Not sure why this path isn’t relative one it exists within the solution. This is the line that I needed to change.

<virtualDirectory path="/" physicalPath="C:\Users\ericl\Source\Repos\ASP.NET Core Contacts\Contacts\src\Contacts" />

As an alternative it also works to close Visual Studio delete the whole .vs folder and reopen the project in Visual Studio. This causes the config file to regenerated with the proper values.

Looks like the .vs folder is in the default .gitignore file, but my project was missing the ignore file.

Tool Spotlight – Add New File and Open Command Line Visual Studio Extentions

Tool Spotlight is a new type of post that I am trying out to bring attention to tools that I find useful and worth sharing. These entries will not be on any sort of schedule and will get posted anytime I come across a tool worth mentioning.

This post is going to cover two Visual Studio extensions that I find very helpful especially in the context of writing ASP.NET Core applications. Both of today’s extensions were written by Mads Kristensen.

 Add New File

The Add New File extension provides a simple way of adding new files without having to go through Visual Studio’s add new item dialog. Visual Studio’s dialog is great when I need it, but a lot of times I am adding a html or JavaScript file and just want a blank file and this extension provides a mechanism to do just that.

Lets look at the difference in the two dialogs. Here is Visual Studio’s dialog:


And here is what the add new file’s dialog looks like:


As you can see the extension’s dialog is much simpler. After the extension is install simply hit Shift+F2 to show the above dialog, enter a file name and click Add file to create a file in the current directory. Directories will also be crated as needed.

Open Command Line

The Open Command Line extension provides a way to open a console from within Visual Studio. The default console application is configurable with options from cmd and PowerShell to cmder and custom user defined applications. Opening the default console to the current directory of the selected item in Visual Studio’s solution explorer can be triggered using the Alt+Space shortcut. The extension also adds an Open Command Line option to the right click menu in solution explorer.


Thoughts and Suggestions

Leave any thoughts on if this sort of post is helpful, your favorite tools or suggestions for future topics in the comments.

Introduction to gulpjs

Working on a future blog post I hit some problems involving files that needed to be moved around as part of build process. This is one of the problems that gulp solves.

What is gulp?

Gulp is a task runner that utilizes node. The core idea behind task runners is automation. Have less that needs compiled into css, minified and output into the proper directory? That is a great use case for a task runner.

Gulp is not the only task runner out there. Grunt is another option and has actually been around longer. I am using gulp because it is the default in Visual Studio 2015. Google gulp vs grunt and decide which is right for you.


  1. Install node if needed from this site.
  2. From the console install gulp using npm install gulp -g

Project setup

Next add a gulpfile.js the root of the project where gulp is to be used. If using ASP.NET 5 this file will already exist and will include a few prebuilt tasks. If you are not using ASP.NET 5 the following is a mimimum gulpfile from the official getting started guide.

var gulp = require('gulp');

gulp.task('default', function() {
  // place code for your default task here

Also add gulp to the devDependencies section of the project’s package.json file. Since Visual Studio handles edits to package.json so nicely (intellisense and automatic package restore) I tend to edit the file manually instead of using npm.

 "devDependencies": {
    "gulp": "3.9.0"


The base gulp API only contains 4 functions (src, dest, task and watch) and doesn’t do a whole lot on its own. This is where plugins come in. Gulp has a ton of plugins that do all sorts of useful things. For example, the default gulpfile.js provided by Visual Studio has a min:js task that used gulp-concat and gulp-uglify to combine javascript files and then minify the result.

Example gulpfile for minification of javascript

The following is a full gulpfile based on the default file generated by Visual Studio stripped down to just the bits needed for the min:js task.

"use strict";

var gulp = require("gulp"),
    concat = require("gulp-concat"),
    uglify = require("gulp-uglify");

var paths = {
    webroot: "./wwwroot/"

paths.js = paths.webroot + "js/**/*.js";
paths.minJs = paths.webroot + "js/**/*.min.js";
paths.concatJsDest = paths.webroot + "js/site.min.js";

gulp.task("min:js", function () {
    return gulp.src([paths.js, "!" + paths.minJs], { base: "." })

The above will pull all the javascript files from wwwroot/js and its subfolders and combine them and output the results to site.min.js in the wwwroot/js folder.

Migration from ASP.NET 5 Beta 8 to RC1

ASP.NET 5 release candidate 1 was released on November 18th. Read the announcement here.  The announcement happened during Connect where Microsoft talk about a ton of cool stuff. Hanselman did a great summary here.

One of the big things (for some people) is that with RC1 ASP.NET 5 now has a go live license which means Microsoft will provide support. One thing to note about the go live license is if a RC2 is released the support will immediately drop for RC1 and any application will need to be upgraded to RC2 before getting support. Once the final release is out it will be supported for years it is only the go live license that ends support as soon as the next version with a go live license is released.

To get all the new bits installed, including tooling updates for Visual Studio, head over to This is one of my favorite parts of the RC. The site will show you the appropriate links for install for the OS you are running on. Just make sure you hit the ASP.NET 5 RC install and not ASP.NET 4.6. The install link will kick you over to the install page of the docs site which provides step by step instructions in addition to the download link for the update.

After completing the install open global.json and update the sdk version to rc1-final.

  "projects": [ "src", "test" ],
  "sdk": {
    "version": "1.0.0-rc1-final"

Next is project.json the dependencies section as usual. In addition to the change from beta8 to rc1-final a few packages have changed names.

  "dependencies": {
    "EntityFramework.Commands": "7.0.0-rc1-final",
    "EntityFramework.MicrosoftSqlServer": "7.0.0-rc1-final",
    "Microsoft.AspNet.Authentication.Cookies": "1.0.0-rc1-final",
    "Microsoft.AspNet.Authentication.Facebook": "1.0.0-rc1-final",
    "Microsoft.AspNet.Authentication.Google": "1.0.0-rc1-final",
    "Microsoft.AspNet.Authentication.MicrosoftAccount": "1.0.0-rc1-final",
    "Microsoft.AspNet.Authentication.Twitter": "1.0.0-rc1-final",
    "Microsoft.AspNet.Diagnostics": "1.0.0-rc1-final",
    "Microsoft.AspNet.Diagnostics.Entity": "7.0.0-rc1-final",
    "Microsoft.AspNet.Identity.EntityFramework": "3.0.0-rc1-final",
    "Microsoft.AspNet.IISPlatformHandler": "1.0.0-rc1-final",
    "Microsoft.AspNet.Mvc": "6.0.0-rc1-final",
    "Microsoft.AspNet.Mvc.TagHelpers": "6.0.0-rc1-final",
    "Microsoft.AspNet.Server.Kestrel": "1.0.0-rc1-final",
    "Microsoft.AspNet.StaticFiles": "1.0.0-rc1-final",
    "Microsoft.AspNet.Tooling.Razor": "1.0.0-rc1-final",
    "Microsoft.Extensions.CodeGenerators.Mvc": "1.0.0-rc1-final",
    "Microsoft.Extensions.Configuration.FileProviderExtensions": "1.0.0-rc1-final",
    "Microsoft.Extensions.Configuration.Json": "1.0.0-rc1-final",
    "Microsoft.Extensions.Configuration.UserSecrets": "1.0.0-rc1-final",
    "Microsoft.Extensions.Logging": "1.0.0-rc1-final",
    "Microsoft.Extensions.Logging.Console": "1.0.0-rc1-final",
    "Microsoft.Extensions.Logging.Debug": "1.0.0-rc1-final",
    "Microsoft.VisualStudio.Web.BrowserLink.Loader": "14.0.0-rc1-final"

EntityFramework.SqlServer is not EntityFramework.MicrosoftSqlServer. Configuration and Logging moved from Mircosoft.Framework to Microsoft.Extensions.

Startup.cs had another set of changes this round. First up some namespace changes which are mostly the move from Microsoft.Framework to Microsoft.Extenstions.

using Microsoft.Dnx.Runtime;
using Microsoft.Framework.Configuration;
using Microsoft.Framework.DependencyInjection;
using Microsoft.Framework.Logging;

using Microsoft.Extensions.PlatformAbstractions;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Logging;

In the Configure function I was able to enable browser link and it be useable and a slight change to the UseDatabaseErrorPage call.

if (env.IsDevelopment())

if (env.IsDevelopment())

Finally, a static void main was added for the entry point of the application. Pretty sure the app will still run without this change, but it is included when adding a new application with the updated templates.

// Entry point for the application.
public static void Main(string[] args) => WebApplication.Run<Startup>(args);

Entity framework 7 only had a couple of breaking issue which seem to be the team finishing up some API tweaks. Here are the renames I hit this version.

Migration related renames
Old New
Index HasIndex
ForeignKey HasForeignKey
Annotation HasAnnotation

Something else I hit was an unexpected port when I ran the application. There is a new launchSettings.json file in the Project folder which is where things like port can be changed. It also has settings for IIS and IIS Express.

Finally make sure and check out the release page and the breaking changes page for this release.

Migration from ASP.NET 5 Beta 7 to Beta 8

ASP.NET 5 beta 8 was released on October 15th. Read the main announcement here and the entity framework 7 specific announcement here.

The tooling update can be found here. The relevant files are either DotNetVersionManager-x64.msi or DotNetVersionManager-x86.msi depending on what your system supports and WebToolsExtensionsVS14.msi.

The above gets everything needed for use inside Visual Studio for more details on other options check out Microsoft’s documentation for getting started with Windows, Mac or Linux.

After completing the upgrade open global.json and update the sdk version to beta 8.

  "projects": [ "src", "test" ],
  "sdk": {
    "version": "1.0.0-beta8"

Next up is project.json which has more changes than other migrations due to the move from hosting in Helios to Kestrel. First update beta7 to beta8 in the dependencies section.

  "dependencies": {
    "EntityFramework.SqlServer": "7.0.0-beta8",
    "EntityFramework.Commands": "7.0.0-beta8",
    "Microsoft.AspNet.Mvc": "6.0.0-beta8",
    "Microsoft.AspNet.Mvc.TagHelpers": "6.0.0-beta8",
    "Microsoft.AspNet.Authentication.Cookies": "1.0.0-beta8",
    "Microsoft.AspNet.Authentication.Facebook": "1.0.0-beta8",
    "Microsoft.AspNet.Authentication.Google": "1.0.0-beta8",
    "Microsoft.AspNet.Authentication.MicrosoftAccount": "1.0.0-beta8",
    "Microsoft.AspNet.Authentication.Twitter": "1.0.0-beta8",
    "Microsoft.AspNet.Diagnostics": "1.0.0-beta8",
    "Microsoft.AspNet.Diagnostics.Entity": "7.0.0-beta8",
    "Microsoft.AspNet.Identity.EntityFramework": "3.0.0-beta8",
    "Microsoft.AspNet.IISPlatformHandler": "1.0.0-beta8",
    "Microsoft.AspNet.Server.Kestrel": "1.0.0-beta8",
    "Microsoft.AspNet.StaticFiles": "1.0.0-beta8",
    "Microsoft.AspNet.Tooling.Razor": "1.0.0-beta8",
    "Microsoft.Framework.Configuration.Abstractions": "1.0.0-beta8",
    "Microsoft.Framework.Configuration.Json": "1.0.0-beta8",
    "Microsoft.Framework.Configuration.UserSecrets": "1.0.0-beta8",
    "Microsoft.Framework.Logging": "1.0.0-beta8",
    "Microsoft.Framework.Logging.Console": "1.0.0-beta8",
    "Microsoft.Framework.Logging.Debug": "1.0.0-beta8",
    "Microsoft.VisualStudio.Web.BrowserLink.Loader": "14.0.0-beta8"

Note that Microsoft.AspNet.Server.IIS and Microsoft.AspNet.Server.WebListener have been removed. Microsoft.AspNet.IISPlatformHandler and Microsoft.AspNet.Server.Kestrel have been added.

In the commands section the web command has been updated to use Kestrel.

"web": "Microsoft.AspNet.Hosting --config hosting.ini"

"web": "Microsoft.AspNet.Server.Kestrel"

As a result of the move to Kestrel both hosting.ini and wwwroot\bin\AspNetLoader.dll can be deleted. In wwwroot the web.config file changed to the following.

<?xml version="1.0" encoding="utf-8"?>
      <add name="httpPlatformHandler" 
    <httpPlatform processPath="%DNX_PATH%" 

Startup.cs had a few changes. First in the constructor the application’s base path moved out of the constructor of ConfigurationBuilder to the SetBasePath function.

var builder = new ConfigurationBuilder(appEnv.ApplicationBasePath);

var builder = new ConfigurationBuilder()

In ConfigureServices the setup for third-party authentication has been removed. For example the following has been removed.

services.Configure<FacebookAuthenticationOptions>(options =>
    options.AppId = Configuration["Authentication:Facebook:AppId"];
    options.AppSecret = Configuration["Authentication:Facebook:AppSecret"];

Third party authentication options are now set in the Configure function. Here is an example with Facebook.

app.UseFacebookAuthentication(options =>
    options.AppId = Configuration["Authentication:Facebook:AppId"];
    options.AppSecret = Configuration["Authentication:Facebook:AppSecret"];

Also in the Configure function app.UseErrorPage is now app.UseDeveloperExceptionPage and app.UserErrorHandler is now app.UseExceptionHandler.



Add the platform handler to the request pipeline before app.UseStaticFiles.

// Add the platform handler to the request pipeline.

// Add static files to the request pipeline.

In AccountController.GetCurrentUserAsync and ManageController.GetCurrentUserAsync Context is now HttpContext.

return await _userManager.FindByIdAsync(Context.User.GetUserId());

return await _userManager.FindByIdAsync(HttpContext.User.GetUserId());

Next up are the changes related to entity framework 7. EF7 had a lot of API changes with this release. I am covering the ones related to the app I am working with and others can be found by looking at the commits related to this issue.

The designer.cs that goes with migrations drop the override of Id in favor of a migration attribute instead. The new attribute can be found in Microsoft.Data.Entity.Migrations.

partial class CreateIdentitySchema
Migration related renames
Old New
Key HasKey
Reference HasOne
InverseCollection WithMany
ConcurrencyToken IsConcurrencyToken
isNullable nullable

After all the above changes my project built, but would error because entity framework was trying to run migrations that had already been applied. After some digging I found that the table used to check if a migration has been applied or not had been renamed from MigrationHistory to EFMigrationsHistory. The following SQL will move the migrations that have been applied from the old table to the new one.

INSERT INTO dbo.__EFMigrationsHistory (MigrationId, ProductVersion) 
SELECT MigrationId, ProductVersion FROM dbo.__MigrationHistory

After fixing the migration issue the app ran with no problems. Make sure and check out the release page and the breaking changes page for this release.

Also note that the ASP.NET 5 project templates for Visual Studio have been open sourced and can be found here. The templates are a great resource which I used to work through a couple of issues when doing the migration to beta 8.

Migration from ASP.NET 5 Beta 6 to Beta 7

On September 2nd ASP.NET 5 beta 7 was released. As with beta 6 this release includes a tooling update for Visual Studio. Read the announcement here.

The tooling update can be found here. The relevant files are either DotNetVersionManager-x64.msi or DotNetVersionManager-x86.msi depending on what your system supports and WebToolsExtensionsVS14.msi.

After installing the tooling update change the sdk version in global.json to beta 7.

  "projects": [ "src", "test" ],
  "sdk": {
    "version": "1.0.0-beta7"

In the project.js file update beta6 to beta7 in the dependencies section.

  "dependencies": {
    "EntityFramework.SqlServer": "7.0.0-beta7",
    "EntityFramework.Commands": "7.0.0-beta7",
    "Microsoft.AspNet.Mvc": "6.0.0-beta7",
    "Microsoft.AspNet.Mvc.TagHelpers": "6.0.0-beta7",
    "Microsoft.AspNet.Authentication.Cookies": "1.0.0-beta7",
    "Microsoft.AspNet.Authentication.Facebook": "1.0.0-beta7",
    "Microsoft.AspNet.Authentication.Google": "1.0.0-beta7",
    "Microsoft.AspNet.Authentication.MicrosoftAccount": "1.0.0-beta7",
    "Microsoft.AspNet.Authentication.Twitter": "1.0.0-beta7",
    "Microsoft.AspNet.Diagnostics": "1.0.0-beta7",
    "Microsoft.AspNet.Diagnostics.Entity": "7.0.0-beta7",
    "Microsoft.AspNet.Identity.EntityFramework": "3.0.0-beta7",
    "Microsoft.AspNet.Server.IIS": "1.0.0-beta7",
    "Microsoft.AspNet.Server.WebListener": "1.0.0-beta7",
    "Microsoft.AspNet.StaticFiles": "1.0.0-beta7",
    "Microsoft.AspNet.Tooling.Razor": "1.0.0-beta7",
    "Microsoft.Framework.Configuration.Abstractions": "1.0.0-beta7",
    "Microsoft.Framework.Configuration.Json": "1.0.0-beta7",
    "Microsoft.Framework.Configuration.UserSecrets": "1.0.0-beta7",
    "Microsoft.Framework.Logging": "1.0.0-beta7",
    "Microsoft.Framework.Logging.Console": "1.0.0-beta7",
    "Microsoft.Framework.Logging.Debug": "1.0.0-beta7",
    "Microsoft.VisualStudio.Web.BrowserLink.Loader": "14.0.0-beta7"

In Startup.cs replace the Microsoft.Framework.Runtime namespace with Microsoft.Dnx.Runtime.

using Microsoft.Dnx.Runtime;

The remaining changes are related to entity framework 7. ApplyMigrations has been change to Migrate.



Any migration designer.cs files will need the following changes. The Microsoft.Data.Entity.Migrations.Infrastructure namespace is now Microsoft.Data.Entity.Infrastructure.

using Microsoft.Data.Entity.Infrastructure;

ContextType has changed to DbContext.



The ProductVersion property has been removed and BuildTargetModel is now protected.

public override string ProductVersion
    get { return "7.0.0-beta6-13815"; }

public override void BuildTargetModel(ModelBuilder builder)

protected override void BuildTargetModel(ModelBuilder builder)

The Microsoft.Data.Entity.Migrations.Builders namespace is now Microsoft.Data.Entity.Migrations.Operations.Builders.

using Microsoft.Data.Entity.Migrations.Operations.Builders;

Any classes that inherit from the Migration need the Up and Down functions changed to protected.

public override void Up(MigrationBuilder migration)
public override void Down(MigrationBuilder migration)

protected override void Up(MigrationBuilder migration)
protected override void Down(MigrationBuilder migration)

The AddCoumn of MigrationBuilder now needs a type specified and nullable has changed to isNullable.

migration.AddColumn(name: "UserId", 
                    table: "ContactModel",
                    type: "nvarchar(max)",
                    nullable: true);

migration.AddColumn<string>(name: "UserId",
                            table: "ContactModel",
                            type: "nvarchar(max)",
                            isNullable: true);

The last change to MigrationBuilder that I ran into was with table.ForeginKey. referencedTable and referencedColumn changed to principleTable and principalColumns.

table.ForeignKey(name: "FK_ContactAddressModel_ContactModel_ContactId",
                 columns: x => x.ContactId,
                 referencedTable: "ContactModel",
                 referencedColumn: "Id");

table.ForeignKey(name: "FK_ContactAddressModel_ContactModel_ContactId",
                 columns: x => x.ContactId,
                 principalTable: "ContactModel",
                 principalColumns: new []{"Id"});

That was all the changes needed to get my test project updated. Here is the Github release page and breaking changes page for this release.

Migration of an existing project through the betas does work, but I recommend creating a new project every couple of betas. Things are changing in the project templates as well the core of ASP.NET 5. At the very least create a new project and look through the startup class and implement anything new that you find useful.  For example the debug logger is now included when creating a new project.

Migration from ASP.NET 5 Beta 5 to Beta 6

ASP.NET 5 Beta 6 was released on July 27th with the details from Microsoft in this blog post.  This release comes with a tooling update for Visual Studio 2015 and fewer breaking changes than beta 5.

Download and install the tooling update from here. Grab either DotNetVersionManager-x64.msi or DotNetVersionManager-x86.msi depending on what your system supports and WebToolsExtensionsVS14.msi. For WebToolsExtensionsVS14.msi there are language pack versions available for languages other than english.

With the tooling updates installed the following changes were made from Visual Studio. In global.json update the sdk version to beta 6.

    "projects": [ "src", "test" ],
    "sdk": {
        "version": "1.0.0-beta6"

For project.json in dependencies section update all the values from beta5 to beta6 except for  Microsoft.Framework.CodeGenerator.Mvc which stays at beta5.

"dependencies": {
  "EntityFramework.SqlServer": "7.0.0-beta6",
  "EntityFramework.Commands": "7.0.0-beta6",
  "Microsoft.AspNet.Mvc": "6.0.0-beta6",
  "Microsoft.AspNet.Mvc.TagHelpers": "6.0.0-beta6",
  "Microsoft.AspNet.Authentication.Cookies": "1.0.0-beta6",
  "Microsoft.AspNet.Authentication.Facebook": "1.0.0-beta6",
  "Microsoft.AspNet.Authentication.Google": "1.0.0-beta6",
  "Microsoft.AspNet.Authentication.MicrosoftAccount": "1.0.0-beta6",
  "Microsoft.AspNet.Authentication.Twitter": "1.0.0-beta6",
  "Microsoft.AspNet.Diagnostics": "1.0.0-beta6",
  "Microsoft.AspNet.Diagnostics.Entity": "7.0.0-beta6",
  "Microsoft.AspNet.Identity.EntityFramework": "3.0.0-beta6",
  "Microsoft.AspNet.Server.IIS": "1.0.0-beta6",
  "Microsoft.AspNet.Server.WebListener": "1.0.0-beta6",
  "Microsoft.AspNet.StaticFiles": "1.0.0-beta6",
  "Microsoft.AspNet.Tooling.Razor": "1.0.0-beta6",
  "Microsoft.Framework.Configuration.Json": "1.0.0-beta6",
  "Microsoft.Framework.Configuration.UserSecrets": "1.0.0-beta6",
  "Microsoft.Framework.CodeGenerators.Mvc": "1.0.0-beta5",
  "Microsoft.Framework.Logging": "1.0.0-beta6",
  "Microsoft.Framework.Logging.Console": "1.0.0-beta6",
  "Microsoft.VisualStudio.Web.BrowserLink.Loader": "14.0.0-beta6"

In Startup.cs in the configure function in the is development section I was able to enable browser link and the UseErrorPage dropped the show all option.

if (env.IsDevelopment())

The LogOff action of the AccountController changed to an async operation.

public IActionResult LogOff()
    return RedirectToAction("Index", "Home");

public async Task LogOff()
    await SignInManager.SignOutAsync();
    return RedirectToAction("Index", "Home");

The rest of the changes I had to make are entity framework related. The call to apply migrations no longer requires the as relation call.



If you are trying to keep any existing migrations then changes will need to be made in them as well. There is a namespace change related to moving migrations out of the relational area.



The settings on auto incremented properties changed as well.



That is all there is to moving to beta 6 from beta 5. I am going to leave you with some reference links that may help if your project has issues with the move to beta 6.

Release page on Github with all the change in beta 6
Beta 6 Announcements Github page including breaking changes
ASP.NET 5 Roadmap

ASP.NET 5 Web Site to Azure

At the point the basics of my ASP.NET 4 contacts application have been moved to the ASP.NET 5. This is never going to be a production application, but I want it run it on a remote server just to prove it works. I decided to publish to Microsoft Azure which is Microsoft’s cloud offering. The process was a lot more challenging that I had expected, but as with all the rough spots I have hit with ASP.NET 5 I am sure the path will be made smooth for the final release.

Publishing to Azure from Visual Studio 2015 RC

To get started right click on the project to be published and select the Publish.


This will load the Publish Web dialog. On the Profile tab select the Microsoft Azure Web Apps option.

This will show the Select Existing Web App dialog. Click the New button to add a new Web App.

The new button show the Create Web App on Microsoft Azure. This dialog has a bit more to it. Web App name sets the url of the app as well as the app name with Azure. For region I just chose the closest data center. My application uses a database and I don’t have an existing database server in Azure so I chose Create new server for Database server selection. Database username and password are self explanatory. With all the options filled in click Create.

After the creation process, which creates all the infrastructure need for the app in Azure, is done Visual Studio returns to the Publish Web dialog. The following is the Connection tab. The fields are editable, but are auto filled from the creation process. In case changes are need use the provided Validate Connection button to verify Visual Studio is still able to communicate with Azure.

The Settings tab allows selection of Release or Debug configurations as well as the target DNX version.

The last tab on the Publish Web dialog is Preview. It is not overly useful on a first publish since all the file for the project needed to be push, but on subsequent publishes it would be useful to verify nothing unexpected is being pushed.PublishDialogPreview

Pushing the Publish button on the Publish Web dialog push the files to Azure and opens a browser with the newly published web app.


After a few seconds I was greeted with a HTTP 500 Internal Server Error instead of my web app. I spent a lot of time on the Azure Portal trying to find my issue. I created a new project and published it without issue which means it is a problem with my app and not the publish process. I spent a lot of time digging and Googling my issues, but thankfully ended up with answers.

App Configuration

My first issues were the result of not setting up the configuration options for my user secrets. As I posted last week this was the main worry I had with user secrets. You would think with my concerns that would be the first thing I checked but it actually took me awhile to get around to checking my user secrets. Just to be clear I am not against user secrets I think they are an awesome feature I am just not used to dealing with this side of configuration. The steps to make the proper configuration for user secrets follow.

From the Azure Portal click Browse everything to get a list of all resources.


From All resources click on the Web App that needs configuration. If you are paying close attention you will notice the name of my web app is different than the publication settings above. This is the result of one of my tries to get the site running before discovering the problem was configuration.

Selecting a web app cause the details page to load. On the details page select Settings.

From the settings details page click Application Settings which will load the Web app settings page.AzurePortalWebAppSettings

In Web app settings scroll down to the App settings section. In my case I was missing the Authentication:Google:ClientId and Authentication:Google:ClientSecret settings used for OAuth with Google. Also make note of the Connection strings section as  this is the section where the connection string to the database needs to be entered.

With all the above changes I was finally able to get the site to load.

Database/Entity Framework

As soon as I click on the contact list section of my app I got another HTTP 500 Internal Server Error. This happens to be the first time the app hits the database. The issue this time is that the DefaultConnection string that needs set so the app can connect to the database.

First step to fix this issue is to go back to the All resources on the Azure Portal and select the database that goes with the web app, aspnetcontacts_db in this example.


This will load the SQL Database detail. Under Connection string is a link for Show database connection strings. Clicking this will load a page with a list of connection strings for this database. Copy the appropriate string and replace the dummy password with the real one. Take that connection string with the password enter and put it in your web app’s DefaultConnection. With the DefaultConnection set the 500 error went away.
AzurePortalDbDetailThe next time I ran I got a stack trace with a message that migrations needed to be run. In order to get migrations to run I made a few changes to my project.

The first change was in the ConfigureServices function of Startup.  I added the setup for the ContactsDbContext using the DefaultConnection string. In the ContactsDbContext I removed the OnConfiguring function which is where the connection string for the ContactsDbContext had been set before.

// Add EF services to the services container.
   .AddDbContext<ApplicationDbContext>(options =>
   .AddDbContext<ContactsDbContext>(options =>

In order to actually run migrations for the ContactsDbContext I added a constructor with a call to Database.AsRelational().ApplyMigrations() which will ensure anytime the DbContext is constructed that the latest migrations will be applied. The following is the full ContactsDbContext class after the changes.

public class ContactsDbContext : DbContext
    private static bool _created;
    public DbSet<Contact> Contacts { get; set; }

    public ContactsDbContext()
        if (!_created)
            _created = true;

The last project change was to the ContactsController to allow ASP.NET to inject the ContactsDbContext instead of creating the context with in the controller.

private readonly ContactsDbContext _db;

public ContactsController(ContactsDbContext dbContext)
    _db = dbContext;

The change made above to the ConfigureServices function in the Startup class is how ASP.NET knows what to inject into the ContactsController. Build in dependence injection is one of the new features of ASP.NET 5.

After all the above changes I published to Azure and tried to access the contact list again. This resulted in a different error and a stack trace. The issue this round turned out to be that the default SQL Server created by Azure does not support the way that Entity Framework 7 is auto incrementing the ID column on contacts table. Thankfully there is an updated version of SQL available and the default server just need to be upgraded.

Back on the detail page for the SQL database there is a Server version listed as V2. Click the V2.


This will load the Latest SQL database update page. Click Upgrade This Server.


Currently the SQL Server created by the Visual Studio 2015 RC is in the Web tier which does not support the latest version of SQL which resulted in the warning below.
AzurePortalDbUpgradePriceWarningClick on your database name to load the Recommended pricing tier page. Since this is a new database Azure does not have enough information to recommend a tier and defaults to S0. At the very bottom of the page there is a big blue S0 link. Click it to change pricing tiers.


The Choose your pricing tier page will load. The current setting for the server is Web which shows as a retired. I chose the Basic tier but anything that is not marked as retired should support the newer version of SQL Server. After clicking on the option you want click the Select button at the bottom of the page.


Now that the new pricing tier has been selected go back to the server details and click the V2 link under Server version. This round you will get a big warning. Under the warning enter the name of your server and click OK to perform the upgrade.


The upgrade process took less than 20 minutes for me. After the processes was complete the app worked as expected.

Partial Views

On my contacts list page I want to apply filters without refreshing the whole page. This post is about step one of my first try at accomplishing this goal.

To add a partial view right clicked on the destination folder for the new view and from the Add menu select the View option.AddViewMenu

This brings up the Add View dialog. I am adding a view call _ContactList using the list template since this is going to be a list of contact. Contact is the model the list will be based on and any data access will happen via the ContactDbContext. The last thing to do is check the create as a partial view check box. Clicking add creates a _ContactList.cshtml file.AddViewDialog

The resulting code in _ConactList.cshtml looks like this:

@model IEnumerable<Contacts.Models.Contact>

    @Html.ActionLink("Create New", "Create")
<table class="table">
            @Html.DisplayNameFor(model => model.Name)
            @Html.DisplayNameFor(model => model.Address)
            @Html.DisplayNameFor(model => model.City)
            @Html.DisplayNameFor(model => model.State)
            @Html.DisplayNameFor(model => model.ZipCode)
            @Html.DisplayNameFor(model => model.Country)

@foreach (var item in Model) {
            @Html.DisplayFor(modelItem => item.Name)
            @Html.DisplayFor(modelItem => item.Address)
            @Html.DisplayFor(modelItem => item.City)
            @Html.DisplayFor(modelItem => item.State)
            @Html.DisplayFor(modelItem => item.ZipCode)
            @Html.DisplayFor(modelItem => item.Country)
            @Html.ActionLink("Edit", "Edit", new { id=item.Id }) |
            @Html.ActionLink("Details", "Details", new { id=item.Id }) |
            @Html.ActionLink("Delete", "Delete", new { id=item.Id })


As you can see by choosing the contact model Visual Studio was able to build a view that displays all the properties of the contact. Since I chose the list template the view is expecting a list of contacts that it will iterate over that list and create a table from the list of contacts.

In my index view I was able to remove all the code associated with the contact list and replace it with the following code which renders my new partial view.


This partial view will allow me to have a consistent view of my contact list any where I may need it. It is also my hope that this partial view will allow me to refresh the list portion of the contact list page when a filter is changed.