The only real news here is that, indeed, ASP.NET vNext is going to be developed in the open, or at least to some extent. But right now, not a lot of code seems to be released that wasn't already out there (although I did not go through all the repos).

I don't think you should expect to find many current/legacy parts of ASP.NET that aren't open yet: this seems to be mostly for new stuff.

Finally, don't forget that "ASP.NET" doesn't seem to mean a lot (anymore): it's basically Microsoft actively shipping the org chart. Anything that's web related and from MS appears to get tacked "ASP.NET" on front of it. Cause really, what does ASP.NET MVC, basically a pretty uninspired Rails port to C# (and just an open source library like any other), have to do with "active server pages"?

[0] https://aspnet.codeplex.com/wikipage?title=MVC [1] https://entityframework.codeplex.com/

Hack, Connery, Hanselman, & Guthrie openly acknowledge that rails was a source of inspiration in their book http://www.amazon.com/gp/product/0470384611?ie=UTF8&tag=scob... but so was Spring, among others. Above all, I think the .net mvc framework was trying to capture the fasted-paced, fly-by-the-seat-of-your-pants essence of the rails way more than anything else. In doing so, they unearthed a lot of awesome concepts previously unknown to most .net developers like domain-driven design, tdd/bdd, dependency injection, scaffolding; old hats to Java and ruby guys.

The mvc .net team did an amazing job of breaking stride with the asp.net mentality of letting the framework do as much as possible. Yet .net was still very much confined by it's own structure, forcing the mvc framework to remain rigid. They opted for configuration over convention which, in my opinion, was by far the biggest differentiator in rails to the mvc frameworks that preceded it.

ASP.NET MVC is the only place I've ever seen in mainstream compiled languages where the code can break in untraceable ways if you change the name of a method parameter (f.ex. for controller actions). Or where models suddenly don't get data because you forget to add "{get; set;}" to the code somewhere. Absolutely no way to find out why it went wrong. The data just isn't there.

Sure, you can learn this and then not make the mistake again, but the reason I don't use Ruby or Python much anymore is because I've had with with having to spend a full day going through a framework's source code to find out why my bug is a bug. In an ecosystem and language like C#, you expect things to either work or to get a pretty OK error message, preferably at compile time. The more magic, the more time I waste tracing bugs.

What's the point of using a compiled language if half your code is a dynamic viewbag of string keys and liberal JSON parsers that just ignore fields it doesn't expect or can't fill?

It's just Ruby, but then in Visual Studio.

No, that's what you expect. I expect that the traits of frameworks you describe to be features of particular frameworks and to be largely independent of language, except that in languages that don't provide introspection/metaprogramming facilities that enable them, you probably won't find them (probably, because usually there may be elaborate ways of hacking around language limitations to do magic, and then even examining the source code will make the magic less obvious.)

You can easily have magic-free frameworks in Ruby or Python, and easily heavy-magic frameworks in most (mostly) statically-typed compiled languages like C# and friends as long as they have some introspection/metaprogramming facilities (and optional dynamic typing like C# makes this more viable, too.)

If you want to choose a language so as to avoid any need to examine the traits of particular frameworks so that you don't run into a heavy-magic one, you are going to need a much more limited language than C#.

> What's the point of using a compiled language if half your code is a dynamic viewbag of string keys and liberal JSON parsers that just ignore fields it doesn't expect or can't fill?

The point is the other half of the code. (The part that, in Python or Ruby you might be tempted to drop down to a C or Java [for JRuby] extension to do.)

I believe you meant "convention over configuration", right?

That said, can't blame anyone for once again being confused by Microsoft's ultra-confusing "give everything the same name" approach to branding.

What does that even mean? In this case, a bunch of libraries and a protocol for dispatching HTTP requests to .NET code.

If I use Mono's XSP server, and use it to host a ServiceStack backend, am I using "the ASP.NET platform"? It's 100% non-Microsoft open source. Am I using ASP.net when I host the same backend on IIS instead? Or when I host ASP.NET MVC (which is just a library) on Mono/XSP?

Or maybe not. Perhaps someone means to specify that they're using Mono/XSP as opposed to one of Microsoft's implementations. But then it'll probably be obvious from the context.

They're building a new stack from the ground up. Which is the only way, really, to make it "cross platform".

http://referencesource.microsoft.com/System.Web/xsp/system/W...

https://github.com/msopentech https://github.com/Azure

The Azure SDK has been there since 2012.

I agree that even now it still seems kind of odd when Microsoft embraces open source technologies, and the company is very big so their support tends to be oddly lumpy (generally better among the groups working on products that are directly related to networking like ASP.NET, Azure, etc) but they've been on this path for quite a while now.

        private bool IsDifferent(ConfigurationsMessage local, ConfigurationsMessage remote)
        {
            return true;
        }

        private bool IsDifferent(ReferencesMessage local, ReferencesMessage remote)
        {
            return true;
        }

        private bool IsDifferent(DiagnosticsMessage local, DiagnosticsMessage remote)
        {
            return true;
        }

        private bool IsDifferent(SourcesMessage local, SourcesMessage remote)
        {
            return true;
        }

        public struct Nada
        {
        }

“The Home repository is the starting point for people to learn about ASP.NET vNext, it contains samples and documentation to help folks get started and learn more about what we are doing.” [0]

“The GitHub issue list is for bugs, not discussions. If you have a question or want to start a discussion you have several options:

- Post a question on StackOverflow - Start a discussion in our ASP.NET vNext forum or JabbR chat room [1]

ASP.NET vNext includes updated versions of MVC, Web API, Web Pages, SignalR and EF... Can run on Mono, on Mac and Linux. [2]

MVC, Web API, and Web Pages will be merged into one framework, called MVC 6. MVC 6 has no dependency on System.Web. [3]

[0] https://github.com/aspnet/Home

[1] https://github.com/aspnet/Home/blob/master/CONTRIBUTING.md

[2] http://blogs.msdn.com/b/dotnet/archive/2014/05/12/the-next-g...

[3] http://blogs.msdn.com/b/webdev/archive/2014/05/13/asp-net-vn...

I'll be quiet now, and get back to working on my MVC code. The day when I can finally stop having to work on WebForms code too will be a happy one :-)

Postback? That's really part of HTTP. What the browsers send back to the server is as specified by HTTP, not Microsoft or Web Forms.

Viewstate? Okay, it's a bit of a tricky thing, but really can mostly ignore it. Else it provides a somewhat useful service.

Controls? Yes, for each HTML 'control', there is an ASP.NET class so to send the HTML for the control to the user, get an instance of the class corresponding to the control, assign values to the properties, attach the instance to a big tree that gets walked by the code in one of the ASP.NET 'events', maybe PAGE_PRERENDER, and move along. Why is this so bad?

Web Forms is my first and so far only way I've written Web pages. Explain what is wrong with Web Forms and what is much better and why?

ViewState was far better than other frameworks that shoved the client state into a server session object and broke the Back button. Plus the clients were saving state instead of wasting server memory. If it got too ugly, you didn't even have to use it, the http variables were still there.

Remember this was all designed back when Netscape 4 was a popular browser and any Javascript was considered exotic. Of course we have much better way to do things now, the WebForm approach broke down hard as soon as it encountered AJAX. But originally it was fine.

Drag an AJAX control on the form, and whatever is in there, that part of the page will be ajaxed.

This in turn forced people to go to the MVP pattern to manage those systems, but I still find plenty of clients with code behind that is THOUSANDS of lines long. Everything in one file.

Also, many of the controls were very hard to style, with some very strange html in there.

This is all fine if you are on the local network, but it ignores all the issues that go along with the network, such as latency. There is no silver bullet for latency. It's a physical constraint. The same goes for bandwidth. Throwing an UpdatePanel on the form doesn't solve the problem. Try using a Web Forms page on your phone some time with a 3G connection.

Right, Web Forms, and, really, HTTP and HTML, treat the client like a 'dumb terminal', one with some quite amazing capabilities but, still, 'dumb' in that the Web browser is just displaying some pixels and the user is just entering data via the standard HTML 'controls', text boxes, radio buttons, check boxes, etc.

For my site for now, treating the user's Web browser as a dumb terminal is what I wanted. One reason: There is less, hopefully nothing, new for a user to understand about how my user interface (UI) works.

But, yes, at times, a more 'dynamic' Web page could be of interest.

Right, JavaScript running in the client's Web browser can yield much more 'dynamic' Web pages. And, with AJAX, still more can be done to have 'dynamic' pages.

But so far for my Web site, I have yet to write a single line of JavaScript. Somehow ASP.NET writes some JavaScript for me and sends it to the user, but I don't know what that JavaScript code does and hope not to care.

My guess is that if I want to write some JavaScript somehow there is a way in ASP.NET Web Forms for me to do so, i.e., maybe just put my code in the file of JavaScript code that ASP.NET writes and Microsoft's IIS sends.

You mentioned a phone: My Web pages are just dirt simple and each just 800 pixels wide -- I hope that the pages will look good on nearly any device with a Web browser right up to date as of, say, five years ago.

For a 3G connections, at

http://www.pcworld.com/article/253808/3g_and_4g_wireless_spe...

there is a graph of 3G speeds by various vendors, etc. and about the slowest is 0.59 Mbps. Fine with me: One of my Web pages sends, including the JavaScript file, for about 400,000 bits. So, the page should download on the slowest 3G connection in about 1 second. If I take the extra blanks out of the JavaScript ASP.NET writes for me, then the page should load a little faster still.

At least at my site, Web Forms is sending mostly just some HTML; maybe, I don't know, ASP.NET Web Forms is slow on the server, but I'm not seeing just why what Web Forms is doing should be slower for the data transmission or the user's Web browser than some other way of sending HTML.

I think there's a lot of value in that, and for as much frustration as maintaining Web Forms apps has caused me (and will continue to cause me) I think it would be neat if they open-sourced it...what's to be lost if the alternative is to just let it rot into obscurity? I would totally fork the repo.

I don't think there is a mandate for all MS project to be on codeplex which is somewhat surprising.

[1] https://github.com/aspnet/FileSystem/blob/dev/src/Microsoft....

ASP.NET vNext (and Rosyln) runs on Mono, on both Mac and Linux today. While Mono isn't a project from Microsoft, we'll collaborate with the Mono team, plus Mono will be added to our test matrix. It's our aspiration that it 'just work.'"

Thanks for pointing that out though, I learned something new today! http://msdn.microsoft.com/en-us/library/dd642331(v=vs.110).a...

I know people who do their .NET work in Sublime Text with a nant build chain. It's not my preferred method, but it works great for them. Hell, I know a guy that uses ASP.NET to host an Angular app, and to unify his build system, he has Grunt pick up the heavy lifting of running his MSBuild files whenever he does the pre-deploy steps for his JavaScript.

If you think you need Visual Studio to do .NET development, it's because you fundamentally don't understand the technologies at play and just wanted to say something provocative and witty.

On the off chance you're not just being knee-jerk and defensive because Something You Like is under fire--people think that VS is necessary because life is way too short to spend building something half as good as the other options in twice the time. I mean, could write Scala in TextMate, too, if I had the jones for it. But I could also not, and use IntelliJ, because I value having tools that are able to improve my productivity. (And decrease my frustration; by sticking with the JVM I have the benefit of not have to rely on Mono, whose GC, from experience, I do not trust in long-running processes; after spending a year owning a trivial Mono ASP.NET app that presented no end of troubles, I am very happy not needing to have a watchdog ready to kick it over when it undergoes its daily spaz-out.)

Xamarin Studio is not an acceptable product, either. I've been trying to use it for a couple weeks now and about ready to pitch a computer out a window--the basic functions of editing code are magnificently broken and have been for a long time. Random phantom line breaks in the editor that aren't in the code file, bad auto-indenting, phantom error highlighting, no partial-build error solving--and Visual Studio doesn't work on OS X. (To say nothing of the "you have to restart because XS forgot how to talk to xbuild" bugs...) That leaves the shitty bodges you well-actually'd your way into or not doing .NET at all. The latter makes a lot more sense for a lot more people.

I really enjoy C# and F# and I'd love to use .NET more if the frustrations in using it on not-Windows were not of such a magnitude. I am critical because it should be better and isn't. (Worse, Xamarin removed most reasons to contribute to the Mono ecosystem a while ago by making so much of the useful bits commercial, which is understandable--gotta eat--but also unfortunate.)

I would argue that it would depend on the person behind the keyboard. I love VS but I happen to be working all day on vi at work and here I know colleges that are as fast or even faster than a lot of people relying on Intellisense. So my guess is that YMMV

You can make mobile apps with Xamarin, and apps for any desktop OS thanks to Mono.

You can make high-quality 2D/3D games with Unity

You can make high-performance web applications with ASP.NET + IIS.

Also, Microsoft has a great startup programme with Bizspark, we built a company on it a few years ago that eventually ended up as part of a $700m acquisition

Even though C# and .NET has a huge developer following, .NET is losing ground to OSS within the top traffic driving sites. 10 years ago, people would build their MVP in .NET because it was the best technology around, but nowadays I see more people building new businesses and placing their strategic technology bets elsewhere (Java/Python/Ruby or Node).

A lot of these developers don't want to be married to the Windows eco-system, for a variety of reasons. Microsoft cannot continue to thrive on the sole basis of it being the only game in town anymore. So all in all what I'm trying to say is I don't think the long-term prospect is looking great.

PS. I heard 2015 will be the year of Linux

I heard that too in 2012[0], 2013 [1] and 2014 [2]

[0] http://www.linuxtoday.com/it_management/2012010900341OSOO [1] http://www.finnbay.com/linus-torvalds-leadership-defines-201... [2] http://meshedinsights.com/2014/03/14/2014-year-of-the-linux-...

>Too little

Really? Its MS, their core products and the open source we are talking about. Heck they even open sourced it under a liberal license.

Flying cars would be pretty huge even though planes have already been flying for a while...

The catch here (and point) is why should you have to switch from VS at all? If it's a real source code editor shouldn't it handle Java, Clojure, Haskell, Python, Ruby, JavaScript, etc all just fine? Some of the oldest and free editors do and do it well. I realize MS has an agenda (perhaps) or they've de-prioritized any of these features into oblivion -- but who are they serving, I certainly didn't feel it was me even after giving them a lot of $ for VS.

http://pytools.codeplex.com/

http://nodejstools.codeplex.com/

They have others but you get the idea.

And you don't need VS to do .net development; check out monodevelop or xamarin studio (they're the same basic thing)

Other types of projects, notably WebAPI, have been able to easily deploy outside of IIS for years. I actually just converted two WebAPI projects to self-hosting. It took about a day, which is not bad considering that includes time to learn what I was doing and reworking an existing deployment process.

It's about the fact that the whole .net framework is not opensource,thus forcing you to run windows server anyway.