Set facepalm levels to 'Picard'

Well, I figured out my problem.  Naturally, it was me being an idiot.  I forgot to change my strongly typed view to accept a view model instead of a string.  The way the exception appeared, I thought it was telling me that RouteData.Values was throwing it.  Turns out it was the internal dictionary of the view itself.

SO link: http://stackoverflow.com/questions/5808554/asp-net-mvc-2-route-errors-problems-when-using-cottsaks-solution/5838686#5838686

Same as it ever was

So, I've made a bit of progress with my 404 implementation, but I'm encountering a NotImplementedException that I'm not sure how to solve.

I'm trying to implement the solution found here: http://stackoverflow.com/questions/619895/how-can-i-properly-handle-404s-in-asp-net-mvc/2577095#2577095  The difference being, I'm using vanilla Ninject 2.0 as my DI container.

Details of my current problem: http://stackoverflow.com/questions/5808554/asp-net-mvc-2-route-errors-problems-when-using-cottsaks-solution

RequestContext is telling me it needs a string somewhere in its internal dictionary.  I don't see where I'm not supplying it a string.

Crisis averted

Turns out my SQLEXPRESS service was turned off for some reason.  No idea why, as it's set to automatically run.  Sorry for jumping the gun.

If it's not one thing, it's another

No attempt at a witty title tonight.  I made some minor changes in attempt to get my bad route handling squared away, and now all of a sudden I'm getting an EntityException, specifically that the underlying provider failed on Open.

FFFFFFFFFFFFFFFFFFUUUUUUUUUUUUUUUUUUUUUU

I haven't touched my domain code in days - neither my repositories nor my connection string - and, yes, I'm sure my connection string is in my Web.config.  It was working just last Friday, and the only changes I've made tonight have been removing [HandleError] from an action method and using named parameters when calling a view.  That's it.

As always, more detail on SO: http://stackoverflow.com/questions/5798047/ef4-entityexception-the-underlying-provider-failed-on-open

And now something to lighten the mood

Since I was diagnosed with diabetes at Christmas, this has become one of my favorite things:

While my keyboard gently weeps

As I wait for the ability to offer a bounty on my route error/500/404 problem on Stack Overflow, I figured I might as well write a letter to Microsoft about what I feel they can do better for newbies, like myself, attempting to jump into using their stack for web development.

1. Don't assume anything.  This has to be the biggest area of frustration for me.  There seems to be an underlying assumption that a lot of incoming MVC devs are former web forms devs.  Similarly, there's an assumption that we're comfortable using Visual Studio.  From my personal experience, I do know a little bit of web forms, mostly how horrible the Page object's life cycle is.  I also know what Web.config is used for in an abstract sense, but am certainly not comfortable mucking around in there.  I'm barely competent with VS, having learned the hard way when to build/rebuild a project so it will work right when debugging.  I'm sure others aren't even at that level when they start down this rabbit hole.

2. Ignored or glossed-over info.  This really should be considered 1A.  Again, there's an assumption being made that people are familiar with ASP.NET and are mostly just migrating to MVC and/or EF4.  Look at the model binding validation fiasco I went through earlier.  Even better, look at the route problem I'm currently facing. 

I own what could likely be considered the tome on MVC 2 - Steven Sanderson's Pro ASP.NET MVC 2 Framework.  It is a great book which explains every part of the framework.  In fact, there's an excellent chapter (Chapter 8) which describes, in detail, MVC's routing mechanism.  What it doesn't explain is how to handle malformed routes.  Web.config's customErrors tag is mentioned just once, in passing, on page 612 in Chapter 17, which is dedicated to deploying MVC 2 projects.  That's it.  No description about what customErrors is, nothing about bad routes at all, no hints on making route errors fit into the rest of the routing system, or anything else.  I can't fault the book for not addressing my EF4 issue, as it works with LINQ to SQL instead, but shouldn't malformed routes at least be addressed briefly?

I'm not trying to crap on the book or its author.  I've found, that aside from the bad route issue, it's a great book, and recommend it to anyone looking to join in the MVC 'fun'.  What I'm trying to illustrate is a pattern.  If one of the framework's best books neglects to mention something that is fairly important like handling bad routes, then how are we beginners supposed to know what the hell to do?  It's certainly not addressed (at least, not addressed well) in the demoware, which is where most newbies start.

3. Smaller gripe: where's the at-a-glance info?  I want to know what kind of debugging errors I can step through compared to those I can't.  I want to know what those step-through errors would mean in a live, release environment.  I want to see the differences between Entity Framework 4.0 vs. 4.1, and how the common patterns have changed.  I'm sure this info exists somewhere, but its spread throughout the ether, buried in articles and blog posts.

So, now that I've vented a bit, I have some constructive suggestions on how to make the newbie experience better.

1. Don't assume we come from web forms country.  My background is in PHP.  I've used a grand total of 1 MVC framework in that environment - Kohana 2.something - and it doesn't exhibit any of the Microsoft idiosyncrasies like Web.config.  My IDE of choice back then was Notepad++.  A lot of other wannabe MVC devs comes from similar, or even NO web development backgrounds.  Keep this in mind.  I'm sure a lot of us are willing to skip over the bare-bones basic info we already know if it means you're actually covering all the basics.  I'd rather be inundated with the "No shit, can we move on?" stuff than not.

2. With that said, maybe create a newbie starter pack filled with the info we need to know before diving into MVC as a whole.  Topics could include basic Visual Studio usage (ex: knowing which errors can be stepped through, those that can't, and the differences between them), the basics of ASP.NET (things that are shared between web forms and MVC, like Web.config), and basic C# (ex: LINQ, lambdas, etc.).  If there's a minimum requirement or some prerequisite we need to know before getting into MVC for real, as there seems to be, then why not provide it in a centralized manner?

3. Be thorough.  Books, at least, shouldn't gloss over anything.  I'd rather have the option to dig through the innards of the framework than not.  Again, more information, not less.

In closing, I like the idea behind MVC, and I'm trying to buy, literally, into the platform.  I'd like it if it didn't seem like Microsoft and supporters of the framework made it easier for me to do so.  I'm not looking for anyone to hold my hand or write my code.  I just want the tools in order to do it on my own.

I would write 500 lines, and I would write 500 more

So, I've made a smidgen of progress regarding custom errors.  Some success, mostly failure, but the failure is a different kind of failure, which gives me hope.

The details can be seen at: http://stackoverflow.com/questions/5761573/a-couple-of-errors-when-trying-to-use-custom-errors-in-mvc-2