I am super geeked to be heading down to Austin, TX to speak at Measure Up this coming September 26th. Measure Up 2015 is the inaugural skills and career development conference put on by the folks at Clear Measure.

This conference is packed with all kinds of great speakers and covers a variety of topics related to business development, dev ops, personal growth and, of course, how to be mind-bendingly awesome at making software. I am going to be talking about the things you need to know when you’re moving to MVC 6, and sharing about my experiences as a remote worker.

If You Live in the Austin Area…

…you have no excuses to miss this event. Register today, it’s only $10, and dedicate one day this year to getting yourself closer to your dream career.

If You Don’t Live in the Austin Area…

…you should probably talk to your boss about getting down there for the day. It’s hard to find a conference with this kind of content and (essentially) only have to pay for a bit of travel, perhaps a hotel room. Professional development does not come with this value for this little.

So, What Are You Waiting For?

Check out the conference agenda. Dev ops, docker. vNext, continuous deployment, load testing, microsevices, infrastructure as code and more.

Register for the event. Seriously, ten bucks_. _

See you in September! ‘Til then, happy coding!

The Beta 6 release of ASP.NET 5 is now available. Run the following command to upgrade from a previous version:

dnvm upgrade

After that, a “dnvm list” command will give you the following:

You can also upgrade dnvm itself with the following command:

dnvm update-self

Which will get you up to the beta 7 version (build 10400) of DNVM.

You’ll also need the updated VS 2015 tooling, which is available here (along with the DNVM update tools if you want them seperately): Microsoft Visual Studio 2015 Beta 6 Tooling Download.

Why This is Important

As part of my progression in porting an MVC 5 app to MVC 6, one scenario that I needed support for was to have libraries targeting .NET 4.6 reference-able from a DNX project. MVC 6, up to this point, only supported 4.5.1, which meant that you’d have to roll back your targeting if you were on 4.5.2 or 4.6.

Of course, multi-targeting is a better option, but requires the time and capacity to either slave over the old code base and NuGet packaging nuances, or port to the new project format where you have much greater in-project support for targeting multiple frameworks.

What You Get

As previously detailed by Damien Edwards, there are bug fixes, features and improvements in the following areas: Runtime, MVC, Razor, Identity. In addition to supporting .NET 4.6 in DNX, they have also added localization and have been working on other things like distributed caching, which you can read about here.

What To Watch Out For

This is still a beta, and there are many moving parts.

Be sure to check out the community standup today and head over to GitHub for the announcements on breaking changes.

Happy coding!

The updates in the .NET Framework provide many improvements, including support for new language features in c#, garbage collection, enhancements in cryptography support, feature toggles, new classes in the BCL and others. The RyuJIT compiler adds significant performance gains for 64bit applications, even those not originally targeting the 4.6, improves startup times and can reduce the memory footprint of your application.

_In this series we’re working through the conversion of an MVC 5-based application and migrating it to MVC 6. You can track the entire series of posts from the _intro page_._

While the explicit modification of your projects may not be required to gain some of the 4.6 benefits, there may be other organizational factors that lead you down that path. We’ll work through the mechanics of the upgrade to 4.6 in this post.

A Word of Caution

UPDATE: July 28, 2015 There is a known issue with certain 64bit applications running on .NET 4.6, under certain circumstances, with certain parameter types and sizes. You can read more about the bug finding here and the issue is being tracked on GitHub, followed by Microsoft’s response and recommendation.

For this reason I am not recommending an upgrade to 4.6 unless you understand the implications and how to properly vet the scenarios described in your environment.

Getting Your Projects Up-to-date

Every project we create references a specific version of the .NET Framework. This has been true throughout the history of .NET, and though the way we will do it in the future will change with the new project system, the premise remains the same.

For now, you can simply open the properties tab for your project and change the target Framework.

You will be prompted to let you know that some changes may be required.

Note that in my case, I had 7 projects with varying types of references and dependencies, and no modifications were required to the code. Your mileage may vary, of course, but this is a simple change and one that you can test quickly. With proper source control in place, this is a zero-risk test that should take only a moment or two.

Now, if you were to try to build the Bootcamp project when you’re only partway through the upgrade, you’d see something similar to the following:

With a message that reads:

The primary reference “x” could not be resolved because it was built against the “.NETFramework,Version=v4.6” framework. The is a higher version than the currently targeted framework “.NETFramework,Version=4.5.1”.

You may run into this in other scenarios, as well, especially if you you have references to packages or libraries that get out of sync in your upgrade process. A project that takes on dependencies must be at (or higher than) the target framework of the compiled dependencies. To remedy this, we simply need to complete the upgrade process on the rest of the projects.

This was pretty painless.

Reasons to Upgrade?

Moving from 4.5.x to 4.6 is not a required step in our conversion to an MVC 6 project. In fact, MVC 6 indeed runs on a different framework altogether. To that end, any environment where you have 4.6 installed will “pull up” other assemblies because it is a drop-in replacement for pervious versions.

Perhaps your primary motivator to move to 4.6 is the perf bump in the runtime, or it might be the new language features (which only require a framework install, not a version bump in your target). But it also ensures we’re compatible with other projects in our organization, particularly when we consider the default target for new projects in VS 2015 is against 4.6. If we want to leverage these from other projects in our organization, we want to make sure that we’re not the lowest common denominator in the mix.

The Next Step

However, there are a couple of other points that we should note, namely that our compiler isn’t tied to the installed framework or the runtime, it’s just used to target a specific set of instructions that the runtime can digest. So, if our MVC 6 will be running on DNX46, or we have other .NET 4.6 projects we’re all set (though, we’d have to use DNU wrap to consume our library at this point in DNX).

But what if we have different projects across our organization, or we have external teams using our libraries? The answer lies in multi-targeting, which is what we’ll address in the next post in this series.

Until then, happy coding!

If you’re modernizing your project, one of the things you’ll surely want to do is to make sure that your build server is upgraded to support VS 2015. Regardless of what CI engine you’re using, there will be at least a little bit of effort required to get your project building again.

_In this series we’re working through the conversion of an MVC 5-based application and migrating it to MVC 6. You can track the entire series of posts from the _intro page_._

For the purpose of this exercise, we’re using TeamCity to run our builds based on a VSC checkin. We’ll get TeamCity prepped to run our build and then update our repository so that we show our build status indicator on the readme home page.

The TL;DR Details

Here’s the basics of what was required to get the builds back online:

• Backup and upgrade TeamCity
• Allow the agents to upgrade, or upgrade them manually
• Install .NET 4.6 and the VS 2015 tools
• Ensure that build targets live on your build agents
• Run your build

Upgrading the Server

I engaged my teammate James Allen here to help with some best practices, namely getting the server backed up. You can either back up the TeamCity data from the web interface or one of the other recommended approaches, or you could snapshot your server for a reset should one be required. During this process, it’s a good idea to spin down your build agents so that you’re not wrecking anyone’s builds.

Next, we needed to move to version 9.1 of TeamCity, so we ran the upgrade process via the web site. This is a painless task and takes only a fraction of the time it took to back up the data. Failing any troubles (we saw none), your build server should be back online in no time, and the build agents were notified (and complied!) to update themselves as well.

Next, I downloaded and installed the .NET 4.6 installer and the VS 2015 tooling, which can be found on the VS 2015 download page. You’ll need to explore through the available downloads on the page, as you can see on this screenshot, to grab the relevant files.

These installs will need to be run on every build agent.

One thing to note was that my original attempt to get the build running failed because of missing build targets at an expected location. I ended up having to copy files from my local machine, where Visual Studio 2015 is installed, from the path: C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0 on the build server.

UPDATE: With the availability of the MS Build Tools for Visual Studio 2015 you no longer have to manually zip up and copy the files. You can download the MS Build Tools 2015 here.

Verifying the Install

You’ll know the tools have been installed correctly if you return to the build configuration settings and add a new build step for msbuild (you don’t have to save it). You’ll see that you’ll have the new options in place:

The build server should be good to go now! For us, we’re not using an MSBuild build runner, our application is build with a PowerShell script via a batch file. This allows our build to be executed locally with only a small parameter change, and the CI process is entirely encapsulated in code (and under source control).

Provided your project is pointing at the repository, you’ll have a good shot at running the build at this point. For our project, everything worked as expected.

Showing Some Bling

Now it’s time to beef up our repo, at least a little. What I’m talking about is wearing our CI on our sleeve, letting everyone on the team (or other watchers of the repository) that our builds are healthy or, perhaps, needing some love; let’s display the build status indicator on our readme, like this:

First, drill into the build configuration and locate the advanced options under “General Settings”. You need to enable the status widget.

Also, from this screen, take note of your Build Configuration ID. This is important because you’ll need to include it in the server request to generate the badge.

Finally, include the following markdown, which is essentially a formatted link with an image inside of it:

Current Build Status [![](http://YOUR_SERVER/app/rest/builds/buildType:(id:YOUR_BUILD_CONFIGURATION_ID)/statusIcon)](http://teamcity/viewType.html?buildTypeId=btN&guest=1)

Be sure to replace the obvious placeholder tokens with your own information.

Next Steps

With our build server updated and our builds back online, it’s time to start shifting our targets. In the next post, we’re going to update our projects and recover from any errors/challenges we may discover along the way.

Happy coding!

The folks on the Visual Studio team have been making it increasingly easier to move from version-to-version with less impact on our projects. In this post I’m going to examine the process of moving from Visual Studio 2013 to Visual Studio 2015.

_In this series we’re working through the conversion of an MVC 5-based application and migrating it to MVC 6. You can track the entire series of posts from the _intro page_._

The Backstory

First, a bit about our application. I said this was a real-world application, and it is. You can clone the repo and run it locally if you like.

What we have is an expense report application, albeit a little on the light side for features. No worries, though, that is the intent! But the real pieces of an application sporting Onion Architecture are in place, and there’s quite a bit of commonly-used tech in this bad boy that you would likely find in any real-world app:

• Separate projects for separate concerns
• A UI Project that stands with only a single reference (to Core)
• An older version of NHibernate
• Unit tests
• HTTP Handlers
• The Bootstrap CSS/JS library
• StructureMap for dependency injection
• A database migrations library
• A custom workflow engine

So, this is no File –> New –> Project here, this is the real deal.

First Steps

The first issue we’re going to address is the fact that our solution and project are currently in VS 2013 “mode”.  In the past, you’d likely have to walk through some kind of conversion process and this was usually a compelling enough reason for people to back delay an upgrade. Did you ever have issues with incorrect file paths, incompatible project type identifiers, broken project references and builds broken due to missing dependencies? At times, I’ve even had to resort to manually editing the solution and project files to get a project back online.  Thankfully, this is nothing like that. There is nothing major we need to do in order to get our project open in Visual Studio 2015, just load the solution from disk.

In the case of Bootcamp, our project opens cleanly and builds as we would expect. But you’ll notice right away a change in the repo.

Visual Studio 2015 runs IIS Express in a more specific context than previous versions, which is a huge win. The applicationhost.config is basically everything you need to get the web server up locally while you develop, debug and test, and it replaces what we would used to use for IIS Express for machine-wide configuration.

This file also happens to be in the .vs directory, used only for devs running Visual Studio on Windows. It’s also easily regenerated for other developers and we don’t need to check it into source control, lest we be endlessly trumping each others’ local changes. Instead of any project or solution modifications, we’re instead going to modify the .gitignore file, adding the following line:

**/src/.vs/

Great stuff! Easy, and we’re running in the latest version of everyone’s favorite IDE. We haven’t yet made any project structure changes, haven’t targeted any new .NET bits, but now we’re ready to start those pieces.

The pull request for this post can be reviewed here.

  Pro tip  To get your solution to open in Visual Studio 2015 by default, instead of Visual Studio 2013, you can simply update the first few lines of your .sln file to include the following:
# Visual Studio 14

VisualStudioVersion = 14.0.23107.0

Next Steps

I’ve been running different incarnations of VS 2015 on my machine alongside Visual Studio 2013 (and for a period, VS 2010 as well) without any gotchas. There are some great new features that are worth checking out (it’s a long list), and your team may be able to leverage them.

While this is a short and single-focused post, I hope you see that opening the project in VS 2015 may yield no negative side effects. Heck, if you’re not sure you want to try it on your metal, you can even jump on a free trial of Azure and attempt to open your project on a VM running 2015.

Happy coding!

These are exciting times for web development on the Microsoft stack, but perhaps a little confusing as well. For many years the cycle of moving from one solution and project system to the next hasn’t been overly complex. Sure, there have been breaking changes, I’ve felt those pains myself, but provided the framework you were using continued to live on, there was a reasonable migration path.

Moving to MVC 6 is going to be a big shift for a lot of development teams, but that doesn’t mean it needs to be scary, complicated or introduce instability into your project.

It does, however, mean that you’re going to need an attitude of learning, that you’ll pick up some new tooling, you’ll have to brush up on your JavaScript and work with some new concepts.

Let’s Make it Happen

I’m super excited to now be part of the excellent crew at Clear Measure, where this type of attitude seems to be fostered, encouraged and embodied by other members of the team and, more importantly, the management.

We’re now undertaking the process of converting from MVC5 => MVC6 with our Bootcamp workshop project and I have the privilege of blogging my experience with it as I go. We’re going to keep the project building and operable as we go, such that at an point it can be shipped to production or branched for feature development.  We’ll be using GitFlow, feature branches, continuous integration and continuous deployment.  Our check-ins will be code that builds cleanly with passing tests.

And, for those of you who come join in our our MVC Masters Bootcamp sessions, you’ll also get to work on this code base with all the tools, exposure to pair programming, a dedicated product owner and 3 days of intense coding.

Shameless plug: If you want to level up your team of developers, please reach out to Gina Hollis at Clear Measure to plan an on- or off-site event. We promise to melt your minds.

How We’re Getting There

Well, to start it off, we’re beginning with our initial commit as the MVC 5 project Jeffrey Palermo’s been using in the Masters Bootcamp for some time.

The application is hosted on GitHub and you can see the issues that we’re identifying and working through. We’re doing the whole thing as open source in hopes that other teams can learn from what we learn in the process.

And, as I knock items off the issue list I’ll be posting about them here, covering the challenges, pitfalls and wins we encounter along the way. You can bookmark this post for updates in the project. Feel free to ask questions on the issues in the repository, or ping me on Twitter (@CanadianJames).

Stay tuned!

• Part 1: Moving to VS2015 from VS2013
• Part 2: Getting Your Build Server Ready for VS2015
• Part 3: Retargeting Projects to .NET 4.6
• Part 4: Multitargeting Projects with VS2015 Projects