Introducing ASP.NET 5

Monday, February 23, 2015

The first preview release of ASP.NET 1.0 came out almost 15 years ago. Since then millions of developers have used it to build and run great web applications, and over the years we have added and evolved many, many capabilities to it.

I'm excited today to post about a new release of ASP.NET that we are working on that we are calling ASP.NET 5. This new release is one of the most significant architectural updates we've done to ASP.NET. As part of this release we are making ASP.NET leaner, more modular, cross-platform, and cloud optimized. The ASP.NET 5 preview is now available as a preview release, and you can start using it today by downloading the latest CTP of Visual Studio 2015 which we just made available.

ASP.NET 5 is an open source web framework for building modern web applications that can be developed and run on Windows, Linux and the Mac. It includes the MVC 6 framework, which now combines the features of MVC and Web API into a single web programming framework. ASP.NET 5 will also be the basis for SignalR 3 - enabling you to add real time functionality to cloud connected applications. ASP.NET 5 is built on the .NET Core runtime, but it can also be run on the full .NET Framework for maximum compatibility.

With ASP.NET 5 we are making a number of architectural changes that makes the core web framework much leaner (it no longer requires System.Web.dll) and more modular (almost all features are now implemented as NuGet modules - allowing you to optimize your app to have just what you need). With ASP.NET 5 you gain the following foundational improvements:

Build and run cross-platform ASP.NET apps on Windows, Mac and Linux
Built on .NET Core, which supports true side-by-side app versioning
New tooling that simplifies modern Web development
Single aligned web stack for Web UI and Web APIs
Cloud-ready environment-based configuration
Integrated support for creating and using NuGet packages
Built-in support for dependency injection
Ability to host on IIS or self-host in your own process

The end result is an ASP.NET that you'll feel very familiar with, and which is also now even more tuned for modern web development.

Flexible, Cross-Platform Runtime

ASP.NET 5 works with two runtime environments to give you greater flexibility when hosting your app. The two runtime choices are:

.NET Core – a new, modular, cross-platform runtime with a smaller footprint. When you target the .NET Core, you’ll be able to take advantage of some exciting new benefits:

1) You can deploy the .NET Core runtime with your app which means your app will run with this deployed version of the runtime rather than the version of the runtime that is installed on the host operating system. Your version of the runtime runs side-by-side with versions for other apps. You can update that runtime, if needed, without affecting other apps, or you can continue running on the same version even though other apps on the system have been updated. This makes app deployment and framework updates much easier and less impactful to other apps running on a system.

2) Your app is only dependent on features it really needs. Therefore, you are never prompted to update/service the runtime for features that are not relevant to your app. You will spend less time testing and deploying updates that are perhaps unrelated to the functionality of your app.

3) Your app can now be run cross-platform. We will provide a cross-platform version of .NET Core for Windows, Linux and Mac OS X systems. Regardless of which operating system you use for development or which operating system you target for deployment, you will be able to use .NET. The cross-platform version of the runtime has not been released yet, but we are working on it on GitHub and plan to have an official preview of it out soon.

.NET Framework – The API for .NET Core is currently more limited than the full .NET Framework, so you may need to modify existing apps to target .NET Core. If you don't want to have to update your app you can instead run ASP.NET 5 applications on the full .NET Framework (version 4.5.2 and above). When doing this you have access to the complete set of .NET Framework APIs. Your existing applications and libraries will work without modification on this runtime.

MVC 6 - a unified programming model

MVC, Web API and Web Pages provide complementary functionality and are frequently used together when developing a solution. However, in past ASP.NET releases, these programming frameworks were implemented separately and therefore contained some duplication and inconsistencies. With MVC 6, we are merging those models into a single programming model. Now, you can create a single web application that handles the Web UI and data services without needing to reconcile differences in these programming frameworks. You will also be able to seamlessly transition a simple site first developed with Web Pages into a more robust MVC application.

You can now return Razor views and content-negotiated data from the same controller and using the same MVC filter pipeline.

In addition to unifying the existing frameworks we are also adding new features to make server-side Web development easier, like the new tag helpers feature. Tag helpers let you use HTML helpers in your views by simply extending the semantics of tags in your markup.

So instead of writing this:

@Html.ValidationSummary(true, "", new { @class = "text-danger" })

<div class="form-group">

    @Html.LabelFor(m => m.UserName, new { @class = "col-md-2 control-label" })

    <div class="col-md-10">

        @Html.TextBoxFor(m => m.UserName, new { @class = "form-control" })

        @Html.ValidationMessageFor(m => m.UserName, "", new { @class = "text-danger" })

    </div>

</div>

You can instead write this:

<div asp-validation-summary="ModelOnly" class="text-danger"></div>

<div class="form-group">

    <label asp-for="UserName" class="col-md-2 control-label"></label>

    <div class="col-md-10">

        <input asp-for="UserName" class="form-control" />

        <span asp-validation-for="UserName" class="text-danger"></span>

    </div>

</div>

Tag helpers make authoring your views more natural and readable. They also simplify customizing the output of HTML helpers with additional markup while letting you take full advantage of the HTML editor.

For more examples of creating MVC 6 apps, see these tutorials.

Modern web development

This week's ASP.NET 5 preview also includes a number of other great development features that enable you to build even better web applications:

Dynamic Development

In Visual Studio 2015, we take advantage of dynamic compilation to provide a streamlined developer experience. You no longer have to compile your application every time you want to see a change. Instead, just (1) edit the code, (2) save your changes, (3) refresh the browser, and then (4) see your change automatically appear.

You enjoy a development experience that is similar to working with an interpreted language without sacrificing the benefits of a compiled language.

You can also optionally use other code editors to work on your ASP.NET 5 projects. Every function within the Visual Studio user interface is matched with cross-platform command-line operations.

Integration with Popular Web Development Tools (Bower, Grunt and Gulp)

Another exciting feature in Visual Studio 2015 is built-in support for Bower, Grunt, and Gulp - popular open source tools that we think should be in every Web developer’s toolkit.

Bower is a package manager for client-side libraries, including both JavaScript and CSS libraries.
Grunt and Gulp are task runners, which help you to automate your web development workflow. You can use Grunt or Gulp for tasks like compiling LESS, CoffeeScript, or TypeScript files, running JSLint, or minifying JavaScript files.

Bower: To add a JavaScript library to your ASP.NET project add it directly in the bower.json config file:

Notice that Visual Studio gives you IntelliSense with a list of available packages. The next time you open the solution, Visual Studio automatically restores any missing packages, so you don’t need to check the packages into source control.

For server-side packages, you’ll still use NuGet Package Manager.

Grunt: In modern web development, you can find yourself managing a lot of tasks, just to build your app: Compiling LESS, TypeScript, or CoffeeScript files, linting, JavaScript minification, running JS unit tests, and so on. Every team will have its own set of requirements, depending on the particular tools that you use. Task runners make it easier to manage and coordinate these tasks. Visual Studio 2015 will support two popular task runners, Grunt and Gulp.

For example, let’s say you want to use Grunt to compile LESS files. Just go into package.json and add the grunt-contrib-less package, which is a third-party Grunt plugin.

Use the new Task Runner Explorer in Visual Studio 2015 to bind the task to a build step (pre-build, post-build, clean, or when the solution is opened).

This makes it incredibly easy to automate common tasks within your projects - and have them work both for you, as well as across a team wide project.

Simplified dependency management

In ASP.NET 5 you manage dependencies by adding NuGet packages. You can use the NuGet Package Manager or simply edit the JSON file (project.json) that lists the NuGet packages and versions used in your project. The project.json file is easy to work with and you can edit it with any text editor, which enables you to update dependencies even when the app has been deployed to the cloud.

The project.json file looks like:

In Visual Studio 2015, IntelliSense assists you with finding the available NuGet packages that you can add as dependencies.

And, Intellisense can even help you with the available versions:

Cloud-ready configuration

In ASP.NET 5, we eliminated the need to use Web.config file for configuration values. We wanted to make it easier for you to deploy your app to the cloud and have the app automatically read the correct configuration values for that environment. The new system enables you to request named values from a variety of sources (such as JSON, XML, or environment variables). You can decide which formats work best in your situation.

In the Startup.cs file, you can now add or remove the sources for configuration values.

The above code snippet shows a project that is set up to retrieve configuration values from a JSON file and environmental variables. You can change this code if you need to specify other sources. In the specified config.json file, you could provide the values.

In your host environment, such as Azure, you can set the environmental variables and those values are automatically used instead of local configuration values after the application is deployed. You can deploy your application without worrying about publishing test values.

Dependency injection (DI)

Dependency Injection (DI) is supported in existing ASP.NET frameworks, like MVC, Web API and SignalR, but not in a consistent and holistic way. ASP.NET 5 provides a built-in DI abstraction that is available in a consistent way throughout the entire web stack. You can access services at startup, in middleware, in filters, in controllers, in model binding and virtually any part of the pipeline where you want to use your services. ASP.NET 5 includes a minimalistic DI container to bootstrap the system, but you can easily replace the default container with your container of choice (Autofac, Ninject, etc). Services can be singleton, scoped to the request or transient.

For example, to see how to use constructor injection with ASP.NET MVC 6, create a new ASP.NET 5 Starter Web project and add a simple time service:

using System;

namespace WebApplication1

{

    public class TimeService

    {

        public TimeService()

        {

            Ticks = DateTime.Now.Ticks.ToString();

        }

        public String Ticks { get; set; }

    }

}

The simple service class sets the current Ticks when the constructor is called.

Next, register the time service as a transient service in the ConfigureServices method of the Startup class:

public void ConfigureServices(IServiceCollection services)

{

services.AddMvc();

services.AddTransient<TimeService>();

}

Then, update the HomeController to use constructor injection and to write the Ticks when the TimeService object was created.

public class HomeController : Controller

{

    public TimeService TimeService { get; set; }

    public HomeController(TimeService timeService)

    {

        TimeService = timeService;

    }

    public IActionResult About()

    {

        ViewBag.Message = TimeService.Ticks + " From Controller";

        System.Threading.Thread.Sleep(1);

        return View();

    }

    // Code removed for brevity

}

Notice the controller doesn't create a TimeService. It's injected when the controller is instantiated.

In MVC 6 you can use the [Activate] attribute to inject services via properties. You can use [Activate] not just on controllers but also on filters, and view components. This means you can simplify your controller code like this:

public class HomeController : Controller

{

    [Activate]

    public TimeService TimeService { get; set; }

    // Code removed for brevity

}

MVC 6 also supports DI into Razor views via the @inject keyword. In the code below, I’ve injected the time service into the about view directly and defined a TimeSvc property by which it can be accessed:

@using WebApplication23

@inject TimeService TimeSvc

<h3>@ViewBag.Message</h3>

<h3>

@TimeSvc.Ticks From Razor

</h3>

When you run the app, you can see different ticks values from the controller and the view.

Fast HTTP performance

ASP.NET 5 introduces a new HTTP request pipeline that is modular so you can add only the components that you need. The pipeline is also no longer dependent on System.Web. By reducing the overhead in the pipeline, your app can experience better throughput and a more tuned HTTP stack. The new pipeline is based on many of the learnings from the Katana project and also supports OWIN.

To customize which components are used in the pipeline, use the Configure method in your Startup class. The Configure method is used to specify which middleware you want to “use” in your request pipeline. ASP.NET 5 already includes ported versions of many of the middleware from the Katana project, like middleware for static files, authentication and diagnostics. The following image shows some of the features you can add or remove to the pipeline for your project.

public void Configure(IApplicationBuilder app)

{

    // Add static files to the request pipeline.

    app.UseStaticFiles();

    // Add cookie-based authentication to the request pipeline.

    app.UseIdentity();

    // Add MVC and routing to the request pipeline.

    app.UseMvc(routes =>

    {

    routes.MapRoute(

        name: "default",

        template: "{controller}/{action}/{id?}",

        defaults: new { controller = "Home", action = "Index" });

});

You can also write your own middleware components and add them to the pipeline.

Open source

We are developing ASP.NET 5 as an open source project on GitHub. You can view the code, see when changes were made, download the code, and submit changes. We believe making ASP.NET 5 open source will we make it easier for you to understand the code, understand our intended direction, and contribute to the project.

Docs and tutorials

To get started with ASP.NET 5 you can find docs and tutorials on the ASP.NET site at http://asp.net/vnext. The following tutorials will guide you through the steps of creating your first ASP.NET 5 project.

Also read this article for even more ASP.NET and Web Development improvements coming this week.

Hope this help,

Scott

148 Comments

> The above code snippet shows a project that is set up to retrieve configuration values from a JSON file and environmental variables.

The config.json file in the example, how is that protected by the webserver/http server? web.config is protected by IIS, but if any file can be used (which is great), it also comes with the burden that the webserver shouldn't serve the file out if one requests it in a URL. Or are there prefab names to choose from?

Frans Bouma - Monday, February 23, 2015 9:07:24 PM

I can't wait to start using this.. So much awesome.. So to speak every thing I miss in todays ASP.NET and .NET for that matter, is dealt with here with surgical precision. Perfect! LOVE THIS!!! Go Microsoft, go you genius!!

Hans Olav - Monday, February 23, 2015 9:12:21 PM

Most incredibly awesome. Razor markup looks way better... but it is still no Xaml. ;) MVC6 + Xamarin.Forms for the cross-platform W-I-N!

MichaelD! - Monday, February 23, 2015 9:12:37 PM

Hi Scott,

Any roadmap you can share with us all?

Released Q3/Q4?

Thanks in advance,
Bart

Bart Plasmeijer - Monday, February 23, 2015 9:22:33 PM

@Frans,

"Application code", and static resources are now entirely split into an "approot", and "wwwroot" directories respectively. The web server only sees what is in wwwroot, which only contains static resources that are safe to serve. If you request /config.json - it will 404, as far as the web server is concerned, it doesn't exist.

ChadT - Monday, February 23, 2015 9:51:39 PM

So we're not at go-live stage yet, right?

Jeff - Monday, February 23, 2015 9:52:25 PM

Frans, If you look in an ASP.NET 5 application, it now contains a wwwroot node in your project. That is the only part of your project that static files can be served from. This is a change from older versions of ASP.NET where we had a mix of static and dynamic files all throughout your project. Now it is very clear. And we use this so we can have a file elsewhere in your project and run tasks to minimize and copy the minimized version to that folder. Also this is how all of our npm support works, we grab scripts from npm and then via a build step move them to wwwroot. Note this is by convention, and is configurable so developer if they want to use a different named folder. Since project.json is outside of that folder it can't be served.

Scott Hunter - Monday, February 23, 2015 9:53:52 PM

Congratulations guys! I've never been so excited with ASP.NET, seriously. This is the BEST TIME to be an ASP.NET developer.
I'm proud to be part of it.
THANK YOU.

Kim Tranjan - Monday, February 23, 2015 10:22:54 PM

Cross-platform ASP.NET is fantastic. Nice job!

alex - Monday, February 23, 2015 11:26:01 PM

Fantastic features! Thank you!

Nicholas - Tuesday, February 24, 2015 1:13:50 AM

Jeff, we don't have any license that prevents you from using the code in production at this point, it is use at own risk. Technically Go Live license means that we would service the code if there was some really bad bug in it. We are targeting the next release to have a go live.

Scott Hunter - Tuesday, February 24, 2015 1:27:54 AM

As a full time .net developer

Pros:
Bower Thx!
ConfigureServices (nice simple IoC, but i still need to see how it behaves with sub dependencies, like Sessions/Contexts)
Open Source Bravoo!!

Cons:
WHYYYYYYYYYYYYYYYYYYYYYY!!!
with all due respect this article is full of nopes!.

why do you insist in try to make your own templating happen, it's not goint to happen, razor was a good idea at the beggining i swear. but i dont use strongly typed views anymore, and there's no way im gonna change to use asp-validation or any other private meta-tag when i can use a fully stack javascript framework like angular/knockout JS.

This is what i use in .MVC so far
Session for user credentials management.
Filters for error handling, authorization, etc...
Routing

if not by these 3 last featuers, i would definetly changed from MVC to NancyFx as my default coding framework.

Regards

Carlos Bolanos - Tuesday, February 24, 2015 2:10:42 AM

@Carlos

DON'T USE THE TAGS!!

people are already bitching on optional tools....

Alex - Tuesday, February 24, 2015 2:50:52 AM

Fantastic. The dynamic development is something I was just wishing for this afternoon. Couple that with the other new features and I'm impressed.

@Carlos - You mean to tell me you're not using private meta tags with angular or knockout? I'm impressed.

Adam - Tuesday, February 24, 2015 3:47:46 AM

Carlos/Alex, the tag helper functionality is full opt in. And we are working on a set of the tag helpers that light up Angular JS functionality. You get a first time server rendering and then Angular JS runs on the client after that. One of our goals moving forward is make it easier to build client side apps.

Scott Hunter - Tuesday, February 24, 2015 3:59:20 AM

Love the DI and configurable pipeline, it would allow to trim lot of extra noise.
Thank you!

Rizwan Ahmed - Tuesday, February 24, 2015 4:12:24 AM

Scott - That first time server render + Angular light-up sounds great, but will it be tied specifically to Angular? Or will this work well with Knockout (or others) as well?

Brandon Paddock - Tuesday, February 24, 2015 7:19:18 AM

There is no mention of anything to do with Web Forms. When will we be able to be use it cross platform?

Stuart - Tuesday, February 24, 2015 8:35:33 AM

I love this and I've been using Visual Studio 2015 and noticed it blows up when using Grunt (well really Node) due to this https://github.com/joyent/node/issues/6960

Scrambledheads - Tuesday, February 24, 2015 9:41:48 AM

This is awesome. ASP.NET with MVC and WebAPI makes developing a solution set so much easier. Making .NET cross-platform with 4 makes it even more appealing. Go MS!

Sanjay - Tuesday, February 24, 2015 11:20:33 AM

Looks very nice. I have some old asp.net 2.0 (the horrors!) projects that I have to update. I was thinking either using 4.0 or switching to Python/Flask. The cross platform option is promising.

Jon - Tuesday, February 24, 2015 12:11:36 PM

ASP.Net development team improve the structure of language and give more flexible features to developer but I think their should be some standards through which quality of application should maintained. If Developer A use json other use xml other use abc, every body will build their own standards and that is totally mess up with standard.

Khuram Shahzad - Tuesday, February 24, 2015 12:14:14 PM

ASP become more and more complicated. At the time of ASP 1.0 you just write code inside HTML and you DEFINITELY KNOW what will be on your page. Now all those frameworks / hidden helpers make me lost in my own code! This is not a progress, but rolling to the mess: after 5 years MS again will say: "Oh, it was so complicated, we developed NEW framework - QWE 2.0!". Be sure, it happen.

Thorn - Tuesday, February 24, 2015 12:28:19 PM

Fantastic....Love ASP.NET even MORE...Thanks for Dynamic Compiling....Great Job..

John Stephen - Tuesday, February 24, 2015 12:48:13 PM

The only part of this that even remotely interests me is running it on Linux/OSX. That said, even if this works, what is next for ORM ? ie. Where is EF support right now for Postgres ?

MS is so far behind - moving at a snails pace. Fantastic to have 'intellisense' for bower, but really - like, look at your competition - Ruby on Rails has solid Active Record. Django has solid ORM. Laravel has solid ORM. All of them let you run TODAY on multiple database backends - able to run anywhere with tools out there to do it. (Heck, the VS tools for Python are miles ahead of your own).

Meanwhile, we are on version 5 of asp.net and it has a suspect EF that continues to focus on MS SQL only. Last time I checked cloud costs, it's double to run an app on Windows vs. Linux - on your own cloud platform.

So again - congrats on this IDE, but I think you guys are missing the target here. I *want* to believe, but honestly we been evaluating other solid web frameworks that support Postgres, etc... for performance, ease of deployment, cost savings, etc...

Kestrel is the best idea yet, but what good is a fancy web framework that can't service the database we use when we run it on nginx linux box ?

Steve - Tuesday, February 24, 2015 12:58:17 PM

"One of our goals moving forward is make it easier to build client side apps." -- said Microsoft since killing Silverlight-- easily their best client-side technology -- in 2011. Now we have to put up with things like "Grunt" and "Gulp" ... makes one wonder if they are coding or are starring in an adult film.

Good thing CSHTML5 is on the way so we can start coding real client-side applications again. Microsoft should buy it outright and dedicate a division to making it great... sort of like what they should have done with Silverlight in 2011.

cshtml5.com

ASP.NET5 team should stick to the server where they (really) know what they are doing.

Jaded - Tuesday, February 24, 2015 1:05:19 PM

So does this mean ASP.Net WebForms is dead? That would be a damn shame as I support several enterprise applications built on WebForms and continued development is always a good thing.

Payton Byrd - Tuesday, February 24, 2015 1:08:56 PM

Brilliant stuff, guys. Love, love, love it.

bill - Tuesday, February 24, 2015 1:16:11 PM

This looks outstanding! I love the attribute replacements for Razor syntax; it fits nicely with the way other frameworks are defining their stuff, and makes it where you don't have to pass a huge array of custom attributes as an anonymous class to @Html.TextBoxFor (for example). Nice!

In one of my other lives, I do development on a machine that cannot access NuGet (yay network restrictions). Will there be any sort of sanctioned work-around to allow us to build Core applications? My current work-around is to have a web app project on another machine that pretty much just has NuGet packages installed. When I update it (or install a new one I realize I need), I then go to the local NuGet cache and burn the new packages to a disc. Then, I copy them to a local directory on the computer without NuGet access, and have a custom repo pointing to that folder. It works, but it's not terribly great for productivity, as once I realize I need another package, I won't be able to get it until at least the next day.

It sounds like this process might work; I'd just need to make sure that I made a new fake project that had all the relevant packages, so I'd get them in the cache to be burned.

Daniel - Tuesday, February 24, 2015 2:11:09 PM

I haven't seen much beyond what is shown here describing dependency injection in asp.net 5. Are the unit tests in the github project pretty much it for now?

Glenn - Tuesday, February 24, 2015 2:31:09 PM

Longtime web developer here, having built numerous apps with the MS stack. I run a startup also running on the MS web stack.

Just wanted to say, ASP.NET 5 is friggin' awesome! I'm really excited about this release and looking forward to using the new bits when they're stable.

Judah Gabriel Himango - Tuesday, February 24, 2015 2:58:39 PM

Maybe I'm being daft here, but even after looking over the docs for both the @import keyword and the view components stuff, I still don't get the value of dependency injection into a view. I was always taught to put as little logic as possible into views. Has that guidance changed or is there something I'm missing here...? I can't imagine something like that being engineered to that degree without a good reason - it doesn't seem like an accidental feature. So, what's the idea behind it?

Will Gant - Tuesday, February 24, 2015 3:28:41 PM

Meh... I will stick with Python and Flask. Cross platform and much more flexible.

Don Joe - Tuesday, February 24, 2015 3:38:26 PM

ENOUGH already!

The world does NOT need any more web software. Just QUIT!

If you still feel compelled to stay in the software world go design a Deep Mind like interface to allow true speech to text / text to speech that can be used as a universal teaching platform. Want to make the world a better place? ELIMINATE the cost for education by using your high tech skills to build "Socrates -- The World Teacher". Not some more useless web glueware that NOBODY needs.

Anonymole - Tuesday, February 24, 2015 4:11:44 PM

looks more and more like Angular JS

buju - Tuesday, February 24, 2015 4:45:47 PM

Grrr.... I meant to say I looked over the docs for the @inject keyword and couldn't figure out the point. I understand @import just fine.

Will Gant - Tuesday, February 24, 2015 4:55:00 PM

Please make security opt-out, not opt-in.

Security should never ever be opt-in

Chris Marisic - Tuesday, February 24, 2015 5:09:36 PM

@Will Gant

Using the example of TimeService it would be equivalent of

public HomeController(TimeService timeService)
{
ViewBag.TimeSvc= TimeService = timeService;
}

And in the view doing

((TimeService)ViewBag.TimeSvc).Ticks

Chris Marisic - Tuesday, February 24, 2015 5:15:56 PM

Right, that's the thing. I don't see what this gets me that isn't already available in the existing structure, plus as a rule, I try to keep interactions with other classes to a bare minimum inside my views. So I probably wouldn't call a service directly from the view anyway. I would have a view model that has whatever results on it that I want to use, and load it from the controller.

I guess the thing I don't see is what this gets me that isn't already provided by the framework. All I can see it doing is resulting in more logic inside views, which is probably the last thing I want.

Will Gant - Tuesday, February 24, 2015 5:34:03 PM

Scott, this is all great, well done to the team for all your work on this.

I have a question about the hosting options, we all hear that IIS is not required any more however I am not clear what the advantages are of not hosting in IIS for production code, I get that not using IIS in dev and test can make things simpler and quicker but surely IIS offers a lot of features that are not available when self-hosting.

I also think deploying web applications outside of IIS will cause a lot of difficulties for Enterprise customers who had SysAdmin teams who look after IIS. When web applications can be anywhere this may prove difficult to support.

I would love for someone to blog about where IIS fits into this new world and also what do we need to do to IIS to get it to work with these new projects ? The IIS website http://www.iis.net is devoid of any information on this.

Thanks
Carl

Carl - Tuesday, February 24, 2015 6:00:11 PM

Is System.Web not always loaded in memory when using IIS, since IIS in the integrated pipeline also supports HttpModules (for which at least the interface definition is loaded from System.Web)? Or is the performance impact of IIS and System.Web itself in this can negetiable?

Sebastiaan Dammann - Tuesday, February 24, 2015 6:07:43 PM

Hi Scott,

What do you mean exactly by saying this...

"ASP.NET 5 is an open source web framework for building modern web applications that can be developed and run on Windows, Linux and the Mac."

Specifically the part about developing on a Mac.

Are you indicating Mono here?

Kid - Tuesday, February 24, 2015 8:15:54 PM

:D

Jack van Noppen - Tuesday, February 24, 2015 8:21:05 PM

@Kid,

No, as part of the move to Open Source, they are planning on developing a version capable of being used on both Linux and MAC OS X (I believe that is what Scott indicated). They have also indicated that they intend to work even more closely with the Mono team.

M

Mark - Tuesday, February 24, 2015 8:33:13 PM

OK Great, I feel bad, Scott deserves better than to be asked such a question. I wish I could have stayed with Windows after over 20 years of dedication but my Mac is a far superior option for me at this time. So now that battle is over, and my platform changed... I would do anything I could to run Visual Studio on my Mac. XCode is hot on the heels with an incredible offering that looks so promising. I really hope Gu can bring something to the Mac table soon before I am totally swept away by Swift.

Kid - Tuesday, February 24, 2015 9:19:20 PM

Greetings.

I'd like to see an example of authentication that doesn't inply entity framework.

Where can I see one?

adrianlmm - Tuesday, February 24, 2015 10:32:58 PM

@scottgu,

My biggest grip so far, with the introduction of the new client-side tooling is that the task runner only works in VS proper. To get a build server, say TFS build to do the same thing is a VERY sad story, throw Git on top of it and you'll never want to use TFS again, ALM or not. Everything seems like it was spot welded, or duct tapped into place, and was an after thought. Heck Git pulls was just introduce in update 4.

Stephen Patten - Wednesday, February 25, 2015 5:51:13 AM

good!

蟋蟀 - Wednesday, February 25, 2015 7:33:25 AM

Tag helpers and [Activate] attribute - really helpful features indeed!
Great job!

Rex - Wednesday, February 25, 2015 8:23:01 AM

I am with @Anonymole on this.
Enough is enough. Actually, I am quite happy with .Net 3.5. There is one need, that seems to be overlooked in general, and that is speeding up the developer her/himself. It is more the user experience which needs improvement, more that the background technology. That is also currently the goal for the few applications I write these days: Improving the user's experience, making the user work faster end concentrate on the main goals.
With all this new stuff, I wonder how it all will look in 10 years. Will there be more Gulping? Will we be even more Grumpy?
And opensource? Did I read that correctly? Shudder..
-Ingvar

-Ingvar - Wednesday, February 25, 2015 8:59:18 AM

ASP.NET moves in the right direction. But it's moving to slow. Without EF MVC6 is nearly is useless.

I tried to edit a MVC Controller file and saving => instant crash of the debugging session.

When ASP.NET+MVC6+EF7 will be ready for production (at the end of the year?) there will be much better frameworks which simplify client/server programming such as Angular2+some client/server backend.

All the ASP.NET features come to late.

Daniel - Wednesday, February 25, 2015 10:39:39 AM

I'm really glad to see .NET officially come to platforms other than Windows. Unfortunately I don't see the same strengths in ASP.NET as I do in many other web frameworks for other languages. Most notably any based upon Symfony's HTTP Foundation library. In ASP.NET, routing is still quite strange and verbose, and the technical decision making for the framework's design is just a little troubling at times.

While I'd absolutely delight in being able to write web apps in C# instead of OO PHP, having .NET on all platforms is still only half the battle. Now we need better libraries.

Alex - Wednesday, February 25, 2015 1:04:00 PM

I did notice no mention of web forms and nothing about support, or lack therof, for VB.NET

I read the following blog post about no more web forms and no more VB.
http://stephenwalther.com/archive/2015/02/24/top-10-changes-in-asp-net-5-and-mvc-6

Is this accurate? If it is will Microsoft be releasing an official statement on this? My company has a huge code base of web forms and VB.NET so knowing Microsoft's official stance on their support for VB.NET and web forms would be nice to have sooner rather than later.

Darrell - Wednesday, February 25, 2015 2:05:49 PM

One thing that isn't clear to me is with using razor with '@' variables and how that will be translated into this new semanticaily-inflected attribute based markup. I get it, I love it, but how are variables translated here? In frameworks like Angular (and with 2.0) I believe they are introducing "#" variables within markup.

I there an equivalent for this new unified programming model? Just curious to know.

Mike - Wednesday, February 25, 2015 4:26:09 PM

Anyone know if there is any truth in Darrel's comment above? , is VB.net getting fazed out? I also use web forms as I hate MVC.

Dave - Wednesday, February 25, 2015 4:47:43 PM

"You can now return Razor views and content-negotiated data from the same controller"
Does this mean it can act as a replacement of WebAPI ?

sark - Wednesday, February 25, 2015 7:08:21 PM

I've seen Kestrel for running a basic web server with vnext, but are there plans to have an Azure emulator that runs on other operating systems as well?

Thanks,

Corey

Corey - Wednesday, February 25, 2015 10:35:38 PM

This is a huge step for .NET community. Can't wait to get started with MVC 5. Thank you Scott and the amazing .NET Team.

Faraz - Wednesday, February 25, 2015 11:11:07 PM

"Waaah, I don't like new stuff because my job entails maintaining 14 year old Contact Us pages in webforms with VB.net. Waaaaaah, a whole company won't design their entire toolset around my soon-to-be-offshored job responsibilities and fear of new syntax characters."
- half of the commenters in this thread

hngh - Thursday, February 26, 2015 12:28:28 AM

@hngh

Such a typical arrogant response.

We have a 10year old code base, hundreds of thousands of LOC, with hundreds of vb.net based web form user controls. So if i want to support ASP.net 5, i should be forced to rewrite my app from scratch to using the latest fad.

Tim - Thursday, February 26, 2015 3:27:59 AM

Thanks Scott. I very like unification of Web UI - Web API and support for DI.

Tung Nguyen - Thursday, February 26, 2015 4:26:29 AM

AngularJS?

Subseven - Thursday, February 26, 2015 7:31:49 AM

I liked how this article summarized all the new features and ofcouse, the new features themselves!

Ibrahim Islam - Thursday, February 26, 2015 8:00:56 AM

@Darrell Web Forms won't be supported in ASP.NET 5. This is official and has been announced a long time ago. It also makes sense since technically Web Forms is very tightly coupled with System.Web and System.Web is precisely what is being replaced in ASP.NET 5.0. Web Forms will still be supported for some time (probably quite long) including new features in the form of ASP.NET 4.6 but do not expect the benefits of ASP.NET 5.0 including Linux support and save/refresh dev cycle.

Stilgar - Thursday, February 26, 2015 8:42:10 AM

@hngh

I work for a very large well know company and we use web forms still, just seems cleaner to me than MVC.

David Warner - Thursday, February 26, 2015 9:13:44 AM

Hi
i am working wordpress , believe it very simple............................

marcus - Thursday, February 26, 2015 9:31:17 AM

Love what you guys are doing! Though, I see NuGet package hell coming up after System.Web is left behind, but developers got what developers asked for :)

Engineers, please don't sleep while changes are happening. I don't like to see custom replacements for standard Microsoft packages which are not thoroughly tested or smell like licensing issues.

Nikola Radosavljevic - Thursday, February 26, 2015 9:56:29 AM

'Build and run cross-platform ASP.NET apps on Windows, Mac and Linux' - will we be able to run ASP.NET apps on an iOS device (without VS)? Of course that would need some sort of client web server?
'Single aligned web stack for Web UI and Web APIs' - wasn't this the promise of Web API?
'Built on .NET Core' - there are breaking changes with this and I can live with that, but is this just so VS will run on Linux and Mac, because if it is, this is another Silverlight debacle?
Sorry for sounding cynical but I can't afford to get burned again.

Rod Mac - Thursday, February 26, 2015 1:50:33 PM

I'm just trying to understand it all in order to make decisions for our company moving forward. We already have planned to move some things to asp.net mvc but not way we can just plop it over there. And getting rid of VB.NET in asp.net 5, if that's true, is an even bigger shift. Not in the ability of developers to learn but we may have to maintain our webforms/vb.net site and have a site running alongside it in mvc/c#

Darrell - Thursday, February 26, 2015 2:24:22 PM

Please rename Visual Studio to JavaScript Studio...

There is nothing more "Visual" ...

memosk - Thursday, February 26, 2015 2:50:49 PM

no support for Web Forms . Imagine a large scale data intensive system with 3k+ stored procedures, implementation with MVC :)

ZeeTech - Thursday, February 26, 2015 3:07:36 PM

Why is Dynamic development only available when starting the project without debugging? Surely, I can change my code now and simply hit refresh, but what good is it without being able to set a breakpoint and debug?

Vladimir - Thursday, February 26, 2015 3:48:34 PM

@Stilgar save/refresh is working in Web Site from Asp.net 2.0 )))

Igor - Thursday, February 26, 2015 4:52:02 PM

For the folks asking about Web Forms. We will continue to invest in that space. We are adding suppport for Roslyn which means Web Forms will get access to the newest C# and VB features. We are adding support for HTTP 2 to System.Web. We continue to take MVC features and port them back, in this case we are taking async model binding and making it available in Web Forms. Our goal always has been to try and keep the various web models equal in feature sets.

Scott Hunter (MSFT) - Thursday, February 26, 2015 6:28:33 PM

I saw a couple of questions about Entity Framework. If you are running ASP.NET 5 on .NET 4.6 you will be able to use EF 6 in its full glory. We also have a new EF 7 that we are making available that works on both .NET 4.6 and .NET Core 5. Internally we have called this EF Everywhere because it will also be able to run it on Phone and Store apps as well. This version of EF also is going to let you talk to NoSQL scenario's like Azure Table Storage.

Scott Hunter (MSFT) - Thursday, February 26, 2015 6:31:49 PM

Is System.Web also loaded when running under IIS? We put hooks in System.Web a few versions ago to let it load a different base framework and this is how we host ASP.NET 5 on machines that have not been configured to run ASP.NET 5. We do have a native IIS module for loading ASP.NET 5 applications and when it is installed we will boot up the application without loading System.Web into memory which saves around 20MB per website.

Scott Hunter (MSFT) - Thursday, February 26, 2015 6:36:35 PM

I know that ASP.Net vNext has web forms support but where is a good place to get an idea about the future of web forms? The more blog articles I read the more I think I need to make the move to MVC. I noticed that the current MCSD paths are for MVC and nothing for web forms, unless I am looking at it wrong.

Thanks, and good work on everything so far, I'm excited about it.

Jason - Thursday, February 26, 2015 6:45:10 PM

Holy guacamole ... ! Can't wait to start using all that goodness!

Darek - Thursday, February 26, 2015 11:10:34 PM

The application cannot start! is this the best you can do Microsoft ???

Loren Lowe - Friday, February 27, 2015 1:01:52 AM

OK, credit where credit is due:

Unified MVC/WebAPI model: YAH!
New HTTP pipeline: YAH!
Open Source: YAH!

Great additions. If I could request one more -- now that you're disconnecting Razor from WebPages entirely (or so it seems), can you please do something about the abomination that is the fact that Razor renders partials/layouts/etc into a nested stack of StringBuilders and only flushes to the response at the end. WHY GOD WHY!? Can you please just have everything write directly to the single underlying TextWriter without the unnecessary allocations in between?

As for the rest.....

Does anyone remember when Microsoft re-branded Windows as "Microsoft .NET Server" because that was all of the rage at the time? Welp, this is the ASP.NET team jumping that same trendy shark. Not all of us want to build our web-front ends using whatever the latest JS framework fad is at the moment. I get embracing these things and making VS work well with them, but throwing away a ton of stuff that just simply isn't broken?

Dynamic Development:
This sounds great in theory. However, we have an incredible amount of tooling that runs at compile time in order to code-gen a bunch of really critical stuff. As an example, we generate strongly typed helpers for all of the content files in the site (so as to avoid magic strings in view files to reference resources). We also code-gen strongly typed view "helpers" that eliminate the usage of magic strings to refer to view files. Lastly, we code-gen strongly typed "controller" helpers so that we don't use magic strings when referring to routes or generating URL's back to our actions. This suite of stuff is similar (I believe) to some of the T4 MVC templates, but tailored to our needs. In this "no-compile" world, how do we get that stuff to run?

JSON Project File:
See above -- we have a ton of tooling tied to MSBuild that does our code generation. These are all implemented as MSBuild tasks, and figure out what they need to do by parsing the CSProj file (i.e. the view generator looks for *.cshtml in the project file). These are also optimized so that they only run when they need to -- this functionality is built into MSBuild, and it's actually quite good at that. What becomes of all of this? In addition, I don't see explicit references to source files, etc in the project file. Is that going away? I ask because that's the equivalent of <Compile Include="**/*" /> which is always a terrible idea (as an example, if you unshelve a shelveset and then undo it, the "adds" from the shelveset aren't deleted on disk, and if you're just compiling everything you find on disk, well, you'll have a pleasant surprise).

Simplified Dependency Management:
Oh really? Is that what you call the cluster**** of client side libraries that get added when creating an empty empty project in 2013? You know what's really simple? I have a bunch of internal binaries we need -- either stuff we don't include in the solution because it never changes, or 3rd party libraries that we've modified and recompiled for our needs, but again, which doesn't get rebuilt often (if ever). I reference them by pointing at those DLL's. Done. I don't want nuget shoved down my throat. My dependencies are fixed and do not change unless we make a conscious decision to do so (and plan ahead for all of the testing that involves). Don't take DLL references away and force nuget. Don't do it. Please.

Bye bye Web.config. Hello JSON:
Why!? Simply because JSON is in vogue? Again, what of all the countless tooling that's tied to Web.config? As a simple example, how the hell do I change the machine key so that it's the same across all of my instances in Azure? As another example, we've extended Razor quite a bit to add new directives and such. The work required to get custom Intellisense for this in Visual Studio was basically nil: create a custom Razor host, set its type in the web.config file, and because VS reads stuff from there, BOOM -- "it just works". I'm fearful this will no longer work.

Seriously guys, I commend your efforts to appeal to the shiny client-side of things, but please don't forget that you have a HUGE body of the people building professional software who don't care about any of that stuff. Please, please, please think through which of our scenarios (which have work FOR YEARS) you're breaking in your quest to have the node folks let you in the cool kids club.

A guy - Friday, February 27, 2015 8:48:29 AM

ASP.Net Rockssssss

Pramod Nair - Friday, February 27, 2015 10:04:55 AM

ASP NET is excellent opportunity to create NEW WEB FORMS !!! This time without ViewState, complex machinery etc. But of course you must retain event model, control's hierarchy, graph, unique ID's, mixing HTML+controls's tahs. And support VB, best language for .NET.

Tristan - Friday, February 27, 2015 2:34:35 PM

Hi Scott. Great stuff! I added an important word to your sentence: "ASP.NET 5 is an open source web framework for building modern, localized web applications that can be developed and run on Windows, Linux and the Mac. ". How is the localization story going to look like in ASP.NET 5? It's still absent in CTP6 and no one seems to be asking for it? Regards

Peter - Friday, February 27, 2015 3:01:48 PM

@Scott: Today when I publish my website, the publishing-process takes my production website down for a long time :( ... will ASP.NET 5 make publishing faster, so my production website is not down?

Morten - Saturday, February 28, 2015 9:49:26 AM

Hi Scott
Thanks for a nice article. It's exciting to see all the new modern changes in asp.net. However one thing that is lacking behind very much is the ability to make multi language / lingual web sites. At this area asp.net is very far behind with its resx technology. Improvements are very much needed in order to make MultiLingual web sites a realistic goal when developing asp.net mvc web sites.

Mohammad - Saturday, February 28, 2015 3:04:32 PM

Scott or anyone in the know, can you comment on the questions about MVC 6 not supporting VB.NET as indicted by Stephen Walther's post? Aside from the rather insulting post he made, several people have asked about it here and elsewhere with no answer. VB.NET got left behind with the templates but is it being completely dropped somehow? What's the plan for VB.NET and MVC (templates and all)?

Chris - Sunday, March 1, 2015 9:22:02 AM

I know what's missing here. Like W10 distances itself from W8, i.e. it's going to be an awesome OS, so VS vNext needs to be awesome. Here's my whacky idea to pull this off. .NET with the simplicity of WinForms and WebForms was awesome back in .NET v1.0 days (2000). So, create a SINGLE control set that streams as Universal (XAML apps) on Windows devices or outputs as HTML5 & javascript on non-Windows devices.

Simple!

P.S. all this stuff about Grunt and Bower and Nugget is doing my head in. It's Visual Studio and .NET, right?

rod mac - Sunday, March 1, 2015 7:56:11 PM

There is some great stuff here and reading through the comments of people slamming the tags and EF. what? The tags are serverside and the code hit returned to the client will be the html and not the tags and feels more natural to the language than the @Html helpers.

EF is definitely not MS only we use it daily with Oracle and they have just released there own driver capable of code first and migrations.

The biggest thing for me is getting used to grunt and how to effectively use it to make my life easier.

Gruff - Sunday, March 1, 2015 10:39:38 PM

tnx a lot.

لوازم جانبی موبایل - Monday, March 2, 2015 6:09:07 AM

Nice article. Looking forward to work with ASP.NET 5.

SelectPdf - Monday, March 2, 2015 1:40:02 PM

I want to congratulate the entire .Net Team! I am sure this version is going to be awesome.
I've never been so excited with ASP.NET, seriously.
Thanks a lot Scott! :)

Zadi A. - Monday, March 2, 2015 2:42:42 PM

Misc thoughts. Merging MVC and WebAPI is a logical step. Too late indeed, but a good one. These are the main components of most nowadays web-applications, so they deserve much attention. But a lot of other stuff is mostly irrelevant. Frameworks should be basic, easy to grasp with a learning curve as low as possible. Small improvements are nice (like the tag-helpers), but they solve a very small issue, yet require one to spend time to learn how it works. This is exactly why so many people fancy stuff like MongoDB, NodeJs, etc.

It's good to see continuous investments into ASP.NET, but I'm not as enthousiastic as with big releases in the past.

Robert - Monday, March 2, 2015 6:26:45 PM

ASP.NET 5 and MVC6 look fantastic, looking forward to the finished product to start building some production apps.

Can anybody confirm my understanding, that when running ASP.NET 5 we lose the dependency on System.Web as long as the server has been configured to run ASP.NET 5 - And this is true whether running on .NET Core OR .NET 4.6 when writing MVC6 (MVC + Web API)....or do you need to build on .NET Core to lose that dependency on System.web

If you were going to build a new Web Forms app, you can run it on .NET 4.6 and retain the dependency on System.Web - When using WebForms will we lose some of the specific ASP .NET 5 features like the dynamic compilation, Bower support, and other things specific to ASP.NET 5.

I favour MVC, but sometimes use Web Forms, both for legacy apps, and on occasion for new projects, it's easy to see how Web Forms doesn't really fit in with the new ASP.NET 5. Those who use web forms as their default preference still have the ability to do everything they did before, and with new additions like Async model binding should be happy imo.

Daniel - Tuesday, March 3, 2015 2:38:50 PM

VB.Net is extremely powerful and easy to learn. Introducing new 'stuff' based solely on C# only will hinder new & young coders from adopting the technology. I know a bunch of home-schoolers who can 'read' VB.Net and understand it. When I show them C# or Javascript they don't like even looking at it because of the 'squigglies' and lack of descriptive words. It's not intuitive to them. It IS intuitive to people who have been around coding for the last 30 or 40 years and have people convinced that squigglies and symbols are superior to words.... almost reminds me of the smugness of the Unix guy on Dilbert, "Here's a nickel, Kid. Get yourself a better computer." I think it also helps put a wall between the coders and the users -- because then only the coders can understand the code (job security and fear?).

I tried MVC and ASP.Net Identity with VB a few times but, always quit using it because of lack of documentation. Stephen Walther made comment of "the 2 people" (on the planet) using VB and MVC -- there would be greater adoption if the examples and support were equal to C#. I really have a hard time understanding why people would choose C# over VB (some vehemently based on the comments above). Many Squigglers (C#) seem so dogmatic and closed-minded on the superiority of their choice in code -- I just don't understand why. With this latest announcement that ASP.Net will be native in C# only, I am sad that MS is perpetuating the stereotype. You can't choose 1 language over the other and then say that the goal is for them to be equal. VB seems to always be treated as an afterthought -- Oh yea... we need to add this stuff to VB as well. It's not just the features that are important -- it's the documentation and examples that are KEY.

This blog comment borders on daring to comment on someone's religion so, I better stop here!

Scott,
Is there a way that the VB community can work with the development of vNext? I was given very good advice: start a thread on the ASP.Net GitHib forum. If the VB community works together perhaps we can help get VB and Webforms native to ASP.Net 5.

Terry - Tuesday, March 3, 2015 2:42:11 PM

Hey Scott et. al,
Is there any comment on the continuity of LINQ to SQL? As much as I can appreciate EF, I have found it clunky and just like using LINQ to SQL more, extending the models in the partial class files. I don't, however, wish to start new projects using a technology that might lose support.

Kyle - Tuesday, March 3, 2015 8:33:40 PM

@Terry , well said and I working with kids to bring them into engineering VB has been great to get the next generation of engineers excited and not frustrated.

warrenB - Wednesday, March 4, 2015 8:32:52 AM

Scott,
I"ve been a web developer since 2000. I followed the whole .NET path, Visual Studio upgrades but i'm thirsty for ONE thing. At the end of the day aren't we concerned about the performance of the page with a page/sec output of the eventual HTML on the page (disregarding DOM ready). You work for any company you just get professional. Visual Studio Test as a developer would do what I need (i've never used it) but day to day why we using Glimpse, trace, action() => stopwatch just to profile our code? Can we have through web essentials or Visual Studio itself a URL (no configuration). You know a manager is going to ask, how will it help me? I can show report, previous X page/sec, now X+100 page per second.
GP
Ps. now I have to find new things to say in interviews about removing windows,passport modules in the pipeline. Or I could turn it around say why we should go MVC6.

GP - Wednesday, March 4, 2015 1:32:43 PM

@Terry I can understand your frustration if you primarily / only use VB.NET for your development at the moment, but I think it makes sense for VB not to be a priority for ASP.NET 5. You mentioned that many home-schoolers who have liked / can read VB haven't liked C# or Javascript because of their syntax.

The ASP.NET 5 release is aimed at modern web development, which these days does include more and more client side code with Javascript, without a doubt. So web developers are likely going end up writing some anyway. I think for those wanting to stay away from JavaScript and it's syntax, something like Web Forms is well suited, as you can use the Ajax Control Toolkit to enable client side functionality whilst writing very little to no JavaScript and still able to use VB.

I appreciate Web Forms has a number of downsides, and some people just plain don't like it. But I see no reason why you couldn't continue using the current version of MVC and continue to write in VB. Yes you would lose out on newer features, but that would be something to weigh up going forward.

VB.NET can still be used in existing technologies / versions of technology and there wouldn't be a requirement to move to the latest version if it doesn't offer what you need. That's all just my opinion, I'm sure that if it was C# that wasn't getting included I would be up in arms myself, so I get where you are coming from.

I don't think developers wanting to write in C# is anything to do with fear of job security, because there's a lot more to it than just being able to read the code. Reading something that is more 'Wordy' may sound easy, but actually understanding why something is built the way it is, and the patterns implemented etc is completely different. You wouldn't want non-coders trying to interpret the code and make potentially dangerous changes in reality.

Other advantages I can see to sticking to a single language initially is removing the need for samples, documentation and new features to be created/implemented multiple times. Allowing for more time to add to the base feature set and improve what is available in .NET Core - At the moment there is no equivalent of SmtpClient and other useful classes (That I have seen) so there's plenty to be done still, if this gets added to the core at all (Not sure if the idea is to offload this work to services running a beefier version of the framework).

If enough people want to bring VB support to ASP.NET 5 then I'm sure it could happen in the open source community like you have asked.

Like you, I don't want this to be interpreted as similar to an attack on somebodies religion, and I don't agree with the people who belittle developers just because they use a certain language, so I'll also stop at this point.

This is all my opinion, and overall I think there are still many options for those wanting to write VB.NET code on the desktop, server and web if they wish.

Daniel - Wednesday, March 4, 2015 1:32:48 PM

@Kyle Is there any comment on the continuity of LINQ to SQL?

We've been recommending EF for new development for several years now. See https://msdn.microsoft.com/en-us/library/ms178359(v=vs.110).aspx#orm For new development where you're not constrained by a legacy data access approach, Microsoft recommends the Entity Framework.

rick anderson [MSFT] - Thursday, March 5, 2015 12:00:42 AM

Could Anders Hejlsberg please take TypeScript to a new level so we can code in C# and TypeScript spits out all the JavaScript embracing all the JSON, Angular, Grunt, Bower stuff, the prospect of which is making me rather ill. Thank you.

Rod Mac - Thursday, March 5, 2015 11:26:50 AM

No VB if true is a killer for me, I have had jobs working with C# and I can code with it, that's not a problem, but I love vb.
I have been using Microsoft Technologies since before the internet days, I was there when VB was new, I think it is the cleanest and best lingo to code in, I simply am not going to enjoy my job as much without VB.
It true I am very disappointed.

Alan Mosley - Thursday, March 5, 2015 4:52:34 PM

@Terry I don't think VB.Net or .Net in general is something home schoolers should be learning, you are teaching them to drive a truck before they can ride a bike. I would go with http://smallbasic.com/ for teaching less than university/college level students.

Craig - Thursday, March 5, 2015 10:06:40 PM

Lets see how Microsoft is going to embrace open source, becauseit has been proven that .NET team cant cope with the changes in time.

You are releasing ASP.NET5 with features from 2009, from other langs and frameworks.

I hope that you can really embrace opensource and stop centralizing development. +1

Rgoytacaz - Friday, March 6, 2015 4:05:44 PM

It looks like there is a bug on the asp.net website. It shows that this article was published today, where in fact it is from the previous month.

Grunt - Saturday, March 7, 2015 1:31:19 AM

I just hope asp.net will take client programming as important as server one, some way to integrate better between MVC/VS IDE and angularjs.

nam vo - Saturday, March 7, 2015 4:21:56 AM

All the examples seem to demonstrate how tightly coupled asp net 5 is to Visual Studio, despite the text saying its not. The article should be about asp net 5 but it seems to illustrate the features of Visual Studio much better.

For example, I get from the text that I might use Grunt to manage my build, but the article shows using Visual Studio to manage Grunt! Why not just use Visual Studio's build chain? If I can use Grunt instead of Visual Studio for my build chain then showing it might have been a convincing benefit for lots of non-Visual Studio developers.

Brian Lowe - Monday, March 9, 2015 12:35:57 PM

Scott,

Sounds like a lot of really great stuff. Not sure if anyone has asked this yet or not, but I am wondering what features will be in what versions of Visual Studio? I work at a smaller company and it would be nice to get all this great stuff and not have to pay 30k per license for all the good stuff!

Thanks,

Jimmy P.

Jimmy P - Tuesday, March 10, 2015 12:17:23 AM

Hi scott,
With this release of ASP.NET (and others e.g. EF), please please pretty please, build these frameworks with interfaces.
It's quite remarkable considering that .NET application development is just full of the bloat that is interfaces as their daily practice, when the rest of the world (e.g. J2EE) has moved on and views interfaces as an anti-pattern (DRY violation). The only place where interfaces should be used is in a framework or reusable API, which is also the only place where you don't get interfaces in .NET (EF, ASP.NET MVC, WebApi). Couple that with the fact that nothing is virtual (because of c# default), we get brick walls that's hard to work with.
As a rule, if anything in the API of the framework is not proxyable, it should be a bug. It makes it hard to use that with application frameworks that rely a lot on proxies

Hendry - Tuesday, March 10, 2015 6:30:30 AM

The only improvement I see here is the cross-platform .NET Core. Everything else is just a waste IMO. There was no need for it at all.

Tag Helpers - No benefit
Eliminating the need to store settings in web.config - No benefit
As well as 90% of the other stuff.

I think MS just introduces change so the MCSDs will need to get recertified. $$$

KJ - Tuesday, March 10, 2015 12:59:27 PM

If no VB is true, it is going to make me not want to use your product at all. After 30 years of coding in VB, it’s going to be hard for me to switch and we just got done writing all our WEB API libraries in VB. I think the developer community is going to lose some good analysis over this,, it will hurt for awhile. I just feel a little betrayed after sticking with you guys for so long. Tell me it isn't so Joe.

John - Tuesday, March 10, 2015 1:43:16 PM

Hi Scott,

I am a teacher for apllication developers. Our students are mainly free to choose the language they want to program in. The languages which dominate are C#, PHP, C++. I would like to teach them also ASP.NET MVC from now on. I myself have worked with ASP.NET a long time ago. Because I don't want to teach them stuff which is old-school, I would like to start my student fresh with the newest technology. Therefore I would like to know if there are courses, lessons for our school we could use to teach our students.

Thanks,

Lormic

Lormic - Tuesday, March 10, 2015 2:57:39 PM

Those are the features expected for modern and open web dev for a long time. ASP.Net is really catching up now. So excited for the coming of official release!

Hunter Wei - Wednesday, March 11, 2015 4:04:59 PM

Dear Sir :

I've translated this GREAT article to Trad. Chinese.
Thanks for your kindly sharing.

http://www.dotblogs.com.tw/mis2000lab/archive/2015/03/11/aspnet_5_introduce_scottgu_20150223.aspx

mis2000lab - Thursday, March 12, 2015 6:20:28 AM

VB.NET is much easier to read, code and maintain than C#.
Not supporting VB.NET in ASP.NET 5 is a major mistake.
Someone suggested renaming VB.NET to B#. That's a good idea.
Microsoft should decide NOW that it is committed to absolute parity between VB.NET and C#.

Mark Century - Sunday, March 15, 2015 4:07:18 PM

The .Net Core and ASP.NET 5 idea has extremely big dependencies to Cloud platforms and Microsoft wants people to use Azure to back such .Net native apps and ASP.NET 5 apps, as Azure is currently a lot more organized than its competitors in the market. Obviously the .NET native (full client side apps) and ASP.NET 5 (web apps) can only work for rendering. No direct relational database access, in-memory caching, message queuing, background services (daemon/Windows Services) etc. can be included in these two things and it's also almost technically impossible to have them included in near future. So what Microsoft expects you to do in the future is like this

1. Set up your solution structures on Azure, including databases, caching, message queuing, background services, etc.

2. Write your .Net native apps or ASP.NET 5 apps to interact with your stuff on Azure. They don't care on which platform you will deploy your apps, be it Linux or MacOS, because their revenue is already ensured with your Azure usage.

They want to gradually, for avoiding stimulating the developers too quickly, transform the full .NET framework to a legacy framework and throw it to open source.

Lixin - Monday, March 16, 2015 1:52:50 AM

@Mark Century: "B#", LOVE IT!

Terry - Monday, March 16, 2015 6:52:49 PM

Hard to tell what is rumor and what is fact here. I've been getting the feeling though that ASP.Net and I may be parting ways in the future. I have been doing web sites since the early classic ASP days with MS. I do Web Forms SITES with VB and they are better quality, faster and easier to do, run quicker and don't break. Pretty much completely against the grain of where MS seems to be taking ASP.Net.

I suppose I will get a lot of dissing for being old-school, but when you've been around awhile you realize that just because something is new and shiny, or Scott Gu tells you it's the greatest thing ever, that doesn't make it better. I see MVC as a code-thick way for coders to write a lot of code and test a lot of code and be proud they are coding in some modern platform. Great for corporate organizations that like to spend a lot of money on coding. Out here in the real world, while you are still figuring out unit tests, I'm already done and getting paid. And my sites don't have performance problems. There were very good reasons why we went away from procedural code interlaced with HTML, and went to forms controls. Those reasons didn't cease to exist.

As for SITES, it was only a few years ago that MS tried to take away web projects and have everyone go to sites. Sites are faster to develop. Period. You brag about how great it is to write some code, save it, then just refresh the browser. I've been doing that for years. I only every hit F5 if I need to step through code, which isn't that often, partly because I'm good, partly because, surprise, I don't write as much code as you.

As for language, well that is really just a preference. The Internet is completely full of craptastic c# code examples, so if you think writing in c# makes you more professional, you are fooling yourself, and probably your boss. But not me.

I see no reason to change a tried and true, successful code base and methodology. Especially just because MS is pushing something else these days.

Don't know if Scott Gu will ever see this, but if you do, one thing: It used to be a fundamental promise of application makers that you NEVER took away a feature. You can add stuff all you want, but to take away is just disloyal to your users. You just don't do it. Especially when you took it away because you had a very basic misconception about how your application is used. If you take away my favorite bits, VB, sites, and web forms, you lose a very long relationship with a seasoned MS developer. Think about it.

Ed - Monday, March 16, 2015 11:29:10 PM

Ed, any chance you can re-post all of this on GitHub ASP.Net issues (#349)??

https://github.com/aspnet/Home/issues/349

Thanks!
Terry

Terry - Tuesday, March 17, 2015 12:50:00 AM

This release (and the Visual Studio CTP 6) doesn't seem to run on Windows 10 technical preview. After installation, unable to create ASP.NET projects. Getting the error

Microsoft Visual Studio
-------------------------------
Expected at least one export of the Microsoft.visualStudio.ProjectSystem.ProjectConfigurationsServiceInternal contract after filtering but found 0.
-------------------------------
Ok
-------------------------------

Harish Ranganathan - Wednesday, March 18, 2015 12:08:59 PM

@Scott, I know this might be a little off topic but since you are always upfront providing insightful information, I thought I would ask you for a straight answer. What is going on with LightSwitch? I have developed two apps on it already and now I got a third client looking for a web application and I figured since LightWwitch is now capable of rendering in HTML, I will use that. While trying to learn it online, all I can find is "LightSwitch is dead" articles. The LightSwitch team blog has taken the silent approach.

Thanks.

Mansoor - Wednesday, March 18, 2015 2:17:03 PM

One of the rules to writing good code is to keep it simple. VB/Webforms keep it simple, C#/MVC keeps getting more and more complicated every year. Simple code is easier to write, read, maintain, and keep bug-free.

Dominic - Wednesday, March 18, 2015 11:03:55 PM

Finally, got rid of the html helper, thank god.
Gulp and Grunt, do we really need it when we have Nuget? I was proudly ignoring them saying we have Nuget and Web developer tools. What happens to Nuget now?

Muhammed Irshad - Thursday, March 19, 2015 10:17:22 AM

Have to say that I am scratching my head at asp.net 5 and wondering WT... is MS thinking. I feel like MS has lost grasp of everything and is running scared and now jumping off a cliff. Don't get me wrong, I LOVE .net and have praised it and do nothing but C# .Net since it came out. I've installed the latest VS 2015 CTP and just playing around with a basic web app I don't understand what is so important that has been gained by turning everything upside down. Now, just like others are posting, I am questioning my commitment to .Net since it seems like MS is not committing to me. And now EF 7 with even more code first stuff. Visual Studio should be renamed to Text Studio. Not everything belongs in code. Time and time again, it seems like MS doesn't hesitate for even a second to alienate existing loyal users all in some half attempt to lure over other developers they don't have yet. It seems MS is constantly chasing whatever the latest open source projects are that we have no idea if they will even still be around in 5 years. It seems like MS only cares about those people that haven't switched to them yet. Is there anything in the plans that we will be able to take an mvc 5 project and upgrade to full asp.net 5 frmwk (not core) mvc 6 and everything just keeps working with zero code changes?

H First - Thursday, March 19, 2015 8:01:15 PM

Very informative and useful post and thanks for share.

BT Customer Service Phone Number - Saturday, March 21, 2015 2:21:29 PM

We want a JS set of libraries that bring most of the .NET functionality in client Javascript.
E.g. we want to have :
0) Project templates that do not use EF. I would like a template that uses OWIN+Dapper+StoredProcedures for authentication.
1) LINQ support in JS. (querying arrays with JQuery, underscore, etc sucks)
2) All the functionality of C#'s string class in JS.
3) If possible, make Spartan able to run C# scripts. If you make some improvements on the C# dynamic type, C# scripts will be the complete embarrassment of JS. I don't like typescript. One main reason is that it adopts stupid syntaxes (e.g. you have to put the type after the variable name). I am not planning to lose my mind over those stupid design decisions. C#, C/C++ are the most widespread languages. If one makes a new language that goes against the norm for no serious reason, he will use his language alone. I won't be part of it. Period.
4) We want to be able to disable links (Bootstrap does this , but should not be required for it), to make <select>s readonly, to be able to use HTML tags as XML tags and not have to worry for which tags should always (according to the geniuses made the specs) have a closing tag and which not, etc. Please, grab the people who make the HTML specs from the neck and shove some common sense into them.
5) We want CSS classes to support inheritance. The excuse that CSS implements inheritance differently is ridiculous. Also, CSS files should allow the use of local variables.

I am very angry seeing people patching the web's infinite holes and bad designs, instead of starting it from scratch. :|

Me - Saturday, March 21, 2015 11:20:31 PM

Hello,

Is there any specific requirement for Windows? I am running on Win7 & Installed 2015 CTP 6. However none of earlier feature is working on my machine- Unified Programming Model (label asp-for) & Dynamic Development (without compiling change reflection)- this shows me - "Changes are not allowed when code is running".

To double check, I re-verified my project properties and I correctly selected Framework 4.6.

Please advice.

Thanks,
Avinash

Avinash Kenjale - Tuesday, March 24, 2015 4:18:57 PM

getting excited with being able to run on Linux or whatever is just pathetic. as worse as getting excited with ef to dishonour sql server as worse as ms getting exicted for paralysing their own iis

jack - Tuesday, March 24, 2015 10:25:38 PM

Scott:

Your comment ... "we are adding support for Roslyn which means Web Forms will get access to the newest C# and VB features" ... is a bit too cryptic based on the slew of changes coming up for .NET. It's too cryptic to make decisions here for my own corporate technology roadmap.

I like what you're doing with the Core CLR, and I want that. However, I also want to keep my preferred design pattern (webforms) and language (VB.NET). What's the outlook, because judging by the current statements of program managers and the fact that 100% of the code samples and projects are done in C#/MVC, I think it's fair to guess that webforms and VB are going away. It's a terrible thing to see, but it seems clear to me. Can you explain CLEARLY exactly where webforms and VB.NET stand in the future (as currently planned) of .NET, which seems to be in the Core CLR/C#/MVC direction?

Luke Latham - Wednesday, March 25, 2015 1:05:14 AM

@Luke Latham,

The guys who are actually doing the development are on GitHub. There is a discussion at: https://github.com/aspnet/Home/issues/349 but, I am the only one there and would really appreciate any help from the VB/Webforms community.

If it's just one voice then it's easy for them to ignore... if there are hundreds of posts then that's a different story.

Terry - Thursday, March 26, 2015 2:27:56 AM

tnx a lot i like your site

طراحی سایت در مشهد - Thursday, March 26, 2015 7:17:04 AM

I saw that discussion, and I'll comment over there next. A couple of points from that Github discussion are very telling to me and add to other indications that VB and Webforms have lost a lot of support within MS:

1. Eilon: "But ultimately most investments are in the newest platforms because they have the most room to grow." ... seems to imply that VB/Webforms are going to get a lot less support going forward..

2. David said, "we're still investing in WebForms on .NET 4.6 and have no plans to bring any of it to ASP.NET 5" ... and in referring to the community getting it going it would be a "huge under taking [sic]."

... combine their comments with the fact that virtually 100% of MS MSDN code examples, public talks, videos, and project samples are C#/MVC and have been for 5-6 years now; then, add (from odd comments made by MS) that VB.NET is losing ground against C# ... VB is apparently growing ... but much more slowly ... so the ratio of apps developed is strongly favoring C#. I wish they would release hard numbers on that point. Of course, you've got every college professor out there pushing hard on C languages and MVC-type architectures.

You made some great points in the Github discussion, and I hope anyone finding this thread will go over and read your comments over there. I agree with you. I want VB.NET and Webforms in .NET 5 with the Core CLR features and new project template/layout for dependencies ... I just don't think we see enough VB'ers and Webforms folks making enough noise to get MS to invest the resources to make it happen. I hope the VB/Webforms community steps up and makes enough noise to move the needle on this. I started 30 odd years ago in BASIC on a TRS-80 Model 4p and a Timex/Sinclair 2000! Good grief! I've been around a while! ... but it certainly looks like I'll be wrapping up my career in C#/MVC.

Come on B# people! Come on Webforms folks! Let's not go down without a fight!

Luke Latham - Thursday, March 26, 2015 7:53:49 AM

I semi-understand why those who've invested in VB.Net and WebForms, and having started out in VB and Classic ASP VBScript I have a soft spot for VB.

But the syntax between VB/C# isn't that alien, I found it thoroughly easy to shift across mainly as the libraries are 99.9% the same due to them compiling into MSIL.

As for WebForms, the writing has been on the wall for a long time - if you've got legacy systems using them, then they won't be impacted, if you've an ongoing system then you can still use them with 4.6.x.

As for migrating, yes, it's a pain due to time and dev costs, but unless you've been silly and tightly bound the UI and business logic, it's just a very tedious job rather than a technically difficult one. And if you have bound the UI and business logic tightly, consider it a valuable lesson learned.

WebForms were of their time, back when the client side wasn't very good and we needed to emulate stateful websites. Things have moved on. One day MVC will be displaced by a better solution too, it's the nature of what we do - otherwise we'd still be using punch cards on mainframes.

Dave - Thursday, March 26, 2015 4:14:51 PM

@Dave Much of that is fine with me. I build apps in C# all the time, and I consider it annoying and ugly ... but tolerable. I'm more concerned about C#'s barrier to entry for youngster devs. I was about 12 when I started programming (btw- TS1000 ... ooops! I'm losing my memory. lol). I really don't think I would have gotten into dev (at that age anyway) if I was faced with trying to understand and learn something like C#/MVC ... it's just a lot more freak'in complicated. Several have commented that kids can start out on SimpleBASIC or FutureBASIC or something like that then transition into something like C#/MVC later in life ... perhaps. It still just feels really bad that youngsters starting out can't embrace .NET as easily as has been the case right from the outset. Writing software is more than just a way for corporations to make money ... it's part of peoples' lives. We wrote software for fun when I was a kid, and VB/webforms is one of the FUN ways to do it. I just hate to see .NET being slowly made less accessible to non-super-geek kids. I think we're losing something as this happens.

"And if you have bound the UI and business logic tightly, consider it a valuable lesson learned." If you Google "MVC sucks," you'll get some great explanations on why webforms is an awesome way to build certain types of apps. Tightly coupling the UI and logic is EXACTLY what many applications need to be quick and easy to build and maintain. None of these are silver bullet technologies that solve all problems, and as soon as you say that this or that has some awesome benefit, it almost always triggers some other major negative drawback under other conditions. Sure, MVC has some great features and benefits and solves some drawbacks of webforms ... hey! ... you can swap the words "MVC" and "webforms" in that statement and it will still be true ... Google "MVC sucks" and check it out.

Here are some things that I hope get discussed ...
(a) MS won't publish hard figures on adoption and use of VB and C#. They just prance around telling us that VB is losing ground. Why not just give us a graph of the ratio of apps using the two languages over time so we can see for ourselves just how fast C# is growing?
(b) MS won't participate in the open discussions on the webforms vs. MVC debate, but they clearly had those discussions internally perhaps 5-10 years ago. They just won't say what arguments have swayed them to firmly go C#/MVC outside of vague mentions of how MVC is considered a "modern language" ... whatever that means!
(c) If the entire community ... not just fat-cat corporate devs who get to go to TechEd ... but the entire community is saying in surveys that they really don't care if VB/webforms goes away, then report the results of those surveys openly. Surveys should include everyone ... they should include kids! It would be really insightful if a survey of only people who write software professionally in both languages and using both design patterns was taken and reported. I'd like to hear from people who started on C# but ended up on VB for whatever reason. Did they like it? Did they hate it? Why? Do they want VB to be kept around even if they prefer their first language, C#?
(d) If the technical issues of having VB and/or webforms added into David's team's work are so intractable and expensive to overcome, then tell us that. Have one of the devs write us a "Deep Dive" on why it would be such a pain for MS to keep VB/webforms part of .NET 5.
(e) Don't keep saying that "open source" is great ... that "openness" and "transparency" are important ... then turn around and shaft a bunch of companies and people on their favorite programming language and website design pattern with a completely opaque decision making process. But at least if the call has been made, tell us who made it, when did they make it, why did they make it, and give us guidance on when VB/webforms is going to be dropped (if known).

I think David tipped their hand with his comment that included, "no plans to bring any of it to ASP.NET 5." ... I think he's implying that the answers to Terry's excellent questions are:

Are VB and Webforms dead in the long run? YES! They are DEAD in the long run.
And, should we all (as Stephen Walther has implied*) just accept the C#/MVC paradigm? YES! You should.
* http://stephenwalther.com/archive/2015/02/24/top-10-changes-in-asp-net-5-and-mvc-6

It's time for MS to step up and answer the questions. If the answer is "We don't know" then say "WE DON'T KNOW."

Luke Latham - Thursday, March 26, 2015 7:38:34 PM

@Luke - I don't get how you think C# is that much more complicated, sure VB is more verbose, but if that was the barrier we'd be teaching people COBOL as you don't get much verbose than *that*! :D

I started off with BASIC too, back in the mid-80's using an ORIC Atmos, before progressing onto Sinclar's Spectrum.

My first experience with the C family was with C and C++, and the difficulty I found with them came from how I was taught. Once I sat down and focussed on concepts rather than the language learning them became much easier, my University courses were a complete waste of time.

And much as I hate the current crop of default project files, they're excellent for learning from. Create, compile and run. Play about with things, if something breaks, google it... If anything the biggest bugbear is that MS are still lazy with error messages.

And even now, there are viable learning alternatives as a step to .NET - been a while since I used it, but RealBasic was a great alternative to VB6, and Abobe's Flash on the desktop is great for drag'n'drop prototyping whilst reducing the fear of the curly brace and with an ES-based language. Doesn't have to be an MS closed shop.

As for MVC vs WebForms, I don't think either of them suck as such, I spent many years working with WebForms - I migrated to MVC simply because the code was cleaner and I could develop much faster as I wasn't working against MS mandated control templates and an overcomplicated Page Lifecycle. Training up a team of developed on that boondoggle was fun - not!

Yet they took to MVC like a duck to water.

And I dispute tightly coupling the UI and logic makes for easy maintenance, the last 20 years has taught me the precise opposite when I've had to retool an app for a new front-end or make chunks re-usable for other projects.

Yes, it can be quicker, but it's a lot dirtier too.

Dave - Friday, March 27, 2015 8:46:49 AM

I see a TON of conflating VB.NET and WebForms in the conversations despite statements that WebForms will continue to exist.

I'd like to hear from Scott or someone in the know about why VB.NET is being specifically excluded from MVC. I guess the 40+ developers at my company are included in the two Stephen Walther noted that use VB.NET with MVC...

One of the reasons VB.NET hasn't seen the same growth is because MS only puts out samples in C# now, which seems to indicate leaving VB.NET behind but in a very indirect and passive way.

Chris - Tuesday, March 31, 2015 3:24:34 PM

in my opinion, for small businesses, with a small group of people in developing Webform it is the best solution

mixfede - Wednesday, April 1, 2015 10:19:18 PM

To me has made me hard to learn this language I have almost 7 years of working with winform and the future of technology I will be based on web / cloud. To take full advantage of this technology is important to learn these HTML, CSS, JS, JQuery, JSON, Angle, Bootstrap, C #, Asp.Net WebForm and MVC languages. Ufffffff much to learn.

greetings To You
Felix Campos
Managua, Nicaragua

Fexche - Sunday, April 5, 2015 4:11:16 PM

The problem is Microsoft has lost control of the interface. When .net first came out, I could write entire win and web apps is 100% .net. N tier, client/server, everything would be .net. But now as businesses move off windows apps (I haven't written one in a long time), the browser has become the new OS to run apps on. With more and more technology moving to client side javascript, less and less of my apps are .Net. My latest app is ExtJS for the client interface. No .net needed. .Net is now just acting as a proxy to the db and I am questioning if I should even bother with .net or sql server for the next app. Slowly the dominos are falling. At the same time, I feel like my productivity has dropped a lot. I hate javascript. But Microsoft isn't offering any viable alternatives. I wish that Microsoft could figure out a way to develop the equivalent of something like ExtJS with some kind of C#/javascript translation layer so that I can write my gui in C# that can on the fly behind the scenes generate the browser equivalent javascript to run client side, and that can reuse the exact same model files client and server, etc.

H First - Monday, April 6, 2015 12:56:54 PM

ASP.NET MVC isn't a replacement for Webforms. Even after dropping Webforms it remains fact that Webforms is much more powerful on the client side. Guthrie and his followers are arguing that the page life cycle of Webforms was to complex to excuse the lack of features in ASP.NET MVC. The reality is that a good architecture is complex. No one has ever required you to use all events of the page life cycle and good developers has had always used patterns like MVP. Now, with ASP.NET MVC you have views that mix code and markup and you heavily rely on different external JavaScript libraries to get anything done. A nightmare for every CIO and architects, because they are facing constantly different libraries with no support. If I look at the official ASP.NET page there are virtually no customers that use ASP.NET MVC. Just some internal projects like Xbox or Bing. Not a good sign...

msdev - Monday, April 6, 2015 2:49:23 PM

I wish that Microsoft could figure out a way to develop the equivalent of something like ExtJS with some kind of C#/javascript translation layer so that. I like it.

khach san da lat - Tuesday, April 7, 2015 7:41:45 AM

This looks really awesome!
But what about SASS compiling? All major css-frameworks seems to go for SASS instead of LESS, will you guys make your own compiler or support someone elses compiler?

Mike R. - Wednesday, April 8, 2015 10:09:39 PM

Don't call VB.NET "B#". Another language exists by that name, for embedded systems (bsharplanguage.org).

I began on Atari Basic myself. Much later, I developed ActiveX apps with VB, then ASP.NET Web Forms apps with VB.NET, because it was the mandated language in my organization (a Quebec, Canada, ministry).

The choice of VB.NET did not and still does not make sense when the clientside language is JavaScript with a C-like syntax. VB.NET was chosen because it was deemed easier to learn for all the VB programmers that the ministry employed. But it was a fallacy because the steeper learning curve was for the .NET base class libraries, not the different syntax for C#. Now most ministries in my province are stuck with VB.NET. Does not make much sense 15 years later in retrospect, now does it? Where are all those VB developers? I suspect few of them still program because the usual path for programmers in government here leads to management of some form or to pure "analysis".

5 years ago I moved to a ministry that chose C# and I had very little problem adapting to C#. Now I can't imagine going back to verbose VB.NET. I can't see myself writing lambda expressions in VB.NET. What a nightmare! It seems to me I'm more productive writing C# than VB.NET.

As for Web Forms, there's another fallacy for you. It's an attempt to abstract the web and its underside. You take a Windows Forms developer and with little training, you make him a web application developer, right? Wrong. I have seen ASP.NET Web Forms applications written by those and one thing was obvious: they did not understand the web at all. You must understand how it all works, or else you'll end up making a mess. So I much prefer ASP.NET MVC because you don't pretend to write web pages (sorry but there you go), you really do, in HTML rather than with controls, and you really have to know what you are doing.

If ASP.NET MVC is too complex for you, then I suggest the Nancy framework. It looks great, and I'd very much like to do a project with that framework some day.

And finally, about the changes coming in ASP.NET 5. You people do realize you're in software development, right? And our field is about change. We're supposed to embrace change. It' funny to me to see such resistance to change in our field.

I'm pretty happy about those changes, but... they are long overdue. If you'd followed what's happening on other web development stacks, you'd understand that very little here is new. With ASP.NET 5, .NET will finally be on par with other stacks. The question is: is it already too late?

Personally, I'd jump ship any minute to develop in a dynamic language with Node.js (JavaScript) and a document (NoSQL) database, if it means more productivity. No need for ORMs! And JetBrains (maker of Resharper for Visual Studio) makes pretty mean IDEs so I can still have my "crutch" (because, of course, "true" OpenSource developers program with text editors ;-). And let's face it: the other stacks are a lot less costly in licenses. In the public sector, that MUST be considered even though most decision makers here don't want to see it.

SylvainC - Thursday, April 9, 2015 5:52:58 PM

I don't get why so many people have VB and Web Forms stuck up their a**.

I wrote classic ASP apps using VB Script from 1998 through 2008 using Visual InterDev, and finally made the jump to .Net because I had the tools available to do it, such as Express Editions of Visual Studio.

I first hopped on the Web Forms and VB band wagon, mainly because it made a lot of stuff stupid easy. But, wow, I needed to do some complex stuff on something presumed as simple as a GridView. What did that take? Writing events for the Row_whatever event? Oh, and then web browsers got way smarter and nobody wants to wait for a round trip to a server. That made me realize this was not the way to go.

I think most posters here don't understand the fundamentals of the web. Mainly get and post. Web forms made it easy for idiots to deal with a stateless system without having to think about what's going on behind the scenes. I do agree that it made transitioning from a Windows based application to a Web based one very easy. Well, guess what, you SHOULD know what is really going on behind the scenes, and how the disconnected world of the web really works. Regardless of the language you are using. How many people reading this ask questions about making a JavaScript or jQuery thing work on an ASP.Net forum? Well, dumb ass, ASP.Net does the server side stuff. The browser interprets what ends up in your page and makes client side functionality possible.

Even after all my years of writing in VB I saw C# and was like "holy crap that's way easier to read and write". All you VB guys show me what you have to write to do something as simple as "public DateTime? CreatedDate { get; set; }". I know it's a whole lot more code to do that in VB. And if your answer is "VB is easier to understand" you should not have a job as a software developer, because you must not know your head from a hole in the ground.

I think it is stupid for Microsoft to waste their time making .Net compile to MSIL for C# and VB. Those of you opposing this change because you can't read C# should think about what it takes to achieve such a thing.

Another thing to remember, not just on the pro-VB side, is all the changes to VS are project configuration changes. So we have to learn these little changes to make our existing projects work. Whoopty do. I'm glad Microsoft has spent the time to think about it. None of you have.

Ryan Besko - Friday, April 10, 2015 6:13:13 AM

Web Development has changed a lot lately.. JavaScript is gaining ground. A lot.

I use Asp.Net for session management en building api's.. But I wonder for how long.

I like C# more than Java.. Syntax wise. But I can't seem to get around the fact Java has much nicer frameworks. Play and even Spring just seem like a better fit for me.

I've been a .Net developer for the last 11 years and I'm seriously worried about the future. Things are changing rapidly and Microsoft is lagging behind.

Marc Schlechter - Friday, April 10, 2015 10:02:49 PM

Oh btw:

C# might be better than VB, but that's not the point. Microsoft advertised several times that VB is a first class citizen in .Net. They also believed in one Asp.Net.

And now all of a sudden VB is not supported on this new framework and WebForms is gone. And EF is a complete rewrite which is crippled upon first release. The team even recommends to keep using EF6.

This is a friggin mess.

Do you want to stop supporting VB? That's fine, but please announce it sooner. I like C# better anyway.

WebForms gone? It makes sense now JavaScript is winning, but why keep defending it? Why tell people it's still being developed when it's actually a thing of the past?

Everyone knows it's dying.. And those who don't, should know before they invest more time and money in old technology.

And EF.. Well I use nhibernate. It does what I want and doesn't break or change with every release. I tried to love EF, several times.. and failed.

Anyways I also want to say you did a lot of things right lately. Going open source is great. VS community edition is wonderful. Supporting Linux and Mac as a target is really nice. I don't hate Microsoft at all. I like you more than Google or Apple these days.

In the end, the open source community will hopefully come with new frameworks like NancyFX etc. Because C# itself is nice. C# 6 is looking more like Scala.. Also really nice.

I just hope the OSS community cares enough.

Marc Schlechter - Saturday, April 11, 2015 10:27:41 AM

Angular is dead by now, seems extremely weird that Microsoft suddenly starts to implement templates for it. Rob Eisenberg left Angular, goodbye Angular.
Even worse, they are now talking about Angular and server-side functionality. It seems completely and utterly stupid to support Angular that way.

And what is up with that weird and obscure Angular-syntax... something is just wrong with it, thank god the pain soon is over.

Why on earth did they invent their own DI and service locator pattern, and as this wasn't enough, why did they choose not to follow their own best practice and use Common Service Locator Pattern.

Even worse, they added Activate-attribute for DI. The first thing everybody learns when dealing with DI, avoid attributed class-pollution.

I simply don't understand why Microsoft is playing the old hunting game instead of making a solid road-map.

Janus Knudsen - Sunday, April 12, 2015 5:33:51 PM

Awesome update in VS2015

Gaushick - Tuesday, April 21, 2015 11:54:58 AM

There's so much reaction here, but so little thought. Having been through 28 years of Microsoft development changes, the first thing one has to learn is that MS rarely offers the kind of hard roadmaps to which some here allude; they very much favor reacting nimbly to what they perceive as either customer or profit demands. Very often, the two are mutually exclusive.

From a technical perspective, the ASP.NET WebForms model was very much inherited from the classic VB6 IDE paradigm; but in the web environment, that event-driven model often became needlessly complicated and clumsy. The simplest things often required somewhat byzantine event handlers at seemingly inconsistent places within the event model; the problem wasn't with the event model per se, but the fact it was modeled from a fundamentally different environment, and the two simply didn't mesh. I think MVC is an effort to resolve that issue.

I remember the halcyon days of VB6, and while I remember its clunky syntax and back-door fixes and patches to make things work, I do remember that it *did* work, and we did get actual work done with it. No one would ever mistake it for the more elegant object-oriented successors that would follow, and even VB.NET was little more than a syntactic shadow of its predecessor. Was it perfect from a computer science perspective? Hardly. Did things get done with it? Absolutely.

Here we are now, twenty years later, and the same evolutionary/revolutionary arguments prevail. An effort is being made to promote a newer, better toolset to accomplish the newer kinds of jobs web-based resources are being asked to perform; jobs older programming models aren't well-suited to handle. It is inevitable that technical change will mandate newer, different tools and skills. It's simply a fact of life.

With the possible exception of my allegiance to C# due to my personal history with C dating back to the 80's, I try as best I can to realize that languages and programming models are not religions, but tools. When one sees a new hammer, al the world suddenly begins to look like a nail, and thus we have to avoid the notion that the newest tool implies a mandate to conform the past to the present merely for change's sake. That's wrong. We are seeing an effort to change and fix some issues most of us have known to be present with the traditional ASP.NET model in particular, and Microsoft programming "theology" in general. The key is balance.

Microsoft has a very serious problem over the next decade. They can no longer assume the closed-shop mentality from which they have benefitted greatly over the last two-plus decades. The real-world now means numerous flavors of Linux, open-source deployments, and multi-faceted development resources. They cannot stay as they have; clearly, Microsoft has struggled to find its niche in the evolving development world, and this new ASP.NET 5/Core .NET packaging is a first step in a drastic new direction. It acknowledges, at least in part, that Microsoft has to co-exist in a very complicated technological world, and its ability to impose standards and tools has diminished greatly. Their options are to perpetuate VB.NET within the microcosm of Microsoft developers, or pursue a solution environment that potentially expands their developer base to those who have never *touched* a Microsoft product because of the glass wall that has, to now, surrounded them - and now to Microsoft's exclusion.

Are all the steps Microsoft are taking the correct ones? It's impossible to say. I don't know if the broader Linux/OSX world will ever embrace the idea of deploying some one-off of .NET in their world. And many of the comments here suggest that the development strategy Microsoft is undertaking in that vein implies some curious, maybe even unwise choices. MS has taken too long to embrace the JavaScript world and the development models it implies, and whether these steps are too little, too late remain to be seen.

All I or any developer can do is try to figure out what kinds of technology gives them the best chance to put solutions together that gets practical jobs done and, more importantly, puts food on the table for our families. If that means embracing new versions of old technologies, or discarding old systems and learning new ones, so be it. I've just been in this business in my own little corner long enough to know there aren't any panaceas. They're just tools. Getting up in arms over any of it makes little sense.

SaneCoderGuy - Wednesday, April 22, 2015 1:33:54 PM

Comments have been disabled for this content.