When using ASP.NET MVC sometimes after a request viewModel properties you expect to be binded and populated are not. For HTTP GET action methods debugging why this might be is easy as the params are visible in your URL. For HTTP POST requests the name/value pairs are sent in the header so they are not as easy to review.
One could use Fiddler or the Chrome/IE developer tools to look at the raw name/values pairs being posted across from the view but the Visual Studio Locals window gives you access to this information too. Just set a breakpoint in your action method and examine the current request object in the Locals window as shown below, the particular property you want to look at is Form. In the example below we can see the raw name/value pair string isSelectedCity=4&Country=United+States
If your using forms authentication in .net and the application that creates the authentication cookie is different than the one that consumes it (i.e. Web farm scenario), the consuming application may not be able to decrypt the authentication token in the cookie and hence you might see something similar to ‘Forms authentication failed for the request. Reason: The ticket supplied was invalid’ in your event log. I had this recently and two common causes were:
Machine key is different between application creating the authentication cookie and the application(s) using it. Keys must match. You can edit machine keys through IIS (as in below image) or directly through the web.config. Restart IIS/App pool shouldn’t be required.
Application creating the authentication cookie and the application(s) using it use a different cryptography core due to one targeting .net 4.5 and the other targeting 2.0 or 4.0. The method of decrypting tokens has changed since 4.5 and so an authentication token created by an application targeting 2.0/4.0 cannot be validated by an application targeting 4.5. The 4.5 cryptographic core is opt in (so not to break 2.0/4.0 applications running on machines which happen to have 4.5 installed) but the Visual Studio 4.5 project template includes one of the two different tags required to opt-in in the generated web.config. In our case our login app was a 2.0 app, but our new app was targeting 4.5.1 and so the default web.config included the following tag:
<httpRuntime targetFramework=”4.5.1″ />
which meant our new 4.5.1 app couldn’t decrypt the generated auth cookie. We simply changed that to <httpRuntime /> and things worked then. The second way to opt in is via the machinekey tag i.e:
<machineKey compatibilityMode=”Framework45″ />
so if you having problems decrypting make sure your apps have compatible runtimes set.
When using Entity Framework, in an effort to track down bugs or performance problems, it’s very handy to see what SQL Entity Framework is generating and sending to the DB when you run a lambda/linq query or indeed make a call to SaveChanges().
This is easy once you know how. Simple add this.Database.Log = x => System.Diagnostics.Debug.WriteLine(x); to the constructor of your database context class (the one that derives from DbContext):
Afterwards you should see all the queries Entity Framework is sending to the DB in your output window.
You may see this exception when doing a DbContext.SaveChanges() call. You then may go drilling into the exception details to find what the specific problem was and notice there’s nothing of value there. A simple way of getting access to the EntityValidationErrors collection and actually seeing what’s in it is to add a watch for it:
I’m really liking a lot of the ASP.NET 5 stuff which is coming down the line. Cross platform capabilities are cool, but more relevant and ‘exciting’ to me is the out of the box IOC container which hopefully will result in one less dependency on Ninject, CastleWindsor etc. and dynamic development which means I can change server side code, save and just refresh the browser without restarting the debug session.
On the MVC side, version 6 introduces tag helpers which I really like too. These allow us to get the same viewModel binding benefits of HTML helpers by applying data attributes to HTML tags rather than using the C# HTML helpers directly via @Html.TextBoxFor, @Html.LabelFor etc.
Markup in my opinion becomes less server side like, less ASP.NET MVC specific and more cleaner and client-side like meaning it would be easier for designers to work more fully on the views. The below example is from Dave Paquette’s introduction article on tag helpers which I link to below.
You can see that by using tag helpers we can specify things like classes, styles and other attributes (such as angular and knockout markup) in the normal HTML5 way rather than via an anonymous type. The only MVC specific part is the addition of the asp-for attribute. Matt DeKrey’s stackoverflow answer on the difference between html and tag helpers really sums up the benefits well I feel. I’m really looking forward to using razor this way, I think it lowers another barrier to working with MVC. If your preference however is to continue with HTML helpers they are still available of course.
By far the best coverage of MVC 6 tag helpers I’ve found is by Dave Paquette who has a tonne of articles about all the different tag helpers and also how you can create your own custom ones too. Start of with his Cleaner Forms using Tag Helpers in MVC6 article which is really good. Mike Brind’s Introducing TagHelpers in ASP.NET MVC 6 is another good introduction to tag helpers but also explores how they actually work under the hood.