Sunday, July 29, 2007

Wow! What a week!

It's been an exciting time of late.  Not only were many things accomplished (and a few plaguing bugs resolved), but I found out Friday (yesterday to me still despite it now being Sunday) that I'd be leaving for the Netherlands (a.k.a. Holland, despite Holland being a pair of provinces of the country) on Saturday for the week.  Well, I'm here now in the town of Eindhoven.  And it's beautiful, though overcast.  I've not been in town but a few minutes so I've not had a chance to get out, but here's a quick photo from my hotel room.

I left Salt Lake at 1:30 PM, arrived in Houston and departed there at 7:10 PM to arrive in Amsterdam at 12:30 PM.  It was so nice to fly business class where I could fully recline the seat, watch movies, have great food, and all-in-all have a great flight.  Then, upon arriving I grabbed the train in the airport to Eindhoven (which was about a 1 hr 20 min ride).  The hotel is only a few blocks from the train station so the walk was nice.

I'll be here all week and I'm looking forward to a great time.

Sunday, July 29, 2007 12:12:00 AM (Mountain Standard Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  |  Trackback
 Tuesday, July 24, 2007

I've been developing an ASP.NET application for quite some time now without a single problem and all of the sudden when I attempt to open the project in VS 2003 (it's an ASP.NET 1.1 app) I am greeted with the following dialog box:

I've been coping with the issue for a few weeks as I'm able to simply open the application directly in IE and attach the debugger as necessary.  Something must have changed of which I'm unaware, but this had me confused.  Needless to say, the very first thing I tried upon seeing this message was to register ASP.NET 1.1:

C:\>cd\windows\Microsoft.NET\Framework\v1.1.4322
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322>aspnet_regiis -i

Investigating it beforehand with the -lv and -lk revealed that it was indeed already registered with ASP.NET 1.1, but I figured redoing it wouldn't hurt.

When I tried opening the project in Visual Studio, still the problem persisted.

The only solution that I could come up with was to create the file that VS looks for when opening a web project (get_aspx_ver.aspx) explictly in my web application's root, even though it's not expecting to find the file in the first place.

Has anyone else seen that and/or have a better solution?

Tuesday, July 24, 2007 7:09:00 AM (Mountain Standard Time, UTC-07:00)  #    Disclaimer  |  Comments [4]  |  Trackback

I was greeted rather abruptly today by an error message that resembled the following:

The module 'XXX' is already in the application and cannot be added again.

This surprised me as I hadn't made any changes to my web.config file's <httpModules /> section.  In fact the module in question is only in my web.config file one time.

I have a web configuration file editor that I had written that updates config files and it automatically adds the <httpModules /> section if necessary, wiring up the httpModule in question. As it turns out, I had inadvertently updated the web.config in my root website which was causing the module to be loaded globally.  Removing the erroneous information from my root web.config file fixed the problem straightaway.

Tuesday, July 24, 2007 6:43:00 AM (Mountain Standard Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  |  Trackback
 Sunday, July 15, 2007

This past week was a very quiet one on the blog-front as I was full-time engaged in Denver for an in behalf of Experlogix.  This was my fourth Microsoft Worldwide Partner Conference and it was fantastic.  Since 2004, the WPC's that I've attendend have been in Toronto, Minneapolis, Boston, and this past week in Denver.

We had the great opportunity to have our expo hall booth situated adjacent to the Microsoft booths which was ideal for funneling traffic our way.

It is wonderful to be associated with such an awesome company and work with great people.  I love what I do! :-)

Sunday, July 15, 2007 6:30:00 PM (Mountain Standard Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  |  Trackback
 Tuesday, July 03, 2007

I've been working with the Visual Studio deployment projects for years now, but always in a very simplistic manner.  That is, I've used them to deploy my applications, install my services, etc, but I've never needed to get into custom development.

Sure, I've long leveraged .NET's ability to have Installer classes to execute custom code when the application in installed to perform tasks such as Event Log creation and/or registration.  This is quite easy, in fact.

Without diving too deeply into it right now, a simple form comes down to the following tasks:

  1. Create a public class that derives from System.Configuration.Install.Installer.
  2. Add the [RunInstaller(true)] attribute to the class.
  3. Add the appropriate code to your Install, Rollback, and Commit method overrides.
  4. Add your application's output to your setup project's Install and Uninstall Custom Actions.

That's it - the installer takes care of everything.

However, my needs with a recent pet project involved passing data to my installer class from the setup project.  This is easily accomplished by following these steps:

  1. Add a dialog to your installer (e.g. there's one called "Textboxes (A)" that will work fine).
  2. Each of these basic dialogs (A, B, and C) contains 4 edit fields.  In order to pass the values from the edit fields to your installer you must name them.  You can use the defaults, but EDITA1, EDITA2, etc don't tend to make much sense.  You name them by changing the EditxProperty property on the dialog.  This is now the variable name you can reference in your code.
  3. Pass the value to your installer by selecting the 'Primary output from XXX (Active)' node in the appropriate Custom Action and setting the CustomActionData property.  This string is defined as a space delimited parameter list.

    For instance, if you named a property 'ROOTFOLDER', you could define the parameter as follows:
    /rootFolder=[ROOTFOLDER]

    If you want to pass more than one parameter, you space delimit them:
    /rootFolder=[ROOTFOLDER] /userName=[USERNAME]

    Of course, if there's a space (or the potential for a space) in the value, you'll need to enclose the property in quotes:
    /rootFolder="[ROOTFOLDER]"
  4. You can then reference the parameters by name in your installer code:
    public override void Install(IDictionary stateSaver) {
       base.Install(stateSaver);
       try {
          string rootFolder = this.Context.Parameters["rootFolder"];
          // do something, such as create the folder, write a configuration file, etc
       }
       catch ( Exception ) {
          // do some logging here
       }
    }

All in all it's pretty straightforward and easy to do.

Happy coding!

Tuesday, July 03, 2007 4:28:00 AM (Mountain Standard Time, UTC-07:00)  #    Disclaimer  |  Comments [3]  |  Trackback