Your official information source from the .NET Web Development and Tools group at Microsoft.
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.
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.
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.
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.
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.
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.
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.
A big THANK YOU for finally bringing sanity to VS project files.
Listing every single file in the project file was plain wrong. That's what the file system was invented for. I wonder how that terrible idea survived for so long - torturing developers with merge conflicts for years...
I was complaining about the project file merge issues just a few days ago! Thank you!
How will we exclude sources from a project that are (temporarily) not ready for inclusion?
@Marc, you can workaround that problem by move the file out of the project folder and add a link to the VS project. This way, the file will not participate in compiling (it's not seen by project.json), but still see-able in the VS as it's linked in .kproj file.
a couple of questions about the kproj file format:
How does the new platform deal with
- custom build actions (embedded resources / copy local etc)
- assembly options (in particular the invaluable Private / SpecificVersion elements)
Does the new command line tooling deal with these old style MSBuild scenarios?
Although I'm excited about these vNext features - I remember the pain associated with the older ASP.NET Websites (folder based projects) in that they became a nightmare once managing any significantly complex project.
Was also wondering as vNext is such a radical departure - whether it would be better to retire the ASP.NET brand as you are essentially jettisoning the legacy of both classic ASP and ASP.NET.
Drop these json as configuraion file. XML have better readibility
i am waitting for VS2014...
Thank you for the update! Where can I read about all the changes made to XNA to update it for the Visual Studio 2014? Unless you are only going to update the project templates.
Also, how do I add a comment inside a .kproj file?
It can often be quite useful. Surely a new superior serialization format supports that as well as XML does.
@Den, I hope the uservoice XNA link will have some answers, we're not in the same team. ".kproj" file is with XML format, so you can comment as XML comment. Project.json is with JSON format, you can see the JSON comment question in stackoverflow.com/.../can-i-comment-a-json-file
@Marc you can exclude files from compile/publish in project.json. In a future release we will add support for excluding files from compile/publish directly in Visual Studio so that you don't need to edit that file directly.
@Howard for Visual Studio scenarios there is the .kproj file, which is an MSBuild file. We are still working on the story for build customizations/extension. Keep an eye here for more details as we make progress there.
- MSBuild already has wildcard file support - see msdn.microsoft.com/.../ms171453.aspx
<Compile Include="**\*.cs" Exclude="DoNotBuild.cs"/>
- Alas, VisualStudio Solution Explorer UI has poor support for this advanced feature
It would be great to fix the VS problem instead of considering that msbuild design is flawed (it is not, at least on this point).
ASP.NET team has already tried "web sites vs web projects" experience in the past, introducing the awful idea "to exclude files VS will rename them as .exclude"
That's good feedback and we'll make sure to pass that along to the VS team. There are some challenges with making wildcards work well in VS I'm sure but maybe they are all solvable. We think we hit the sweet spot between websites and web applications this time.
XML vs JSON can be debated forever but the key thing here is that the project file format is declarative. It itself is not an msbuild file. It can be built using msbuild via the kproj and a pipeline can be built around the kroj but we are trying to avoid conflating the project format with the build system. It a cleaner separation that allows for more flexibility.
Very good !! Many Thks guys