We are investigating adding these capabilities to System.Web based applications
Sorry, the GitHub link was incorrect. I've removed it from the status for this suggestion.
We are planning to provide a common service provider abstraction for web applications.
We are addressing this feature request in ASP.NET vNext (http://www.asp.net/vnext), which introduces a central abstraction for dependency injection. Out of the box we provide a simple IoC container to bootstrap the system, but you can easily replace it with your IoC container of choice. You can follow our progress on ASP.NET vNext at http://github.com/aspnet.
This is planned for a future version of ASP.NET MVC.
We currently support closed generics. Is that sufficient? Or is the request here specifically about open generics?
Support for output caching is tracked on our CodePlex site here: https://aspnetwebstack.codeplex.com/workitem/608. Please add your vote to the CodePlex issue if you want this feature!
This won't be in Web API 2.2. We are considered adding this for the next major release of Web API, but this is still under investigation.
In the meantime there are third party implementations that you can look at using:
Updating the status of this suggestion to declined based on user feedback.
While ASP.NET MVC does not support multi-tenancy directly, it is possible to build support for multi-tenancy on top of ASP.NET MVC today. For an example of how to achieve multi-tenancy you can take a look at Orchard (http://orchardproject.net/), which is a multi-tenant CMS and web framework built on ASP.NET MVC.
To be clear, you can absolutely build multi-tenant apps on top of ASP.NET MVC. There are a variety of ways to build the relevant features (multi-tenant authentication, database isolation, configurable modules and theming, etc). Instead of building these features directly into MVC we believe these features are best built on top MVC. We contribute heavily to Orchard as one such implementation. Orchard is both a CMS and a web framework for building multi-tenant apps all built on ASP.NET MVC. Even better it's fully OSS and free. Orchard isn't the only way to do multi-tenancy on MVC but if we were to do multi-tenancy we would basically be re-implementing the underlying framework support in Orchard.
Moving this back onto our backlog based on customer feedback.
Regarding the comments about client side validation the blog post does have a 2nd part that describes how to setup client side validation: http://blogs.msdn.com/b/stuartleeks/archive/2012/09/07/flexible-conditional-validation-with-asp-net-mvc-adding-client-side-support.aspx.
This item was incorrectly marked as completed previously
This should just work for the Web API project template. Could you walk us through what you tried and what didn't work?
Thanks for this suggestion! Could you please provide links to the comments that you found on the web so that we can take a look at them?
We do support multipart/form-data in ASP.NET Web API. The support is somewhat different than the MVC support because ASP.NET Web API uses formatters to handle the request body instead of model binding. This means you get the form data as a single object instead of potentially multiple parameters. The benefit of this approach is that you get a convenient formatting abstraction for dealing with multiple formats (XML, JSON, OData, etc). The downside is that the programming model is not as nice for dealing with form data.
You can override how ASP.NET Web API does parameter binding to get the MVC behavior. Ex see http://blogs.msdn.com/b/jmstall/archive/2012/04/18/mvc-style-parameter-binding-for-webapi.aspx. The extension is already available in WebApiContrib. We are considering adding it to the core runtime. If this is what you want, then could you please add a specific suggestion for this feature so that it can be voted on?
As for JSONP, it's not supported by MVC today, although you can implement support for it. The same is true for ASP.NET Web API and there is a JSONP implementation available in WebApiContrib. we are definitely looking at adding cross domain support to ASP.NET Web API including JSONP and CORS. Vote for this UserVoice item if this is what you want: https://aspnet.uservoice.com/forums/147201-asp-net-web-api/suggestions/2632112-out-of-the-box-jsonp-formatter.
Could you please provide an example of model binder arguments that you would like to rename or exclude?
Looking at your blog post I believe you highlight four issues:
1. Why do you need to specify a route name to generate a link when the MVC UrlHelper.Action(…) method don’t require you to specify one?
- Looks like the behavior of MVC is to iterate over the routes and pick the first one that happens to work. Is this the desired behavior?
2. Cannot foreach loop over HttpRouteCollection
3. No way to get the name of a route from the route or the route collection
- This is really an issue with ASP.NET Routing, although it is aggravated by Web API requiring the route name to generate links.
4. Creating a Web API UrlHelper should only require the request, not the controller context
- Fixed! You can create a UrlHelper with just the request.
Help Page generation for ASP.NET Web API is now included with the preview of the ASP.NET Fall 2012 Update (available at http://www.asp.net/vnext).
Thanks for this suggestion!
Have you had a chance to take a look at the ASP.NET Web API Help Page preview?:
The ASP.NET Web API Help Page preview adds help page support to any web API. You simply add the NuGet package, configure it however you'd like and you are good to go. Unlike the WCF help page we use Razor views to generate the help page content which you can then customize and style to match the rest of your web site. This feature is still just a preview so your feedback is much appreciated!
You now have the ability to register per route message handlers by specifying the message handler in the MapHttpRoute method.
[AllowAnonymous] is also supported with [Authorize] today.
At level of granularity would you want to be able to exclude message handlers from processing a given request?
We do already support a Web API version of [AllowAnonymous]. What issue are you running into when using [AllowAnonymous]?
For great support for the real-time web please use ASP.NET SignalR:
We recommend using SignalR for notification and callback patterns: https://github.com/SignalR/SignalR.
Going forward we plan to productize SignalR and integrate it with ASP.NET Web API.
We have updated the IDependencyResolver abstraction to support dependency scopes.
We are now tracking this issue in the Issue Tracker on our new CodePlex. Please take a look at the proposed resolution and post any feedback you have as comments:
We are avoiding dependencies on statics due to the issues they cause with async code and unit testing.
For error handling situations you can implement an IExceptionFilter, which has access to the request message.
Actually, it would really help if you could identify for us the specific places where you needed access to some context but it wasn't available so that we can ensure that we have fixed your specific cases.
As you mentioned, we are avoiding dependencies on statics due to the issues they cause with async code and unit testing.
However, we are doing work to ensure that the request is available everywhere that it should be.
We need more clarity on what the issue is here – the link provided returns a 404 Not Found. Does this issue still exist in our released bits?
I believe you are seeing this exception because you need your web api host to provide a Silverlight policy file:
We now support per-controller configuration by applying an attribute to your controller that implements IControllerConfiguration.
I assume you are referring to supporting multiple configurations when web hosted, correct?
You can now use the Async Targeting Pack for Visual Studio 2012 to use the new await keyword when targeting .NET 4, so we don’t believe adding sync APIs is needed:
There are cases where .Result and .Wait() can be dangerous, so we are considering making safe synchronous versions of the HttpClient APIs available. In general, blocking the thread is a bad thing, but writting correct async code on .NET 4 is still very difficult. Vote this one up if you think this is important.
We don't currently plan on providing support out of the box for the Allow header or OPTIONS requests, but it should be possible to enable this yourself in a cross cutting way using action filters. We are certainly interested in hearing though if the community thinks this needs to be in the box.