Pro Tips: Get Your Windows MSI Installer Logs

Want more information about what an .msi is doing on your system or what caused a generic and completely useless error message to pop up?  Run the following command substituting the path to your .msi from the command line and the output file will contain verbose logs.

msiexec /i filename.msi /l*v log.txt

C# Meta-Programming And Extension Methods Question

First, it should be noted that my ASP.Net MVC-foo is yet great and I know this.  If you know a better way to do this, please take the time to explain how you are superior.  If you don’t, how will we ever know?

Working with ASP.Net MVC 2 client-side form validation this past week, I ran into two unfortunate (IMHO) facts which kept tripping me up:

1. Html.ClientValidationEnabled() must be called as a scriptlet BEFORE the form is created
2. Html.ValidateFor or Html.ValidationMessageFor must be called for EACH property of the model you want validated.

*** This StackOverflow answer includes a couple other important & useful things to note

These two issues (and many more) bother me about ASP.Net MVC 2 client-side validation but #2 in particular was really ticking me off.  I like that I can conditionally turn validation on/off on a field by field basis … but why make me enumerate all validation-needed model fields twice in my view!?  Especially in my case where I want validation turned on for ALL model object fields that have DataAnnotation Validations defined for.  Obviously the fields are going to be enumerated in the view once; how else are the text boxes and drop downs going to be created, but why make me list out each field AGAIN just to turn on validation?

All of this amounts to one WET solution. Am I missing something?

The best solution I have seen, and the one I am about to start implementing, is this one by Rick Anderson over at MSDN found via this related forum post.  The idea is to create additional Html helper extension methods which will combine the creation of the HTML form element with turning on and configuring validation.  This solution has the benefit of making me enumerate the model fields being used only ONCE in my view code and reads cleaner.

The only problem is that I have to walk through our application, find anywhere that is using a built in HtmlHelper extension method to build an HTML form element (e.g. input tag), build a new validating wrapper extension method that matches the signature of the original, and then replace the original code with the new extension method.  This can be done, but is time consuming and error prone.  And I am lazy.

The real issue …

I want to … create additional HtmlHelper extension methods based on all existing ones that produce form elements and take in a Linq expression to find the model property that first pass that expression to helper.ValidateFor() and then return the original extension method’s valued.

Is there any meta-programming feature or technique in C# that will allow me to concisely do that?

e.g.

Since Html.TextBoxFor(user => user.FirstName) is used in our app, as it stands I will am going to create a custom extension method similar to:

public static class ValidatingFormElementsExtension
{
  public static MvcHtmlString ValidatedTextBoxFor<TModel, TProperty>(this HtmlHelper<TModel> helper, Expression<Func<TModel, TProperty>> expression)
  {
    helper.ValidateFor(expression);
    return helper.TextBoxFor(expression);
  }

  // and so on for EACH one we use

}

Anyone have any ideas?  Am I completely off base with this? Is there a better way?

~~~~~~~~~~

<mini-related-rant>

A few more quick cracks at ASP.Net MVC  that I need to get off my chest

• Why are so many things done in scriptlets!?  I feel like I am back in the vanilla JSP days of yesteryear.
• They are Annotations in Java and Attributes in C# …. so why are the data validation attributes defined in System.ComponentModel.DataAnnotations?
• I get that HTML checkbox form input fields have TRUE/FALSE values passed back when the form is submitted, and that doesn’t map perfectly to how other fields are handled by the Required attribute …. but why was NOTHING included to do this?  Having to use a RegularExpression validator for [Tt]rue is clumsy no?

</mini-related-rant>

Note to self: C# throw; NOT throw ex;

If you need to catch and re-throw the original exception in C# (and possibly other .Net CLR languages) PLEASE, GOD PLEASE, use:

catch(FooException ex) {
// do what you came here to do
throw;
}

NOT:

catch(BarException ex) {
// do what you came here to do
throw ex;
}

While I love being a polyglot developer equally confident developing on the .Net CLR as the JVM, when I am working in a mainstream OO language I still think in Java.  Thus my confusion today when I found a several times re-thrown exception’s stack trace only going back as far as the last re-throw.  Turns out that explicitly throwing an exception (new or old) sets the originating stack trace location as the point of the throw command, not where the Exception object was created or originally thrown.  This is not the same in Java.  I like the syntactic sugar implicitly throwing the caught exception, but shouldn’t the behaviors be the same!?  Sadly the offending throw anti-pattern is strewn throughout the code I was working with….

** Also, put the damn curly braces on the same line ;-)

*** Several more knowledgeable .Net devs on the team knew this fact, but weren’t 100% sure why; but I found this link which helped.

MonoRail with URL Rewriter working on IIS 7

I have spent the last few days setting up an existing client application in a new data center (IIS 7 +, Windows Server 2008, x64 bit).  Sounded easy, but it turns out that IIS 7 has some differences from IIS 6 and this app and its libraries (Castle project’s MonoRail & ActiveRecord, and URL Rewriter) were written for IIS 6.  Below are a few tips and tricks that helped us finally get the app up and running this afternoon.  Some of these may be obvious to your average .Net developer, but I come from a Java background and IIS configuration is a enigma wrapped in a mystery to me.  In hind site the few articles I found on Google were helpful and contained good information, but weren’t framed in a way that I immediately could get value from.

• Setup the application pool with “Classic” managed pipeline mode.  From what I found, this has IIS run the app in IIS6 compatible mode.
• Setup a new website using the above pool (not some other one, this is important)
• Add handler mappings for MonoRail and the UrlRewriter (web.config XML snip-it can be found on my GitHub Gist 315115)
• Most of the MonoRail and URL Rewriter install instructions focus on changing “Application Extension Mappings” in IIS 6.  These are found under “Handler Mappings” in IIS 7.  Note: these changes now modify your site’s web.config directly (instead of just being a IIS setting).  The changes are under the <handlers> element.  If you do an automated build (e.g. with NAnt or MSBuild) and push your files out these changes need to be committed into source control otherwise your normal file will override them the next time you deploy.
• We ended up including both the 32 and 64 bit Framework isapi filter .dll’s as our handlers but it looks like Windows Server 2008 only cares about the 64 bit libraries.  We are still testing this with our builds because currently all of our workstations are 32 bit XP machines.
• We also removed all of the original mappings since our application didn’t use them, static content is hosted elsewhere, and they were conflicting with the MonoRail mappings