As you all may already know, ASP.NET MVC is open source and it is up on GitHub. The team has the entire framework out in the open so you can get familiar with it. What I like is we now get a real opportunity to learn the framework we love. How about, cloning the repo off of GitHub and setting a breakpoint? You will see the full request pipeline right in the call stack.

From reading the documentation, there is little on getting a build. This write up is to show you how to get there with zero drama.

How about a story? I once set up Express from source in a matter of minutes. I love how Express sets up their repo, you git clone, npm install and npm test and watch for green lights. The framework runs thousands of unit tests in seconds, all out in the open. I even set a breakpoint using NTVS in Visual Studio and saw a call stack that is flat and beautiful. Coming from such an awesome experience, I expected no less from the folks at Microsoft. But then it happened.

Rule #1: Don't Use Visual Studio

As a Windows developer, my initial attempt was to open Mvc.sln in Visual Studio. What you will realize is that the solution does not build with MSBuild. From my time figuring it out, it is using a custom build system called Sake. My recommendation is to not waste time figuring out Sake. We are here because we want to learn and might contribute to ASP.NET MVC, not its build mechanism.

So start in the command line with git clone then .\build.cmd inside the Mvc directory. My initial crack at it showed many build perils. This led me to open an issue up on GitHub. From experience, the folks there are friendly and willing to get you up off the ground. If you experience issues with the build itself, I would let the team know so they can fix it.

If it all goes well, the build will compile and run all unit tests in minutes. Once done, open up C:\Users\<user> in explorer and peruse through .dnx.

DNVM First, DNX Second

You might start thinking, now what? You've got this colossal code base in your machine with no end in sight. You may start to feel stranded at sea. Look to the right and all you see is code, look left and yes, more code. One way I like to get situated is to check out the unit tests. But first, let's discuss the dnvm command.

DNVM is the versioning system for the DNX runtime. Start by typing dnvm list. If there isn't a star next to any runtime environment, try dnvm use default. The build installs the runtimes and you must use one to run tests. In my current setup, the default is sufficient but you may need to set it up yourself. Typing up dnvm without arguments reveals how to use it. There is documentation out there that covers the basics.

As a warning, once you get a working build, don't f*** with it! Building more than once downloads the latest packages and runtimes which may fail. Trust me, it is a rat race you don't want to be in. DNX will “compile” code changes on the fly with Rosyln. The initial build is just to get the whole system up off the ground.

Now that you have selected a suitable runtime, do this in the Mvc folder:

> cd test\Microsoft.AspNet.Mvc.Core.Test
> dnx test
> dnx test -method Microsoft.AspNet.Mvc.Controllers
    .DefaultControllerFactoryTest
    .CreateController_SetsControllerContext

To know where the -method flag came from, type dnx test -? to see the full list of command line options.

Set a Breakpoint!

You may start wondering, tests pass so what? Remember rule #1? It was a temporary commandment made for fulfillment. You didn't think Visual Studio would be obsolete now, did you? Time to fire up Mvc.sln inside Visual Studio.

Once inside the solution, find Controllers\DefaultControllerFactoryTest.cs:102 in the folder above and set a breakpoint. Now, it is time to fire the test in DNX:

> dnx --debug test -method Microsoft.AspNet.Mvc.Controllers
    .DefaultControllerFactoryTest
    .CreateController_SetsControllerContext

The --debug flags tells DNX to wait. Go to Visual Studio and attach to the proper process id. Once done, you should see it hit the breakpoint.

Breakpoint hit in Visual Studio

Amazing, huh? How about more awesomeness? Set a breakpoint inside MvcMinimalSample.Web\HomeController.cs:10. This should be the home controller of a minimal MVC app. Type this up inside the Mvc folder:

> cd samples\MvcMinimalSample.Web
> dnx --debug web

The prompt waits for you to attach then visit http://localhost:5000 in the browser. BAM! That should hit the controller with a full blown call stack.

Full ASP.NET MVC call stack

Feel free to explore around the stack, you can move up and down. See how the request pipeline invokes the controller. The FilterActionInvoker creates the controller. It is actually making my controller, too beautiful to describe in words.

Conclusion

The full ASP.NET MVC stack is out in the open and the team has been making strides towards transparency. What I like the most is now you and I get a say in all this. It is like having input in the future of our careers. ASP.NET is a well respected stack in the enterprise and its future looks bright. My recommendation is learn the guts and bolts of this awesome framework. Perhaps, you'll learn what makes it great and integrate that into your own practice.

The post Build ASP.NET MVC from Source Code appeared first on BeautifulCoder.NET.