My biggest turnoff about ASP.NET MVC is the lack of documentation, namely a cohesive manual. I find the handful of links to blog posts at http://www.asp.net/mvc/overview ridiculous and absolutely not befitting the only modern web development framework promoted by Microsoft.
Agreed. It feels like I have to get a book to really really learn MVC.
Documentation is one area where it feels like an open source approach is the way to go. Get the community to contribute, along with MS, to a single well-defined structured document.
I work with the ASP.NET team to coordinate some of the content for this site. We're always interested to hear what you like and don't like about the site, what you'd like to see more of, etc. Thoughts?
Not related to the site, but now there is an audience... regarding asp.net mvc:
Can we have support and out of band releases for asp.net mvc without having to go through connect or partner support, which are both to be honest, utter shit?
Also can you get the API right and leave it right so we don't have to piss around for a week with our container and testing environment.
And finally, can you give us something better than razor which has a parser that isn't made of broken twigs and has proper separation of content and programming language (its horrid sorry). Jinja2/django/golang templates FTW.
Oh and sort out SQL 2012 licensing. It's going to cost us £768,000 to upgrade out kit from 2008 to 2012. Postgres migration is an order of magnitude cheaper.
I'm coming from a large asp.net mvc project and its not pleasant, sorry. Welcome to Microsoft centric development!
There are some other view engines available if you don't like Razor. Since you mentioned Django, I'm guessing you've looked at NDjango(http://ndjango.org/index.php?title=NDjango_Home). Another one I've been keeping an eye on is Parrot (http://thisisparrot.com/) - still in development, but I really like the syntax.
After that it got kinda ranty so not sure if I missed some other questions.
I'm talking supported builds, not signed builds. You know with the pile of pre-paid support credits that we get with our partnership agreement which are supposed to result in solutions. Every support call requires a week long argument with the lowest grade of software support who phone me up and ask if they can close the call every day without escalating it. I'm aware of the support options you mention, which basically result in "yes, just limp along with the dependency injection problems with ActionFilters in MVC3 for 6 months" or fork and fix it yourself. We chose the latter, but it's expensive so we might as well forfeit the partner agreement, use Open Source software and pay someone to maintain our forks and contribute patches to the products.
We've looked at NDjango, but it's based on F# and as we well know, unless a product is a mainstream MS platform then it's liable to go out of the window on a whim or is shrouded constantly with uncertainty (choke silverlight, original workflow foundation, XNA? etc).
Sorry if this is rather critical and slightly ranty, but I'm slightly pissed off with maintaining this mess.
Can you send me some specifics (jon dot galloway at microsoft dot com)? At a minimum I'd like to make sure we've got a bug filed on the di / filters issue you mention, but more importantly I want to see what we can do about the support issues you're hitting.
Not sure if you are still watching this thread, but here's my rant. I am the OP.
Positives
---------
The articles posted on your site are top notch. For eg: In the page I see now, I wanted a beginner article on the latest TypeScript buzz, it's there. The WebAPI and Rosyln were fun to read, so was the MVC with TDD and many more articles listed.
Negatives
---------
Someone has mentioned this in a comment here, and I do it again. Why don't we have a community section for Azure, Windows Apps and so on? I find information from the community much easier to understand and practical and makes up for the incomplete MVC and WebAPI documentation. The same goes for other technologies as well.
You can always contact me (@jongalloway or jon.galloway at microsoft.com) with site suggestions. The more official way is to use the Site Feedback link in the site footer. We have weekly meetings with the site dev team, community folks (Scott Hanselman and me) and Scott Hunter (ASP.NET team head PM) and we give high priority to community feedback.
I do know that the Azure site team's looking at expanding community content. They've contacted me to ask about how we handle the community info on the site home page. In case you're interested, here's the overview: http://weblogs.asp.net/jgalloway/archive/2011/06/22/the-asp-...
You can deploy .NET 4.5 to Azure right now if you use the Virtual Machines instead of the SDK. We're running a Windows Server 2012 VM with several .NET 4.5 sites on it right now for advancedrei.com and its supplemental sites.
I've never understood their sick obsession with attributes. When I first started using MVC, I thought it was clever to add HttpPost, HttpDelete, etc... After using a real routing library and then bringing one into my MVC project, it just looks, well... stupid. Gone are my RPC method names. Gone are my untestable Http method -> Action routing. Gone are my magical behavior mixed in due to something in a square bracket.
There is nothing magical about attributes in C#, they are a well defined way to declaratively add meta data to your methods, and I've always found them quite useful and effective.
Here are a few links that may be insightful on how they work:
What's this real routing library you speak of? I actually just started using an Attribute Routing [1] library for my WebAPI project. I like having my routes defined on the methods that will handle them instead of hidden away in the global.
I used AttributeRouting for a fairly large ASP.NET MVC 3 project. I found it really clean and useful - I preferred having the routing information declared on the methods themselves, rather than in some generic routing table, or a single catch-all route. With this library, you don't have to explicitly define a route on every method, there are convention-based approaches, and different levels at which you can define the base route, then more specific routes as you get closer to the methods themselves.
I also used T4MVC, which may have fallen by the wayside, but that kept a lot of the "magic strings" out of the code.
It's good to see Microsoft investing time and resource to recognize community contributions. They should open similar platforms for Mobile, Azure, SQL and Windows Developers too. www.windowsclient.net used to be a good resource for Windows App programmers, but it's been abandoned
Slightly off topic but I'm finding it difficult to find this information: How long are ASP.NET MVC releases supported for with bug fixes? MVC4 is out now and presumably next year MVC5 will be out -- does MVC4 continue to receive bug fixes?
MVC is open source now, so while there may not be official support from Microsoft, I would think bugs there will always be bug fixes as long as someone wants to maintain it.
Not for a minute. The releases are pretty much shelved after v.next. To add to that, the support you do get is crappy, even as a gold partner. ASP.Net MVC is awfully designed and rather buggy as well from experience.
I've been using it on a huge project (145 controllers)since CTP2. I wouldn't use it again.
we're currently investigating werkzeug, python, sqlalchemy and postgresql as a replacement for a new project, particularly also because we got shafted by SQL 2012 per core licensing.
I've built a fair number of medium-small sites with it and like it pretty well...I'm interested in your perspective with such a large project. Why do you think it's awfully designed?
I did just run into a pretty nasty and obscure bug. (That was the first though.)
In my case it manifested on ajax calls but not the initial page load. I had a custom grid that worked fine on the first load but blew up when the user tried to page or sort it. And it only happened on production, because the prod server had the component mentioned in the link installed, but the dev and stage servers didn't.
Luckily the guy administering the web servers tracked down the configuration difference, googled, and found the above link, and I was able to make a small change to my code to work around it, pre-calculating the url on the initial load and just referencing the resulting string on the ajax call (specifically, using lexical closure instead of calculating the url inside a lambda). That fixed it.
They're not really. WebAPI is built on top of MVC, but uses some different base classes (which is annoying as hell at times). [Edit] Plus what vyrotek said [/Edit]
I think it has more to do with getting uptake among the WCF crowd than anything else. IF MS doesn't specifically call it out the folks that had bought into the kool-aid to use WCF for all services probably would never see it. As it is, only 50% of them will see it.
The MS stack has a LOT of 80% developers who are buried in the bowels of some organization happily doing the same thing they've been doing since they first learned .NET.
Heck, I had a call from an organization the other day looking for a senior developer, but they had to have intimate knowledge of a perticular third parties UI control library, because that was what they were using when they wrote the original application in VB6. Couldn't convince them that they probably don't need the 3rd party controls for an HTML app, not could I convince them that any senior developer worth hiring would be able to understand and use said library in a matter of hours if they were truly needed.
Over the last three years I've come to understand that it's I'm not that I'm awesome, it's that most developers are just bad at their jobs (present company probably excluded).
It's a common misconception that Web API is built on or tied to MVC. It's not though. You can use it in a WebForms site just as easily as in an MVC site. You can even self-host Web API outside of IIS entirely.
Also, Web API isn't intended to replace WCF. The "connected systems" people have a whole different set of needs than people building simple web-facing APIs. I don't think we should expect to see WCF or "Add Service Reference" going away anytime soon.
I had totally forgotten about that, although I have seen WebForms used in an MVC site as well.
I did NOT intend to imply that it was a replacement for WCF. I meant to imply that it is a replacement for the WCF REST Starter Kit, and if MS didn't make a huge deal out of it, a lot of people that had gotten used to using WCF for web services would never see it.
Web API is actually built on a completely different HTTP pipeline than ASP.NET products. When it moved to the ASP.NET team, there were a number of changes made to make it feel more natural to ASP.NET devs. Hence the slight variations when you dig under the covers. The question we need to ask ourselves, is why would the ASP.NET team agree to continue to support a completely new HTTP pipeline.
Because unlike ASP.NET it can be self-hosted [1]. It wouldn't surprise me if ASP.NET was moved onto System.Web.Http in the future. Because ever since ASP.NET MVC they have been trying to hide the old System.Web under the new System.Web.Abstractions to support unit testing.
Implementation details. To the person using the products, they are nearly identical, with one being for web sites and one being for APIs. I see no reason why these should be separate. Please explain.
ASP.NET MVC is approx. 3 years old product and to support the features of the current ASP.NET Web API in an elegant way, lots of breaking changes would occur in ASP.NET MVC. This is just one of the reasons. You might also see this one as another impl. detail but it is the brutal truth.
It's pretty impressive to see people who have no idea about the technology they are talking about. ASP.NET Web API doesn't force REST at all! Go learn what that FX does in the first place before leaving comments like this.
The WebAPI project has an interesting history. It was owned originally by the WCF team and then was taken over by the ASP team. A lot of the supporting code for it comes from a new Namespace too. That makes some things slightly annoying when hosting an API in your MVC application.
Two of the main reasons are Display Modes and TAP support.
Also, you don't need ASP.NET MVC 4 to use ASP.NET Web API. Just install Microsoft.AspNet.WebApi package into your existing ASP.NET MVC 3 project, you will be good to go. Just be careful for the order of routes. Both ASP.NET MVC and Web API routes collected under the same collection and a request may go into another pipeline rather than intended one if routes aren't set up properly.
After calling that, you can create a view (index.iphone.cshtml) and it'll be automatically picked up when the condition's matched. This example uses the user agent, but you can use any logic you'd like - cookie / database call / time of day / whatever.
Very nice! What's the best way to develop and debug mobile sites locally? Is there a quick way to force either my browser or VS to go into 'mobile' mode?
Take a look at the great Django manual (https://docs.djangoproject.com/en/1.4/) to see what I mean.