What issues or refactoring did you have to do when you upgraded from ASP.NET MVC Preview 5 to the newly released Beta version?
Issue number one: Yellow screen of death.
CS0234: The type or namespace name 'Mvc' does not exist in the namespace 'System.Web' (are you missing an assembly reference?)
Solution: I removed all references in my project and re-added them, pointing to the assemblies in program files\asp.net\asp.net mvc beta\assemblies, but that didn't solve the problem.
I had a system.web.mvc dll in the gac (no idea how). Tried to delete it. Unable to; assembly is required by one or more applications. Had to find the assembly as described here and delete the registry entry. I was then able to remove the gac's version of system.web.mvc.
This STILL didn't fix the problem. I had to RE-ADD the references AGAIN. Now its working.
Just to be clear!!! The beta assemblies were dropped under Program Files, while an older version of System.Web.Mvc was in the GAC.
I'm about to do this myself. Here's the list of changes from the readme:
Changes Made Between CodePlex Preview 5 and Beta
Changed the default validation messages to be more end-user friendly.
Renamed CompositeViewEngine to AutoViewEngine.
Added a Url property to Controller of type UrlHelper. This makes it convenient to generate routing-based URLs from within a controller.
Added the ActionNameSelectorAttribute abstract base class, which serves as the base type for ActionNameAttribute. By inheriting from this base attribute class, you can create custom attributes that participate in action selection by name.
Added a new ReleaseView method to IViewEngine that allows custom view engines to be notified when a view is done rendering. This is useful for cleanup or for view-pooling scenarios.
Renamed the ControllerBuilder method DisposeController to ReleaseController to fit with the pattern that is established for view engines.
Removed most of the methods on the HtmlHelper class, converting them to extension methods of the HtmlHelper class instead. These methods exist in a new namespace (System.Web.Mvc.Html). If you are migrating from Preview 5, you must add the following element to the namespaces section of the Web.config file:
<add namespace="System.Web.Mvc.Html"/>
This makes it possible for you to completely replace our helper methods with your own.
Changed the default model binder (DefaultModelBinder) to handle complex types. The IModelBinder interface has also been changed to accept a single parameter of type ModelBindingContext.
Added a new HttpVerbs enumeration that contains the most commonly used HTTP verbs (GET, POST, PUT, DELETE, HEAD). Also added a constructor overload to AcceptVerbsAttribute that accepts the enumeration. The enumerated values can be combined. Because it is possible to respond to HTTP verbs that are not included in the enumeration, the AcceptVerbsAttribute retains the constructor that accepts an array of strings as a parameter. For example, the following snippet shows an action method that can respond to both POST and PUT requests.
[AcceptVerbs(HttpVerbs.Post | HttpVerbs.Put)]
public ActionResult Update() {...
}
Modified the RadioButton helper method to ensure that every overload accepts a value. Because radio buttons are used to specify a choice from a set of possible values, specifying a value for a radio button is necessary.
Made modifications and fixes to the default project template. This includes moving script files to a new Scripts folder. The default template uses the ModelState class to report validation errors.
Changed action-method selection. If two action methods match a request, but only one of those has an attribute that derives from ActionMethodSelectorAttribute that matches the request, that action is invoked. In earlier releases, this scenario resulted in an exception.
For example, the following two action methods are in the same controller:
public ActionResult Edit() {
//...
}
[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Edit(FormCollection form) {
//...
}
In Preview 5, a POST request for the Edit action would cause an exception, because two methods match the request. In the Beta, precedence is given to the method that matches the current request via the AcceptVerb attribute. In this example, the first method will handle any non-POST requests for the Edit action.
Added an overload for the ViewDataDictionary.Eval method that accepts a format string.
Removed the ViewName property from the ViewContext class.
Added an IValueProvider interface for value providers, along with a default implementation, DefaultValueProvider. Value providers supply values that are used by the model binders when binding to a model object. The UpdateModel method of the Controller class has been updated to allow you to specify a custom value provider.
I experienced the same problem as Will and had to do similar things as him, including copying the dlls to the bin folder.
Now things are working in the internal vs.net server but are causing IIS7 to crash.
Ok, it turns out one of the major problems is that I missed the step to update the compilation assemblies in the web.config:
<add assembly="System.Web.Mvc, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
All i had to do was update the assemblies from
%ProgramFiles%\Microsoft ASP.NET\ASP.NET MVC Beta
Also get the most recent Microsoft.Web.MVC from codeplex
to update my futures assembly too.
add in 2 lines to the web.config
This one to the <assemblies> Section:
<add assembly="System.Web.Mvc, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
This one to the <namespaces> section:
<add namespace="System.Web.Mvc.Html"/>
Then i had to update all the <%using (Html.Form()) to <%using (Html.BeginForm())
On one code file i had to add the System.Web.Mvc.Html; namespace
My stuff is based on Rob Conery's MVC Storefront, so anyone using that should be able to follow the above.
Hope it helps someone out there.
Disregard this... I'm a loser - it's Microsoft ASP.net in program files... not just ASP.net
Maybe this should be a second question, but I think keeping it all in one place might help.
When running the Beta installer nothing ends up changing on my PC. I don't see the folder in the Program Files folder... no assemblies are added to the GAC... even the installer gets to the last step and then hangs for around 10 minutes or so.
I've uninstalled and reinstalled a couple times now without any luck.
Anyone having a similar problem?
The problem with AutoFac has now been resolved in Revision 454 of the AutoFac code base
http://code.google.com/p/autofac/issues/detail?id=86&can=1
Im trying to find out how the new ModelBinder works, as far as I can see it's very different, but i haven't managed to find out how it works yet..
My old looked like:
public class GuestbookEntryBinder : IModelBinder
{
#region IModelBinder Members
public object GetValue(ControllerContext controllerContext, string modelName, Type modelType, ModelStateDictionary modelState)
{
if (modelType == typeof(GuestbookEntry))
{
return new GuestbookEntry
{
Name = controllerContext.HttpContext.Request.Form["name"] ?? "",
Website = controllerContext.HttpContext.Request.Form["website"] ?? "",
Message = controllerContext.HttpContext.Request.Form["message"] ?? "",
};
}
return null;
}
#endregion
}
The new one looks like:
#region IModelBinder Members
public ModelBinderResult BindModel(ModelBindingContext bindingContext)
{
throw new NotImplementedException();
}
#endregion
Any hints?
I use Autofac as my DI container. A null container exception gets thrown when trying to dispose of the container objects.
Yup, also use Autofac as DI container.
Get same issue as this guy
http://groups.google.com/group/autofac/browse_thread/thread/68aaf55581392d08
No idea if a fix is possible but cant continue until this is fixed ......
After struggling with this for most of the day, I figured I'd post my solution here. Maybe this is normal Visual Studio behavior but I never noticed it before...
On my existing project, I actually had to manually move the Beta files to the Bin folder. For whatever reason, just browsing to it with Add Reference wasn't working...
Html.TextBox - value now is object, not string.
So, hidden errors possible (not at compile time and even not at runtime), for example I've used this overloaded method earlier Html.TextBox(string name, object htmlAttributes). Now my attrs go into textbox value.
About the Autofac issue. There is a thread on the autofac discussion group about the need to update the controller factory to be compatible with the Beta release of the MVC framework
http://groups.google.com/group/autofac/browse_thread/thread/68aaf55581392d08
I hope they post a new version very very soon :-)
When I upgraded from Preview 5 to Beta I had difficulty locating the generic overloads of ActionLink. It appears that those are not included in the main release of ASP.NET MVC but are being shipping as "futures".
I found the necessary assembly (Microsoft.Web.Mvc) # http://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=aspnet&ReleaseId=18459
There is a breaking change in the ViewContext constructor. It has changed from:
ViewContext(ControllerContext context, string viewName, ViewDataDictionary viewData, TempDataDictionary tempData)
to:
ViewContext(ControllerContext context, IView view, ViewDataDictionary viewData, TempDataDictionary tempData)
This broke my code because I am using MvcContrib.Services.IEmailTemplateService, which takes a ViewContext in its RenderMessage method. To get an IView from the template name, I am doing the following:
var view = ViewEngines.DefaultEngine.FindView(controllerContext, viewName, null);
Not sure if this is the best practice, but it seems to work.
This is now broken:
<%=Html.TextBox("Name", new Hash(#class => "required"))%>
In Preview 5 the above would bind the value of ViewData.Model.Name to the textbox. This still works:
<%=Html.TextBox("Name")%>
But if you want to specify html attributes, you must also specify the value as follows:
<%=Html.TextBox("Name", ViewData.Model.Name, new Hash(#class => "required"))%>
Actually this is not really safe. If there is any chance ViewData.Model might be null you need to do something like this:
<%=Html.TextBox("Name", ViewData.Model == null ? null : ViewData.Model.Name, new Hash(#class => "required"))%>
This change seems counter to the Beta release notes:
"...in order to reduce overload
ambiguity...the value parameter was changed
from object to string for several
helper methods."
The value parameter for TextBox used to be string, and it was changed to object. So to avoid ambiguities they had to remove the one overload that I use the most. :(
IMHO, every HTML helper method should have overloads that allow binding in all cases without specifying the value. Otherwise we will end up with inconsistent view code that will confuse future devs.
If you are using Html.Form from the futures assembly (Microsoft.Web.Mvc) you might get a name collision on the FormMethod enum. For example:
Html.Form<FooController>(c => c.Bar(), FormMethod.Post, new Hash(#class => "foobar"))
This will complain that FormMethod is an ambiguous reference between Microsoft.Web.Mvc and System.Web.Mvc. This is quite sad because IMHO BeginForm does not provide a viable option due to its lack of an override that uses a lambda expression. Your only option is to use magic strings, which resist refactoring.
The best solution, it seems, is to put the following into every view that uses FormMethod:
<%# Import Namespace="FormMethod=Microsoft.Web.Mvc.FormMethod"%>
Ugh. Hopefully this is temporary. I expect that the futures assembly can be changed to use the enum from System.Web.Mvc. Or much better yet, hopefully they overload BeginForm to use expressions.
It seems that Html.Image is broken. As of preview 5 it was moved to the futures assembly. I cannot imagine why. Anyway, the error is:
Method not found: 'Void System.Web.Mvc.UrlHelper..ctor(System.Web.Mvc.ViewContext)'
The best solution I can see is to replace this:
<%=Html.Image("~/Content/Images/logo.jpg") %>
with this:
<img src="<%=Html.ResolveUrl("~/Content/Images/logo_350.jpg")%>" />
What Will said above, except that in addition to deleting the assemblies from the GAC and re-adding the references I also had to run the Beta installer again (putting the right assemblies in the GAC this time, though I'm just using a file reference).
I suspect if I'd deleted the Preview 5 assemblies from the GAC (and I've no idea how they got in there either) before I ran the installer, everything might have been OK. Worth trying.
In the unlikely event that anyone else out there is as daft as me and working on Vista, you may not need to do the registry hacking above in order to delete the old assemblies - just run gacutil from an admin command prompt. Doh!
I found that updating the web.config namespaces element with the namespaces from a blank project fixed my problems. I also had to update my ModelBinders due to the interface change.
Related
I installed AttributeRouting via nuget, for an ASP.NET MVC 4 project, in which previously I mapped routes lowercase with a MapRouteLowercase extension, but I don't really think this could be causing the problem, because when I disabled my older route mappings in Global.asax, the attribute based routes were still not working.
[GET("Sample")]
public ActionResult Aszadba()
{
... do whatever
}
But when I check the routes.axd, the route is not present, nor it is working : (
Didn't touch any of the basic configurations that the package made at install. If I put a breakpoint into the AttributeRoutingConfig class it gets hit, so it seems the mapping function is called properly.
I also tried mapping with the [Route("Lofasz",HttpVerbs.GET)] format, without success.
Any help or hint would be appreciated!
I believe you need to use the latter [Route(Directory/Page)] attribute syntax, although I haven't seen the Get attribute before and it may be a valid alternative.
Crucially you need to add-
routes.MapMvcAttributeRoutes();
To your RouteConfig.cs file before your first mapped rotue.
I have found a dozens of threads about getting the name of the controller and method based on the url, I managed that just as well. Can I get the MethodInfo of the method based on their name automatically from the MVC engine, or do I have to do Type.GetType("Namespace.Controllers."+cname+"Controller").GetMethod(mname)? Which is not so nice, since how do I know the namespace in a framework class? How do I know if the default naming patterns are being observed, or is there a different config in use?
I want to get a "What Would MVC execute?" kind of result....
Is it possible?
EDIT: further info:
I have a framework which uses translatable, data-driven urls, and has a custom url rewriting in place. Now it works perfectly when I want to show the url of a news object, I just write #Url.Content("~/"+#Model.Link), and it displays "SomeNewsCategory/SomeNews" instead of "News/29" in the url, without the need to change the RouteTable.Routes dynamically. However in turn there is a problem when I try to write RedirectToAction("SomeStaticPage","Contact"); into a controller. For that, I need to register a static link in db, have it target "/SomeStaticPage/Contact", and then write
Redirect("~/"+DB.Load(linkid).Link); and that's just not nice, when I have 30 of these IDs. The web programmer guy in the team started registering "fake urls", which looked like this:
public class FakeURL
{
public string Controller;
public string Action;
public int LinkID;
}
and then he used it like Redirect(GetFakeUrl("controller","action")); which did the trick, but still was not nice. Now it got me thinking, if I apply a [Link(linkid)] attribute to each statically linked method, then override the RedirectToAction method in the base controller, and when he writes ReturnToAction("action","controller"), I'll actually look up the attribute, load the url, etc. But I'm yet to find a way to get the methodInfo based on the names of the controller and the action, or their url.
EDIT: I've written the reflection by myself, the only thing missing is getting my application's assembly from inside a razor helper, because the CallingAssembly is the dinamically compiled assembly of the .cshtml, not my WebApplication. Can I somehow get that?
To answer your edit, you can write typeof(SomeType).Assembly, where SomeType is any type defined in code in the project (eg, MvcApplication, or any model or controller)
Also, you can write ControllerContext.Controller.GetType() (or ViewContext) to get the controller type of the current request EDIT That's not what you're trying to do.
I found out that it was totally wrong approach. I tried to find the type of the controller based on the name, when instead I had the type all along.
So instead of #Url.Action("SomeAction","SomeController") I'll use #Url.MyAction((SomeController c)=>c.SomeAction()), so I won't even have to find the controller.
I have created a base class that derives from ViewPage with a custom public attribute that I want to be able to set in the #page directive however I am getting the following error.
Error 24 Error parsing attribute 'attrame': Type 'System.Web.Mvc.ViewPage' does not have a public property named 'attrname'.
the directive looks as so
<%# Page Title="" Language="C#" AttrName="Test" Inherits="Web.Helpers.Views.BaseViewPage" %>
The problem seems to be that it doesn't recognize the base class from the Inherits tag. I thought this should work from reading around on the internet. Has anyone else tried this or have any idea why this isn't working?
This is unfortunately not supported in ASP.NET MVC 1.0 or ASP.NET MVC 2.
The reason for this is an implementation detail of some MVC-specific parser logic that is used in ASPX/ASCX/MASTER files. If the view page's (or view master page's or view user control's) base type is a generic type there is logic that hard-codes the base class for the ASP.NET parser's sake to be just regular ViewPage (or ViewMasterPage or ViewUserControl).
Because the ASP.NET parser looks at the base class that MVC tells is, it will only ever be ViewPage, and thus it doesn't recognize the new property that you added, and thus it reports an error.
It is worth mentioning that this applies only if the base class you specify in the view page is generic. If you use a non-generic type then it should work just fine and you should be able to set values on custom properties.
I can think of two workarounds:
1) Create custom page base types for every type you need. This solution is rather easy, though cumbersome:
public class MyBasePage<TModel> : ViewPage<TModel> {
...
}
public class CustomerPage : MyBasePage<Customer> { }
public class ProductPage : MyBasePage<Product> { }
And then use only the non-generic derived types in the view pages' "inherits" attribute.
2) Copy the MVC source code (see links below) from the ViewTypeParserFilter into your project and make some small changes. The key method to change is the PreprocessDirective() method. Towards the bottom is an if() statement that overrides the "inherits" attribute to be one of a few hard-coded values. As you'll see, this code runs only if the declared base type is generic (hence my earlier comment).
It's up to you to decide exactly how you want to change this code. The key thing here is that the type name must be a type that .NET's Type.GetType() method can understand. That is, you have to use the CLR syntax for constructs such as generics and not the C# or VB syntax. For example, while in C# you can say:
System.Web.Mvc.ViewPage<Customer>
In the CLR syntax it's something like:
System.Web.Mvc.ViewPage`1[MyApp.Models.Customer]
Hopefully one of the two options above suits you.
Source code links:
ASP.NET MVC 1.0 source code download
ASP.NET MVC 2 RC source code
You need to set the base type in the web.config to get around this. Go to
/Views/Web.config
and change the
configuration/system.web/pages
and change the attribute pageBaseType to your class.
<pages pageBaseType="Web.Helpers.Views.BaseViewPage" {your other attributes here} />
I recently tried to implement dependency injection using StructureMap. I managed to follow the example all the way but I'm encountering a thrown exception every time I try to run the application. Here's some code snippets from my controller factory.
public class StructureMapControllerFactory : DefaultControllerFactory
{
protected override IController GetControllerInstance(Type controllerType)
{
if (controllerType == null)
throw new ArgumentNullException("controllerType");
return ObjectFactory.GetInstance(controllerType) as Controller;
}
}
My Global.asax calls a static BootStrapper class which registers all my dependencies but it looks like the StructureMapControllerFactory's GetControllerInstance is getting called twice. The first time it's called, a proper controllerType is passed in but it's always null on the second calling.
The first time GetControllerInstance is called, the type is set to HomeController which is correct. The code the fires in HomeController and it returns the View(). On the return of the View(), the Page_Load event is called on the aspx file. After stepping through that, it arrives at a line:
httpHandler.ProcessRequest(HttpContext.Current);
That's where the GetControllerInstance is called the second time.
Here's my Global.asax bits which may be relevant:
protected void Application_Start()
{
RegisterRoutes(RouteTable.Routes);
Bootstrapper.ConfigureStructureMap();
ControllerBuilder.Current.SetControllerFactory(new StructureMapControllerFactory());
}
I'm very keen to get dependency injection working and would be most appreciative if anyone can help me out. :)
UPDATE
The reason this is happening is that when an image is specified in a css file, and that image is missing the routing framework tries to map the url to a controller. Ignoring the routes as listed below will prevent the error from happening, but I decided not to implement it because it's a nice way of being notified that you have a missing resource.
You can see a detailed explanation along with examples of setting up dependency injection using Structure Map here.
I was having the same issue and I think I figured it out. For whatever reason whenever you try to provide your own Controller Factory you need to add a couple of additional IgnoreRoute definitions. The first thing I would do is add this line to your GetControllerInstance method:
if(controllerType == null)
return base.GetControllerInstance(controllerType)
This will at least give you more information in the error message as to what the request is that is causing the controllerType to be null. In my particular case I had a background image in my css file set like this:
background: url(img/logo.gif);
So what happens is the routing is looking for a controller called "img" and an action that takes logo.gif or something along those lines. That's obviously not the correct behavior.
After some digging I realized I needed to add an IgnoreRoute definition to my Global.asax file that would ignore anything in the "content" directory of my site like this:
routes.IgnoreRoute("{Content}/{*pathInfo}");
I'm still not sure why you don't need to do this with the default ControllerFactory, but nonetheless it works.
You'll probably run into the same issue with favicon.ico. Particularly if you using google crhome. You'll need to add this as well:
routes.IgnoreRoute("{*favicon}", new {favicon=#"(.*/)?favicon.ico(/.*)?"})
I am guessing you are requesting a static file, such as a javascript file, that has not been added to your project or perhaps the reference to it has a typo. You should monitor your browsers web requests and look for web requests for that do not correctly resolve to a static file when they should. You can use firebug in FF or fiddler if you are using IE to do this.
I have something similar to the following method:
public ActionResult Details(int id)
{
var viewData = new DetailsViewData
{
Booth = BoothRepository.Find(id),
Category = ItemType.HotBuy
};
return View(viewData);
}
and the following Route:
routes.MapRoute("shows","shows/{controller}/{action}/{id}", new {id = 0});
Everything worked fine before the Beta, when I had Preview 3. Now the method will fill the id correctly the first time I execute the action. However the second time the controller's ModelState contains the last-use id value. This causes the ActionInvoker to use it in the method's parameter instead of the Route value.
So if I call the action twice on two different entities the results are such:
www.mysite.com/shows/Booth/Details/1 => Details(1)
www.mysite.com/shows/Booth/Details/2 => Details(1) //from ModelState["id"]
From my quick scan with Reflector it seems it first binds parameters to the ModelState then to Routes. However, I never even posted anything from the model. As far as I can tell the ModelState should not contain anything.
Is this a bug in the Beta, possibly a bug somewhere in my code, or is there some design feature that I am ignorant of? Any insight into the nature of ModelState and why this happens is appreciated.
EDIT:
I discovered that this issue is actually a symptom of what appears to be a bug with the DefaultValueProvider if you instantiate a Controller from an IoC container that exists for the lifetime of the Asp.Net application.What happens is that the DefaultValueProvider uses the first ControllerContext given to the Controller and never updates it until the controller is recreated. This causes old RouteData to be used for method parameters instead of the current RouteData.
It's hard for me to tell what you expect to happen and what is happening from your post. Is it possible there's an error in your BoothRepository.Find method such that it returns the same thing every time?
ModelBinder should not be affecting this method because the parameter to the action method is a simple type, int.
Were both of these requests GET requests? If you still are having problems, can you try and create the simplest repro possible and email it to philha - microsoft dot com?
EDIT: The problem ended up being that the developer was attempting to re-use the valueprovider across requests (by having Castle Windsor manage the lifecycle of Controllers). Right now, there's no support for re-using controller instances across requests like you would with IHttpHandler which has a IsReusable property. So in general, reusing controllers across requests requires doing a lot more work on your end. :)
The problem is the LifeStyle, I completetly overlooked the fact it was being defined, which means by default the controllers will use the Singleton lifestyle. Setting the LifeStyle to Transient for all controllers will sort this problem.
if you use spring.net modify
Controller's singleton to "false"
This is a common issue when using Singleton behavior with a IoC container such as Spring.NET or Windsor. Controllers should not have singleton behavior because the ControllerContext is per request, much like HttpContext.