# Friday, 03 May 2013

Today I wasted an hour or two chasing my tail around trying to figure out why a change to one of my ASP.NET MVC Views was not at all showing any changes in my jQuery Mobile version.  I cleared my cache, hit ctrl+F5 a billion times, redeployed to our test server and then again.  I double checked my code, then again.  I would view source and on my mobile version it hadn’t changed.  What is going on?

I noticed another oddity through all this. My page was loading up two versions of jQuery.  One being an older version I know I updated. 

<script src="/Scripts/jquery-1.8.2.js"></script>
<script src="/Scripts/jquery-1.8.3.js"></script>

Yet, it was loading. Huh? I’m confused.

What’s Happening

Then it hit me. Bundling in ASP.NET MVC looks for whatever version I have in the scripts folder to generate the tag since my syntax is:

bundles.Add(new ScriptBundle("~/bundles/jquery").Include(
"~/Scripts/jquery-{version}.js"));
    Does this mean I have the older version along with the newer version on my test server. 

folder

Inspecting the test server revealed this to be the case.  I then went to my view folder for the mysterious view that wasn’t changing and found a very old .mobile.cshtml file that we ditched a while back once we were able to consolidate our normal and mobile view on one page.

So how did this happen.  We’re a small shop and use Web Publish built into Visual Studio to deploy to our servers.  I looked at the file publish options and the "Remove additional files at destination" was unchecked.

publishOptions

Leaving this unchecked means that any file you removed from your project if on the destination machine will not be removed. 

Delete some views, update your jQuery nuget packages and publish without this checked and the old items will remain on your deployed environment.

A simple check of the box and all is well again.

Luckily, our production server deploy settings were correct so we didn’t have to worry about some nasty little bug in production due to this. Smile

Happy Coding!

Posted 05.03.2013  #    Comments [0]  | 
# Wednesday, 01 May 2013

All of the applications I put into production use ELMAH to track unhandled exceptions.  In one our new releases of an application I noticed a semi-rare bug occurring through these logs.

Validation Failed

Validation Failed

System.Data.Entity.Validation.DbEntityValidationException: Validation failed for one or more entities.

I initially figured something extraordinary occurred for this to happen. Then it happened again and then another time. Now I felt it was time to give this error a more thorough review.  Something less then extraordinary was likely happening.

I use data annotations on my database model since I’m using Entity Framework Code First (EF CF) and in my view models.  I was a little concerned that some nefarious input was being entered that the client side unobtrusive JavaScript was missing as well as in my server side checks.

As it has almost always turned out when I suspect something like this, the true answer is something much simpler and sometimes even a bit embarrassing.

Here’s the offending view model / with the EF CF model.  Can you catch the issue?

//View Model
public class MyCourseViewModel
{
    [Display(Prompt = "Yada Yada Yada College")]
    [Required]
    public string College{ get; set; }
    [Display(Name = "Course Title", Prompt = "Intro to Psychology")]
    [Required]
    public string Name { get; set; }
    [Display(Name = "Course Prefix & Number", Prompt = "PSY 101")]
    [Required]
    public string CourseNumber{ get; set; }
//…more view model fields…. } //Database Model... public class MyDatabaseModel{ [StringLength(150)] public string College{ get; set; } [Required] [StringLength(150)] public string Name{ get; set; } [Required] [StringLength(25)] public string CourseNumber { get; set; } }

Mismatched Annotations

In my database model I set maximum lengths for my strings but I didn’t for my view model.  Enter the case where a user enters a value longer than the allowable amount and you have the client side & server side checks all pass on the view model but then an error occurs at the database model level since you’ve exceeded your length.

Takeaway

Make sure you at least have matched or created a more stringent rule in your view models as you do in your database models.  A simple oversight on my part and definitely not intentional.

Logging

Takeaway number two: Log, log, and log.  Then be sure to review those logs not just ignore them.  Take action when you begin to see a pattern.

Dealing with exceptions

Adding ELMAH to my MVC projects has been a breeze and has offered a great amount of insight into unforeseen bugs.  I often don’t react to the first new bug that ELMAH reports.  I instead look to see if it’s a pattern and when one emerges I then put it on my list to deal with.

Happy Coding! Smile

PS – I realize a better test setup would have been able to prevent this bug from ever making it into the wild. A unit test would have even missed this but not an integration test. Some extra food for thought on how testing can save your bacon…. Mmm… bacon.

Posted 05.01.2013  #    Comments [0]  |