Today we released various runtime and tooling updates for ASP.NET vNext in Visual Studio “14” CTP 3. We included all the features that were included in Visual Studio 2013 Update 3 in this release. This release also has ASP.NET vNext runtime and tooling improvements as outlined below.
ASP.NET vNext Runtime
This CTP includes our alpha3 runtime packages for ASP.NET vNext. You can find all the details on the specific enhancements added and issues fixed in the published release notes on GitHub.
For information on how to get started with ASP.NET vNext using Visual Studio “14” check out the article Getting Started with ASP.NET vNext and Visual Studio “14”.
The existing MVC Music Store and Bug Tracker sample projects have been updated with the bits for this release. You can find instructions on how to open, build, run, and publish these sample ASP.NET vNext projects in the documentation for the corresponding GitHub repos.
ASP.NET vNext Tooling
No files listed in the .kproj file
When using ASP.NET vNext, all source files in/under the folder that contains project.json will be automatically included in the project. Visual Studio project files typically list each file that is included in the project. In the previous CTPs if you added a file to your source folder it would automatically be reflected in Solution Explorer in Visual Studio. This was facilitated by a file watcher looking for file events and then modifying the .kproj directly. In this release we have updated the .kproj so that the files are not listed. This is consistent with how the runtime consumes those files. Also, not listing the files in the .kproj should significantly ease merging issues that you’ve had in the past with project files.
Because of this breaking change when going from CTP2 to CTP3 it is recommended that you either:
1. Re-create the .kproj file, or
2. Remove files listed in the .kproj file
To re-create the .kproj file you can delete the .kproj and .kproj.user file. Then in Visual Studio you can go to File->Open Project and select the project.json file. Note: after opening that project you may need to update the Output Type property. Take a look at the Opening project.json as a project may lead to the wrong output type topic in Known Issues below for more info.
Just one more thing that I want to point out here. One other reason that we implemented this feature is to allow Visual Studio developers to work with those that are using the command line to build ASP.NET vNext applications. If we assumed that all ASP.NET vNext developers were using Visual Studio then we could have listed each file in the .kproj. This is evidence that we are committed to providing a cross platform story for ASP.NET vNext. On that note in case you missed it you can now develop ASP.NET vNext applications on Macs 🙂
If you have a large number of .kproj files from a previous CTP that need to be updated, the process above may be cumbersome. The other option is to delete the files listed in the .kproj file. The .kproj file is an MSBuild file, which means that it is an XML file. You can write a script to remove the files. If you are using Windows I have developed a PowerShell script that you can use at https://gist.github.com/sayedihashimi/f2048fd957f860f38ecd. Note: this script is not officially supported and provided as it is. If you develop a script that works on other platforms besides windows then feel free to fork and comment to my gist so that others can find it later. I’ll accept any new scripts which appear to work.
When developing software, a critical aspect is to develop and execute unit tests. I’m happy to say that in this CTP you will see our initial support for unit testing in ASP.NET vNext projects. Note: we have not yet integrated creating unit test projects as a part of the new project experience, but we will be working on that. To get started with unit testing follow these instructions.
1. Add an ASP.NET vNext Class Library project for your test cases to your solution
2. Update project.json to include the test runner for your unit testing library of choice
3. Author test cases in that class library
You can find a very basic working sample using xUnit at http://bit.ly/basic-unittestctp3. I’ll describe how you can re-create what is in that project. Below you will find the full project.json for the sample test project. In this sample I will show you how to get started with xUnit, but we are not limited to xUnit. You can plug in any unit testing framework of your choice. Keep an eye on the blog and http://asp.net/vnext for more details about how to integrate other unit testing frameworks.
There are two items that are critical here. The presence of Xunit.KRunner in the dependencies section. This will make the xUnit APIs available so that you can author your test cases. The other item is the test command in the commands section. Commands are executable from the command line with the k utility. If you are interested in command line scenarios see the instructions here to get started. When discovering/executing test cases Visual Studio will look for the presence of a test command, and then invoke the necessary command line to discover & execute test cases. Let’s move on to see the test cases in the project and then how to invoke them in Visual Studio.
In the samples there is a single C# file named SampleTests.cs, below you’ll find the full content for that source file.
Here you can see that we have two simple test cases, TrueIsTrue and OnePlusOneIsTwo. These methods are decorated with the Fact attribute to indicate that they are unit tests and they invoke Assert methods to verify behavior.
After authoring these test cases in Visual Studio you will need to perform an explicit build (CTRL+SHIFT+B for general profile) to discover tests cases. Note: “Run All” does not discover tests cases in this release. After you build the project Visual Studio will discover tests cases and populate the Test Explorer. The image below shows how this will look like for the sample project.
Now that the Test Explorer is populated you can execute them all using the Run All command, or you can select to invoke individual test cases. Let’s click Run All and verify that the test cases pass. You can see the result of that in the image below.
Note: in this release discovering tests cases is a bit slow. You can monitor progress of discovering and executing test cases in the Tests output window. We will be working on improving the performance here in future releases. In this initial release we do not have the ability to debug test cases either. We will light that up soon.
Support for Configuration
We have added support for managing build configurations in the Visual Studio configuration manager. For new solutions/projects you will have two build configurations by default, Debug & Release. If you need to define create new project build configurations you can do so in the configuration manager. In the image below you can see how to invoke the Configuration Manager dialog.
In this case I used the Configuration Manager to create a new project configuration. You can see that there is a new build configuration named Sample in the configurations section. Using build configurations you can customize the options that are passed to the compiler.
Command line scaffolding
In this release you’ll also find our initial support for scaffolding content into existing projects. Currently this is limited to the command line, and is very basic. In future releases you’ll see us beef up the support as well as integrate the experience into Visual Studio. Just like unit testing, we are approaching this in a command-line first approach and having Visual Studio execute those command lines. That way we know that command line and Visual Studio users have similar capabilities. You’ll also be able to create your own custom scaffolders using C# and Razor. Keep an eye out here and on asp.net/vnext for more details on the new command line scaffolding.
Web publish via Web Deploy to Azure Web Sites
In previous CTPs we had enabled publishing your project to Azure Web Sites. We did this through an API which is only available in Azure Web Sites. Since then we have worked with the Web Deploy (aka MSDeploy) team and now publishing is going through Web Deploy. The support is still limited to Azure Web Sites, but this is our first step to enabling a publish experience for other hosting platforms.
There is no visible change from previous releases. All of the changes are under the hood.
If you have tried publishing in previous releases and try publishing in CTP3 you’ll notice that the initial publish experience is much slower than it was in previous releases. In previous releases we had the ability to call specific Azure Web Sites APIs that were optimized for that scenario in particular. This will not be our final experience and you should expect publish times to be much faster in the future.
Most of the time on the initial publish is spent in publishing the NuGet packages that your project references. In later releases we will work with the Web Deploy team to restore known NuGet packages on the server side, thus avoiding the overhead of transmitting each NuGet package from the client to the server. This will significantly improve performance and it will be much faster than previous releases where we used Azure specific APIs.
Opening project.json as a project may lead to the wrong output type
In CTP3, and previous CTPS, when you open project.json as a project, the created project is an ASP.NET vNext Class Library project. If the project is a web project then fixing this is easy. In the properties grid for the project you will find an Output Type property. You can use this to switch from Class Library to Web Application. See the image below.
We’d love to hear your feedback. For Visual Studio tooling related issues, please submit bugs through Connect, send suggestions on UserVoice and quick thoughts via Send-a-Smile in the Visual Studio IDE. For ASP.NET vNext, please provide feedback in Github or the ASP.NET vNext forum. If you ask a question in Stack Overflow, use the asp.net-vnext tag. Thanks for being with us in this exciting time!
Thanks to Sayed Ibrahim Hashimi | @SayedIHashimi, who wrote the majority of this blog.