Can I run a MVC 1 application using the MVC 2 assemblies without a hitch? I understand that some 3rd party tools have had stuff broken in MVC 2, but let's assume I'm not using those any other tools.
There have been breaking changes.
If you want a 1.0 project to run on 2.0, it does look for things in different places; so you'd have to migrate the application to 2.0..
Here are the changes that could possibly 'break' (current as of Preview 2):
Changes in Preview 2
Helpers now return an MvcHtmlString object
In order to take advantage of the new HTML-encoding expression syntax in ASP.NET 4, the return type of the HTML helpers is now MvcHtmlString instead of a string. Note that if you use ASP.NET MVC 2 and the new helpers with ASP.NET 3.5, you will not be able to take advantage of the HTML-encoding syntax; the new syntax is available only when you run ASP.NET MVC 2 on ASP.NET 4.
JsonResult now responds only to HTTP POST requests
In order to mitigate JSON hijacking attacks that have the potential for information disclosure, by default, the JsonResult class now responds only to HTTP POST requests. AJAX GET calls to action methods that return a JsonResult object should be changed to use POST instead. If necessary, you can override this behavior by setting the new JsonRequestBehavior property of JsonResult. For more information about the potential exploit, see the blog post JSON Hijacking on Phil Haack’s blog.
Model and ModelType property setters on ModelBindingContext are obsolete
A new settable ModelMetadata property has been added to the ModelBindingContext class. The new property encapsulates both the Model and the ModelType properties. Although the Model and ModelType properties are obsolete, for backward compatibility the property getters still work; they delegate to the ModelMetadata property to retrieve the value.
Changes in Preview 1
DefaultControllerFactory class changes break custom controller factories that derive from it
This change affects custom controller factories that derive from DefaultControllerFactory . The DefaultControllerFactory class was fixed by removing the RequestContext property and instead passing the request context instance to the protected virtual methods GetControllerInstance and GetControllerType.
Custom controller factories are often used to provide dependency injection for ASP.NET MVC applications.
To update the custom controller factories to support ASP.NET MVC 2, change the method signature or signatures to match the new signatures, and use the request context parameter instead of the property.
“Area” is a now a reserved route-value key
The string “area” in Route values now has special meaning in ASP.NET MVC, in the same way that “controller” and “action” do. One implication is that if HTML helpers are supplied with a route-value dictionary containing “area”, the helpers will no longer append “area” in the query string.
If you are using the Areas feature, make sure to not use {area} as part of your route URL.
Known Issues
The Add View dialog box throws a NullReferenceException when the Create strongly-typed view check box is checked, a View Content selection other than “Empty” is selected, and a View data class type name is specified for a type that does exist. When specifying a type name, either use the drop-down list to select the type name or type the fully-qualified type name. For types that do not exist, you must set View Content to “Empty”.
Check out this document. You'll learn about the breaking changes :
http://go.microsoft.com/fwlink/?LinkID=157072
One gotcha that has bitten me is that all the fields of a model are now always validated on a post.
The changes is described by Brad Wilson here.
Steve Anderson's blog post describes the issue and my favorite solution (using a custom validator).
Related
I have an ASP.NET WebApi application that has some controller methods that expect certain strings to be passed in as method parameters (declared as part of the route template).
On all the methods, the strings passed in are base64-encoded -- which means each controller method must base64-decode them before doing anything with them. While I can obviously have each method do this easily enough, I was wondering if there was a way to perform the decoding before the string actually gets passed to the controller method. I presume this is something along the lines of an action filter or custom formatter, but I'm not familiar enough with asp.net web api to know where to start on that?
Summary:
I've got route templates like : {controller}/{encodedString}/whatever
where {encodedString} is always a base64-encoded string.
and controllers with methods like
GetWhatever(string encodedString)
{
Base64Decode(encodedString);
// do other stuff...
}
I would like to use some part of the asp.net webapi pipeline to decode {encodedString} before the controller method is actually called. What path should I start down in order to do this?
You can create a custom model binder and attach it to the parameters using the ModelBinderAttribute. In the model binder you then do the base64 decoding.
For a reference on parameter binding in Web API check:
How WebAPI does Parameter Binding
I need to extend asp:Menu to support linking to MVC routes (my project has a mix of MVC and non-MVC pages). My menu is generated using a custom class which determines if a user should be shown a node based on their priveleges to the file it referes to.
MVC pages are restricted using the AuthorizeAttribute. Avoiding mocking (if possible) I want to
Determine if the path refers to an MVC page or a standard page
If MVC, determine if the user has the rights to access it
Here's my method signature inside the menu generation class:
Private Function CanAccessPage(path As String) As Boolean
Here's the algorithm I used for this,
Based on #SLaks answer here, I was able to determine if the path referred to an MVC route.
If it was MVC, I grabbed the controller type (this required knowing what namespace my controller's were in)
Got the action method by controllerType.GetMethods(actionMethodName) (if you have multiple methods with the same name, you must pick the one your link refers to. Probably the one with an HttpGet attribute).
Used actionMethodInfo.GetCustomAttributes(GetType(AuthorizationAttribute), False) to get a collection of all authorization filters for the specified action
Called OnAuthorization with the fake context info I build in step 1 for each attribute.
Check if TypeOf filterContext.Result Is HttpUnauthorizedResult and return accordingly
Using ASP.NET MVC 3 I would like to render different "templates" (i.e. partial views or whatever you want to call them) to my views based upon the type of the view model (or a property on the view model) supplied at runtime.
I understand the out-of-the-box ASP.NET MVC functionality enables the addition of a UIHint attribute to a property or field on the viewmodel supplied to the view, but as far as I can tell this doesn't meet my needs as I won't know the template required until runtime.
AFAICT ASP.NET doesn't support generic viewmodels of type T either, so my idea is to take the ASP.NET MVC3 source code and write my own DisplayFor method that accepts a viewmodel instance (specified by it's abstract base type in the view), which resolves the actual type at runtime and uses this to find the template name by convention.
Does this sound feasible/worthwhile?
The view would look thus (note specification of base type, a concrete instance would be supplied at runtime):
#model MyViewModelBase
#{ DisplayFor(Model); }
Viewmodel:
public class MyMagicalViewModel : MyViewModelBase {}
Invocation of this view would look thus:
...
return View("MyView", MyMagicalViewModel);
...
...and this would return html corresponding to the MyMagicalViewModelPartialView.cshtml
Have you looked into Html.EditorFor?
I am using in my views (asp mvc3/razor cshtml) references to the Request object (eg, #Request.Params["Name"]). Do you think this is a very bad practice? Should I rewrite the value in the controller Request.Params ["Name"] to ViewBag.Name and then use it in the view (#ViewBag.Name)?
Best practice is to use a model class. An instance of the model class is created or updated in your controller. Then the controller displays a strongly-typed view.
So I'd avoid direct access to the request from the view as well as the use of the view bag.
Should I rewrite the value in the controller Request.Params ["Name"] to ViewBag.Name and then use it in the view (#ViewBag.Name)?
Yes. You will avoid runtime errors if "Name" does not exist.
The IDE will not warn you of the NullReferenceException about to be thrown with the following code.
#Request.Params["Fake"].ToString()
Of course, you'll have to be careful about ViewBag.Fake being null as well.
I like to use the viewbag to store things not related to the model, for example if I have a dropdown containing locations. I like to store only the id of the selected location on the model and the locations in the viewbag, since is not needed to create a contact. I think that's the purpose of the viewbag.
For me the model is a bag or properties used in business operations, for example if I have a customer creation view using a NewCustomerModel, I don't wanna pollute my model with things like a IList<CustomerType> AND a SelectedCustomerTypeId property. I just want the second since is the one imma use to create the customer.
Enterprise Library Validation Application Block (VAB) integrates with ASP.NET and also with WCF.
Is there a way to integrate ValidationResults created in WCF with ASP.NET?
e.g. an ASP.NET web page invokes a WCF service. The WCF service validates the data using VAB and returns validation information via a FaultContract. The ASP.NET page can take the results and display some error messages. However, a common approach is to indicate which fields have errors (e.g. inline message or asterisk). It seems that most of these approaches will involve being able to correlate the validation result with a control or with a validator.
I don't think there is an out of the box solution but was also curious if anyone had done this and what their approach was.
Since there is no out of the box solution and there aren't any answers posted, I will share what I implemented. I'm not in love with the approach but it is working for me.
Overview
The basic approach is for the ASP.NET page to populate a mapping between properties on the DataContract objects to the ClientId of the control that is being validated. When a validation error occurs the ClientId is returned back from the service to the asp.net page as part of a FaultContract. Then the details from the FaultException are extracted; the ASP.NET page retrieves the ClientId of the control that caused the error and appropriate action can be taken (e.g. change control look and feel or set the text on a validator).
Details
All of the DataContract objects inherit from a base class that exposes a Dictionary. This dictionary is used to map object properties to ASP.NET controls. In the Dictionary, the key is the property name on the DataContract object and the value is the ClientId of the control. Before invoking a service, the client must attach the Dictionary to the DataContract object.
When a ValidationResult is created by Enterprise Library it contains a property called Target which is the object that was validated. ValidationResult also contains a property called key which is the name of the property from the target object that was validated. The ValidationResult key is also a key into the Dictionary that was set in the ASP.NET page before calling the service.
With the ValidationResult key, the ASP.NET supplied information (ClientId) can be extracted from the ValidationResult Target. The information is then added as the Tag of the ValidationResult. Unfortunately, Tag is a readonly property so it has to be set by creating a new ValidationResult and passing the tag to the constructor.
The collection of ValidationResults is then transformed to a pre-existing CustomValidationResults collection (which looks just like ValidationResult) that we needed to use. The CustomValidationResults are then added to a custom ValidationFault and a FaultException is thrown.
The ValidationFaults are then extracted from the FaultException in the ASP.NET page. The ValidationFault contains the ClientId of the control which is associated with the error so the page can choose to display the Messages as it sees fit.