ASP.NET 5

[m...@yannisguedel.ch]

Dear Umbraco-Team,

The next version of ASP.NET (called ASP.NET 5) will break a lot of things (everything). Migrating Umbraco to ASP.NET 5 will be a long during task with tones of breaking changes. I havee seen that you put a lof a time in researching about it and even had a Session with the ASP.NET team: https://groups.google.com/forum/?fromgroups&hl=en#!searchin/umbraco-dev/vnext/umbraco-dev/uLaM7VhWaxk/Fg11aP0jwb8J

However I could not find a discussion how it's planned to process with ASP.NET 5 , how important this is for you and how feasible you see this.

Basically there are two things I am really interested in. The first one is the timeframe you think is needed to migrate umbraco to ASP.NET 5. 1 year? 2 years? 5 years? Never?

Two second is more a general one. Migrating any Framework/CMS/Library/whatever to ASP.NET 5 will be a relly hard task. So I'm wondering how other teams solve this big problems. Which steps are required? How "hard" are you with your customers? Will you go with multiple steps, like first dropping all WebForms support and then other small steps or will it be one big release breaking everything?

[Aaron Powell]

Disclaimer - I don't work for HQ, I'm just someone who has contributed over the years in various capacities to Umbraco.

During the CodeGarden 14 keynote there was a talk about vNext (as it was then called) and that Umbraco would go that way. Naturally I subtweeted the hell out of it - https://twitter.com/slace/status/476649047265001472 but I still maintain my stance on bandwagonning.
I recently caught up with some of the HQ team and the conversation did naturally come to ASP.Net 5 and I took the time to better elaborate on that tweet in detail (which I should have done a blog at the time on but oh well :P).
I steadfastly believe that Umbraco shouldn't be going ASP.Net 5 simply because "it's the future", keep in mind that ASP.Net as we know it today, WebForms, MVC, WebAPI and all that stack isn't going away, there's 15 years of investment in it so don't expect it to just vanish.

But does that mean I think Umbraco shouldn't invest in ASP.Net 5? Yes, I think investing *specifically* in ASP.Net 5 would be the wrong approach. Now before people lynch me hear me out on why I think this. It's the same reason that I see Umbraco 5 failed, it wasn't doing what was best for the users instead it tried be 'the future'. MVC-because-MVC was wrong, MVC because it made Razor more universal, it opens up testability, it enables a more flexible back office, these are all good reasons to have gone MVC and were all achievable on the "v4" codebase (as has been proven).

So how does this relate to Umbraco and ASP.Net 5? Well simply put do what's going to make things better for the majority of the users. Doing things like removing the reliance on HttpContext and in turn moving away from relances on System.Web.dll have benefits on the way we write applications on Umbraco and also doing that makes it easier to migrate to ASP.Net 5 when the time is right.

In summary - Should Umbraco run on ASP.Net 5? Eventually yes. Should Umbraco's focus be working on ASP.Net 5? No, there's plenty of other areas to improve that will help with that goal without being focused entirely on that goal.

--
You received this message because you are subscribed to the Google Groups "Umbraco development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to umbraco-dev...@googlegroups.com.
To post to this group, send email to umbra...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/umbraco-dev/6620681c-752c-429b-9273-6109b99ba797%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Devin Bost]

I've done quite a bit of research on this subject, and my opinion is that ASP.NET 5 really is the future because the Microsoft developers appear to have fixed all of the architectural issues that previously bothered me; they've replaced them all with best practices, and it's actually quite impressive. If someone wants to give me a "TO DO" list on what needs to be done for the migration to ASP.NET 5, I can get the process started. 

-Devin

[Aaron Powell]

TODO:

1.       File -> New Project -> ASP.NET Core 1.0

2.       Don’t make Umbraco 5 again

To view this discussion on the web visit https://groups.google.com/d/msgid/umbraco-dev/733912bd-71b8-4ef7-8173-fd028f5c9a41%40googlegroups.com.

[jbr...@gmail.com]

Have a look at the Umbraco roadmap. First they are going to build Umbraco 8 which removes a lot of legacy stuff. After that Umbraco 9 will focus on ASP.NET Core 1.0. See slide 43 of the presentation: http://static1.squarespace.com/static/55bf4530e4b0b2984959feba/t/5638d8d6e4b0ce96e2266472/1446566102051/RoadToV8.pdf

There is already a POC: https://github.com/Shazwazza/Umbraco9

[Devin Bost]

Aaron, did you delete my response to your post?

-Devin

[Aaron Powell]

Nope – it was caught in the spam filter, I’ve just released it.

To view this discussion on the web visit https://groups.google.com/d/msgid/umbraco-dev/1fa81185-bd33-4dea-b63b-c1972a30d558%40googlegroups.com.

[Aaron Powell]

I’m quite aware of the history of Umbraco 5, after all I helped kill it (http://www.aaron-powell.com/posts/2012-06-25-i-helped-kill-umbraco-5.html).

 

My previous post was somewhat facetious. ASP.Net Core 1.0 isn’t a direct successor to ASP.NET, you don’t just upgrade NuGet packages and have it work, it’s a reimagining of the platform using the learnings of the previous 15 years of development (on ASP.NET) plus learnings from what other web frameworks are doing (including Node.js, Ruby and others).

 

The biggest challenge that I see with moving Umbraco to the new Core platform is how the Umbraco pipeline works and the plugin model. Both of those are very tied to the ASP.NET hosting model which is IIS based, but in Core the hosting model is very different to support non-IIS hosting (be it self-host on Windows, libuv on *nix, etc). These two models are very different and I’d be surprised if you could make something that would support both models.

 

Does this mean that Umbraco of the future only supports Core? Microsoft hasn’t made it clear what the future of the current MVC/WebAPI2/etc is, but after all they are open source too so there’s nothing to stop them living on.

 

Also I think you’ve got a false assumption below about how ASP.NET Core and Node.js, Node.js has little to do with Core, it’s just the recommended way to do client-side assets (JS, CSS, etc). You don’t have to use it, in fact Shannon has worked on porting Client Dependency to Core 1.0 so you can do your asset management entirely in .NET.

 

From: umbra...@googlegroups.com [mailto:umbra...@googlegroups.com] On Behalf Of Devin Bost
Sent: Thursday, 25 February 2016 13:35
To: Umbraco development <umbra...@googlegroups.com>
Subject: Re: ASP.NET 5

 

Aaron, are you suggesting that I should just fork Umbraco and do it myself? 

 

The problem with Umbraco 5 (as alluded to by Niels here: http://umbraco.com/follow-us/blog-archive/2012/6/13/cg12-keynote-video.aspx) is that it was not built on a sound architectural foundation. (Hopefully, I will not offend anybody by this statement.) Good architectural principles make software easier to maintain because they lead to increased simplicity, modularity, scalability, flexibility, and agility.  As Niels said in the CG 12 Keynote, the problems with Umbraco 5 are that it was too complex, had too steep of a learning curve for people, was too hard to maintain, and had not enough community and user support. Niels also said that Umbraco 5 was slow and had performance that did not scale as the number of pages increased. This, in my opinion, indicates that the architecture had room for improvement, which is exactly what lead to the breakthrough developments of Umbraco 6 and 7. Umbraco 7 was so brilliant because it embraced powerful new technologies, including Node.js and AngularJS. This was not just a home-baked architectural innovation. It represented integrating with a foundation supported by Google, an arguably large software development organization, and their open source community (regarding AngularJS), and catching the wave of community support generated by the way that Node.js was changing the way we think about web development. Clearly, that was a risk worth taking; it clearly put Umbraco on the forefront.

 

It is also clear that every aspect of the Umbraco 7 architecture is to embrace Node.js. That is exactly what ASP.NET 5 does. Even if we completely disregard the architectural improvements offered by ASP.NET 5, the fact that it is built on Node.js would at least homogenize the architecture with Umbraco 7 in at least a few ways, which would make it easier and more simple to maintain and develop with. (Notice it will also decrease the learning curve of new developers.) My opinion is also that ASP.NET 5 is simpler and way easier to unit test than previous versions, but that's just my opinion.

 

So, what's the justification for thinking that vNext is going to lead to the next Umbraco 5? ASP.NET 5 is far superior in every architectural aspect that I am aware of, plus it has the entire backing of not only Microsoft, but also the new open source Microsoft community. vNext is here to stay because it makes .NET platform independent, and platform independence is arguably the only reason that developers still continue to develop with Java instead of using the .NET. It is not like we would be depending entirely upon some obscure thing that only a few people can understand and maintain. 

 

So, if we decide to not move forward to embrace a more advanced, easier to maintain technology that is built on a more firm foundation (including the future road-map of Microsoft, who, mind you is collaborating with Google to develop Angular 2), then how is that going to help us? I'm not saying that you're making a bad point; I'm just saying that I want to see more of the logic underneath your opinion because I completely disagree with your position.

 

-Devin

To view this discussion on the web visit https://groups.google.com/d/msgid/umbraco-dev/b2944b65-96b8-4ce4-91a9-a907ea0a697e%40googlegroups.com.

[Devin Bost]

Aaron, thanks for releasing my post and explaining your reasoning. You're making a good point about the plugin model, but I'll admit that I'm not an Umbraco plugin expert. Would you be able to please elaborate a bit more regarding what aspects of the plugin model you're most concerned about?

Also, I was unaware that Shannon is porting Client Dependency to Core 1.0, so I appreciate your clarification about that.

-Devin

[Shannon Deminick]

Hi all,

As Jeroen mentioned, it's worth reading and watching these since Umbraco on ASP.Net Core is discussed there:

Have a look at the Umbraco roadmap. First they are going to build Umbraco 8 which removes a lot of legacy stuff. After that Umbraco 9 will focus on ASP.NET Core 1.0. See slide 43 of the presentation: http://static1.squarespace.com/static/55bf4530e4b0b2984959feba/t/5638d8d6e4b0ce96e2266472/1446566102051/RoadToV8.pdf 

 

There is already a POC: https://github.com/Shazwazza/Umbraco9 

In order to get Umbraco working with ASP.Net core, v8 needs to be completed first and all WebForms stuff needs to be removed/converted. Until this is done, Umbraco will not be able to run on ASP.Net Core. The process of getting Umbraco to work with ASP.Net Core is:

• Get v8 done - this includes migrating to NPoco from PetaPoco since NPoco has a POC running on ASP.Net Core
• Part of v8 is to convert webforms based editors but it is not the goal of v8, so once v8 is out we'd probably still need to convert the remaining webforms
• Determine all dependencies that Umbraco requires and find their equivalent ASP.Net Core versions and help to port over dependencies that Umbraco requires to ASP.Net Core

What Aaron mentions about: 

The biggest challenge that I see with moving Umbraco to the new Core platform is how the Umbraco pipeline works and the plugin model

The routing pipeline has already been created in the POC mentioned above, so that is already taken care of. Regarding Umbraco's plugin model, I have a POC and loads of information about this from spending some time with David Fowler at the MVP Summit in 2014. The way this will work will certainly be different from how we do it today but it will be much much nicer and simpler, this sort of thing is nicely baked into ASP.Net Core. 

To answer your question about the ClientDependency library that works on ASP.Net Core, this is a new library called Smidge: https://github.com/Shazwazza/Smidge 

So the priority is v8, without this we cannot port over to ASP.net Core therefore v8 is the focus right now.