MVC 5 + WebApi 2

[Shannon Deminick]

I wanted to start a discussion on the process of upgrading the Umbraco core to MVC 5 and WebApi 2. I have done a bunch of testing with regards to the upgrade and want to share my results and discuss what are options are to roll out these changes in the core of Umbraco.

Some points to know before thinking about version release options:

• There are breaking changes in MVC 5 and WebApi 2, however these changes will probably not affect many people. They are listed here: http://www.asp.net/visual-studio/overview/2013/release-notes#knownissues
• In some cases if people are affected by these changes, they may need to recompile and fix any compilation errors
• Depending on your project's WebApi usage, you may have to change the global configuration call if you are using WebApi's WebHost as mentioned at the top of this article: http://www.asp.net/mvc/overview/releases/how-to-upgrade-an-aspnet-mvc-4-and-web-api-project-to-aspnet-mvc-5-and-web-api-2 NOTE: Umbraco doesn't make this registration call so this would only affect projects that are using custom WebApi implementations with WebHost
• If you are referencing anything in Microsoft.Web.Mvc.FixedDisplayModes like the FixedRazorViewEngine you will need to recompile
• If you are referencing anything in Microsoft.Web.Helpers you will need to install the latest version (3.x), recompile and fix any compilation errors since the old version method signatures are slightly different and potentially add an assembly redirect
• Unfortunately we cannot ship Umbraco 'as-is' and have developers upgrade their projects to use MVC 4 and WebApi 2
  
• In order to use MVC 5 and Web Api 2 with Umbraco, there are some core code changes required inside of Umbraco to make it work therefore we cannot ship Umbraco and support both MVC 4 and 5 and WebApi 1 and 2.
  
• The upgrade process would be pretty straightforward. During the Umbraco upgrade process we would: 
• Update all web.config files (including those found in /Views folders) to have the correct MVC version details and we'd update all MVC and WebApi assembly redirects correctly
• Remove the old non compatible DLLs from the /bin : Microsoft.Web.Mvc.FixedDisplayModes and Microsoft.Web.Helpers

What about existing packages?

Existing packages will continue to work. I've tested the existing Articulate package and installed it into an Umbraco install running MVC 5 and WebApi 2 and it runs without problems. It's also a good test case because it references MVC and WebApi extensively. As per the above breaking changes however, if a package is referencing the assemblies: Microsoft.Web.Mvc.FixedDisplayModes or Microsoft.Web.Helpers then they probably will not work. I have no idea if any packages reference these libraries though and I would assume that a very small percentage (if any) actually do.

However, it would be a good idea to find out if there would be packages that would break due to this, which ones and how many.

Why might we want to upgrade these libraries?

• MVC 4 / WebApi 1 has been superseded for over 1.5 years
• People cannot actually upgrade their Umbraco projects to MVC 5 / WebApi 2, currently it's impossible without core changes
• Don't want Umbraco core to seem old and out of date
• Various new features in later versions - this includes things like attribute routing, OAuth2, better Identity support, better async ops, easier CORS support, better VS tooling, etc...
• http://www.asp.net/mvc/mvc5, http://www.asp.net/mvc/overview/releases/mvc51-release-notes#new-features, http://www.asp.net/mvc/overview/releases/whats-new-in-aspnet-mvc-52#new-features, http://www.asp.net/visual-studio/overview/2013/release-notes#TOC11, http://www.asp.net/web-api/overview/releases/whats-new-in-aspnet-web-api-21, http://www.asp.net/web-api/overview/releases/whats-new-in-aspnet-web-api-22
• Lots of bug fixes and performance improvements

Umbraco release options

Here's the list of potential release options for including MVC 5 and WebApi 2 in Umbraco:

1. Due to some breaking changes, we wait until Umbraco version 8
• This makes sense with regards to Semver, but  based on the current v8 task list this release might not be available for some time
2. Even though there are some minor breaking changes, we ship a 7.x (perhaps 7.3 or 7.5 or whatever) with MVC 5 / WebApi2
• This doesn't follow semver precisely but the breaking changes are minimal and with the correct documentation, upgrading should be pretty easy
3. Due to some breaking changes we release a Umbraco version 8 instead of the next 7.3 version and move the current version 8 task to version 9
• This makes sense with regards to Semver but that would mean we are actively supporting 3 major versions and then 4 major versions when v9 would be released. 
• People will be hesitant to upgrade because major version changes are a bit scary. 
  
• IMO: this is not a great option
4. We configure the Umbraco project to have 2 different build outputs for the same Umbraco 7.3 version
• With this setup we would actually have 2 'builds' of Umbraco: one targeting MVC4/WebAPI1 and another targeting MVC5/WebAPI2 but the code of Umbraco would be the same and therefore would still be released under a single 7.x version
• This can be done by configuring the sln to have multiple build outputs: Debug, Release, DebugMVC5, ReleaseMVC5. Then for the core code changes required to target each one we can use #ifdef statements in the code. The .proj files then have to be manually updated to reference the correct versions of MVC/WebApi for the specific target
• We would then have 2x the number of downloads on our downloads page and 2x the number of Nuget packages. For example, we'd then have the following Nuget packages: UmbracoCms, UmbracoCms.Core, UmbracoCms.Mvc5, UmbracoCms.Mvc5.Core - it's important to note that the same assembly names and versions would be included across all builds, each build simply targets a different MVC/WebApi version.
5. We setup a nightly build of an MVC 5 / WebApi 2 branch in the core for people to use until v8 is released

If anyone else has other potential release options please let me know. 

Here's the PR if anyone is interested, you could of course just run with a custom build if you wanted :)

https://github.com/umbraco/Umbraco-CMS/pull/608

Looking forward to hearing what people think.

Cheers,

Shannon

[Morten Bock Sørensen]

On Wednesday, December 31, 2014 3:19:15 AM UTC+1, Shannon Deminick wrote:

I wanted to start a discussion on the process of upgrading the Umbraco core to MVC 5 and WebApi 2. I have done a bunch of testing with regards to the upgrade and want to share my results and discuss what are options are to roll out these changes in the core of Umbraco.

In my opinion, a change to the core that means upgrading dependencies to new major versions, should be done in a new major version of Umbraco. The version number is the main way for people who do not read release notes, to identify if this nuget update will have a big impact on the solution.

I would choose either option 1, and bundle it with the rest of the planned features for v8, or option 3, and release a v8 that just contains the MVC WebApi changes.

You concerns with introducing a v8 soon, is that you will be maintaining multiple major versions, but that is not really a question of versions, but a question of whether or not you want to support people who do not want to upgrade MVC. I do not see a big problem with deciding that development will continue in v8, and v7.x will only get critical fixes applied.

Then you could always decide to do a version 8.1 or 8.5 that contains new features, but that do not break anything?

In short, if the MVC upgrade is important enough to do now, it's important enough to trigger a v8 version. Otherwise, wait till v8 will eventually come out.

[Andy Butland]

For me there's a wider question that this touches on, which is how important the version number is for what you might term marketing purposes?  SemVer is a great system from a developer perspective to know and prepare for breaking changes, but it doesn't lend itself to aligning with the release of major features that are worth making a big noise about.

So for example, the release of Umbraco 7 was a big event - rightly so as it had a lot of new features for everyone from developers to editors.  If SemVer is followed strictly, Umbraco 8 could be - perhaps for this, or even for another breaking change not yet considered but potentially important, such as a discovered security issue - much less of a thing to make a song and dance about.

In this sense it would be nice to somehow separate the version number from the more feature driven release cycle.  That way the major version could ramp up as fast as you like strictly following SemVer.  But you would also have more marketing driven releases - like Apple's big cats ("Snow Leopard" etc.), or Microsoft's "VIsta" (OK... that one not a great example!).

Andy

[Morten Bock Sørensen]

On Wednesday, December 31, 2014 12:11:52 PM UTC+1, Andy Butland wrote:

In this sense it would be nice to somehow separate the version number from the more feature driven release cycle.  That way the major version could ramp up as fast as you like strictly following SemVer.  But you would also have more marketing driven releases - like Apple's big cats ("Snow Leopard" etc.), or Microsoft's "VIsta" (OK... that one not a great example!).

I think this is a very good point. I could be difficult to find a good naming strategy though, so maybe it would be enough to just accept that not all major semver updates needs the big song and dance. However, the song and dance would probably most likely align with some of the major semver versions. So a release sequence could look something like:

• New backend
• semver 7.0
• Big marketing splash
• The Grid
• semver 7.2
• Big marketing splash
• MVC5
• semver 8.0
• No marketing
• Content versioning and segmentation (?)
• semver 9.0
• Big marketing splash
• Some breaking change
• semver 10.0
• No marketing
• Features x, y, z
• semver 11.0
• Big marketing splash

And so on...

/Bock

[Aaron Powell]

Thanks for the write-up Shannon, the one thing I find interesting is that Umbraco has some hooks into MVC which tie an Umbraco release to a specific version of MVC. This I see as a bigger problem than the question of Umbraco supporting MVC 5/WebAPI 2.

 

My “ideal world” would be Umbraco isn’t tied to any specific MVC/WebAPI version leaving me free to drop in which ever one I want/need to use, well within reason, like I don’t expect Umbraco to support MVC 1, but fact that I’d need to change the core to support the version bump is what I have issues with.

--
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/dbca9f76-4957-4a56-b378-4cf81a16dd93%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Aaron Powell]

I’m going to disagree with you two here, SemVer is important and should be tied to feature development. The point of SemVer is to give developers a level of confidence around releases and that they won’t change their behaviour unexpectedly.

 

As someone who is building extensions on Umbraco the fact that it isn’t SemVer is really frustrating, there were some changes between 7.0 and 7.1 that weren’t backwards compatible, meaning trying to make extensions to cover both can be difficult.

 

Throwing that out for an arbitrary versioning scheme makes cross-version extensions really hard. I’d much prefer SemVer, that major versions bring new features, be it MVC major version bumps or a new backend.

--

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/0595126d-8fe4-40e8-b5cb-a3cabbe06e14%40googlegroups.com.

[Morten Bock Sørensen]

On Thursday, January 1, 2015 7:44:14 AM UTC+1, Aaron Powell wrote:

Throwing that out for an arbitrary versioning scheme makes cross-version extensions really hard. I’d much prefer SemVer, that major versions bring new features, be it MVC major version bumps or a new backend.

Aaron, I don't see any of us arguing that SemVer should be thrown away? We're simply just saying that not all of the major SemVer versions need to be released at codegarden. If breaking changes need to be made, then just bump the version number. Of course that does not mean that breaking changes should be made all the time, but if MVC5 is a big deal to users, then put it in, and bump the version. That's all I'm saying.

/Bock

[Damiaan Peeters]

I really like the idea out of band release (solution 5).  It supports a need for dev's while you maintain semver.  Depends a littlebit on the timeframe v8 is being planned.

On Wednesday, December 31, 2014 3:19:15 AM UTC+1, Shannon Deminick wrote:

[Aaron Powell]

Sorry Morten, I must have misinterpreted the points you were making on naming vs versioning.

 

From: umbra...@googlegroups.com [mailto:umbra...@googlegroups.com] On Behalf Of Morten Bock Sørensen
Sent: Thursday, 1 January 2015 8:41 PM
To: umbra...@googlegroups.com
Subject: Re: MVC 5 + WebApi 2

 

On Thursday, January 1, 2015 7:44:14 AM UTC+1, Aaron Powell wrote:

--

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/94359548-cc09-4d08-9beb-48e00837d68b%40googlegroups.com.

[Shannon Deminick]

@Aaron - I would also love it if we had a codebase that supported both MVC4/5 and WebApi1/2 but it's not possible because of Microsoft's changes. As noted, this is mostly due to their backward compatibility changes for these assemblies: Microsoft.Web.Mvc.FixedDisplayModes, Microsoft.Web.Helpers. There's a reason MS had to make major version changes too since their code isn't 100% backwards compatible. I'm not sure why you see this as a 'bigger' problem, it's just the way things are and is outside of our control. That said, there is a pretty ugly way that we can make Umbraco's core support both: We create a separate DLL called Umbraco.Web.FixedDisplayModes which contains the fixed view engines and replaces the normal ones on startup. We use reflection to apply this logic (rev: 38f3e3dd6876fdec9fe649579390c91d710da2ee) to see if HttpRequestMessage has a RequestContext property.

If we did that for the next 7.3 release, then people would be able to upgrade their installs themselves but would need to follow both MS's instructions: http://www.asp.net/mvc/overview/releases/how-to-upgrade-an-aspnet-mvc-4-and-web-api-project-to-aspnet-mvc-5-and-web-api-2 and our own custom instructions since people would also need to remove a new Umbraco.Web.FixedDisplayModes assembly. 

So I suppose this could be an option #6 

The other question we need to ask is how important people think having MVC 5/WebApi 2 support is, or if people would simply just be happy to wait for the upgrade in v8.

[Niels Hartvig]

Great discussion!

In the enthusiasm in finding a versioning vocabulary in SemVer, I think we forgot to ask ourselves what do we think is a breaking change.

In the simple world it's an easy binary answer, but Umbraco is also a bigger and older project than your average simple nuget package with everything that follows and as such we'd be on version 13(!) today if we should have been following SemVer religiously. In that light, it's worth considering whether SemVer actually is the Nirvana we hoped.

Ignited by David Heinemeier Hansson, there's a great discussion in the Rails community about SemVer being an illusion in practice:

https://gist.github.com/jashkenas/cbd2b088e20279ae2c8e

Best,

Niels...

On Wednesday, December 31, 2014 3:19:15 AM UTC+1, Shannon Deminick wrote:

[Aaron Powell]

The reason the strict dependency in Umbraco is a problem for me is that Umbraco is a CMS, it’s good at doing content management but it is not good at describing how I should write my application.

 

One thing that I’ve always liked about Umbraco over other CMSs that I’ve used is that it gets out of my way in generating HTML, meaning I can do as crazy a HTML design as my designers come up with. I’d like a similar thing with the dev side, if I want to use MVC5 Umbraco shouldn’t prevent me, it shouldn’t have to ship it in-the-box but through binding redirects there should be no reason I should have to recompile Umbraco.

 

From: umbra...@googlegroups.com [mailto:umbra...@googlegroups.com] On Behalf Of Shannon Deminick
Sent: Friday, 2 January 2015 11:19 AM
To: umbra...@googlegroups.com
Subject: Re: MVC 5 + WebApi 2

 

@Aaron - I would also love it if we had a codebase that supported both MVC4/5 and WebApi1/2 but it's not possible because of Microsoft's changes. As noted, this is mostly due to their backward compatibility changes for these assemblies: Microsoft.Web.Mvc.FixedDisplayModes, Microsoft.Web.Helpers. There's a reason MS had to make major version changes too since their code isn't 100% backwards compatible. I'm not sure why you see this as a 'bigger' problem, it's just the way things are and is outside of our control. That said, there is a pretty ugly way that we can make Umbraco's core support both: We create a separate DLL called Umbraco.Web.FixedDisplayModes which contains the fixed view engines and replaces the normal ones on startup. We use reflection to apply this logic (rev: 38f3e3dd6876fdec9fe649579390c91d710da2ee) to see if HttpRequestMessage has a RequestContext property.

--

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/c0667953-24d0-4fad-929d-4bcf795c9d75%40googlegroups.com.

[Aaron Powell]

This is a challenge of product development where extensibility is a core feature (for extensibility I’m not just talking about creating packages but also creating sites that have functionality other than plain content publishing).

 

For me this comes back to my previous comment, that Umbraco is great at content but I want it to get out of the way when I build my application.

 

From: umbra...@googlegroups.com [mailto:umbra...@googlegroups.com] On Behalf Of Niels Hartvig
Sent: Friday, 2 January 2015 8:51 PM
To: umbra...@googlegroups.com
Subject: Re: MVC 5 + WebApi 2

 

Great discussion!

--

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/84a3a758-151f-4b9d-a34f-43b91a134f8c%40googlegroups.com.

[Shannon Deminick]

Did you read my points above? There's a reason Microsoft made their own major version changes... Because they've made breaking changes in their code and in their own compatibility with their own assemblies. We have a product that is built on these assemblies, I'm not sure how we would have been able to predict the future and what breaking changes would have come in newer versions of assemblies we reference. Also you cannot avoid a recompilation if Microsoft's breaking changes affect you... Again this is out of our control.

I've listed 6 possible solutions for moving forward and dealing with the upgrade, including an option where we could release a version that would allow you to upgrade manually with assembly redirects. Would love to hear some opinions on any of those options or any idea's for options that haven't been proposed.

Sent from my phone

You received this message because you are subscribed to a topic in the Google Groups "Umbraco development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/umbraco-dev/jSL0wpddCiY/unsubscribe.
To unsubscribe from this group and all its topics, 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/BLU402-EAS722C70FE03F0D6B7DF0838EE5B0%40phx.gbl.

[Lee Kelleher]

> The other question we need to ask is how important people think having MVC 5/WebApi 2 support is, or if people would simply just be happy to wait for the upgrade in v8.

I guess this is the crux of it; how much demand is there for immediate MVC 5 support?

Judging from the issue tracker, it seems more of a "would be nice", rather than "need it right now".

I'd go with Option #1 (wait until v8). Then if there's a demand for it sooner, we explore Options #5 and #6. (Although #6 is hacky, I think it would work well for implementers)

re: SemVer - all valid points, I think it's worth more discussion, (on a separate thread).

Cheers,
- Lee

[Andy Butland]

As regards the specific issue of MVC5/Web API 2 support, from recent projects I've worked on with Umbraco I can't say I've found an absolute need for this, so I'd concur with the "nice to have" view and could wait for V8.  

Having said that though, on the wider point it does seem to me to be an issue that if features or upgrades are useful - as indicated by Shannon's points in his original post - and are ready for release, if they are held back for perhaps many months due to being stuck between the two unpalatable options of not maintaining consistency with SemVer or bumping the major version number prematurely from a features/marketing perspective.  Not sure what the answer to that is, but as Lee says, should be discussion for another thread... 

Andy

.

[Devin Bost]

Personally, I am very interested in the OAuth2 features. (This was actually a deal breaker for a project I worked on.) I think there could be a lot of potential in integrating OAuth2 with the existing member management features. (For example, I would like to combine members registered via OAuth2 with the existing role-based security features. That would make it super easy to add new OAuth2 users to existing security groups.) However, I don't know how important these features would be for other members of the group. 

Personally, I would prefer these features sooner than later. I do understand, however, that these would not be small changes (in terms of impact). How far out would v8 be (in terms of time)?

-Devin

[Shannon Deminick]

Hi everyone,

I decided tonight to create a new PR which 'should' in the short term solve this problem for everyone. The PR is here:

https://github.com/umbraco/Umbraco-CMS/pull/617

If we choose to accept this for Umbraco 7.3.0, it would mean that you can fairly easily upgrade your own solution to use the latest versions of MVC and WebApi by following Microsoft's upgrade procedures and using Nuget. All the details are in the PR. I've tested this just now and it works perfectly. I think this is a good option for us until version 8 is released.

Let me know what everyone thinks.

[Peter Josefson]

Hi,

Is this implemented already? I did an experiment the other night on a 7.2.2, lifting MVC and WebAPI to the latest NuGet versions. Umbraco seems happy, I am happy. Had to find a couple of packages that were needed as well to get it rolling, but it was fairly unproblematic (had YSODs about missing stuff first). No biggie, EXCEPT that I can't figure out how to do route configuration via App_Start (as it's not there), and I haven't even tried attribute routing (yet). Haven't needed that part, though, I'm mostly POSTing my requests - no query parameters needed.

I'm developing against that solution now - maybe I'll stumble onto something - we'll see. We have a mobile app, a web page angular.js app and an umbraco custom section working with the API:s (one public and one - the backend - authenticated), and it works like a charm so far.