I was updating some code today in ASP.NET 2.0.  The code had originally been written in ASP.NET 1.1 and I'm in the process of migrating the application 2.0 in piecemeal fashion.  I'm doing it thus, in part, to experiment.  In doing so, I encountered an interesting situation that I thought to pass along to my faithful reader.

First of all, allow me to back up a bit to address a few of the issues that have some bearing on the discussion.  I have a web service that I built for user authentication.  I call it my Devstone Authentication Engine.  This web service has a custom SDK that provides functions that call the services, effectively isolating the dependent application from the nuances of setting up web references and associations.  The calling app simply establishes a reference to the SDK dll and we're good to go.

Alright, well, that SDK dll uses Reflection on the calling assembly to discover information about the system to which the user is authenticating.  I like this approach.  I have a custom Attribute-based type that I apply to the client application in question.  When the client application attempts to use the SDK dll, it reflects back on the caller to determine the desired target.

To be honest, this was all well and good in .NET 1.x.  You could build a Web Application, compile the entire site into a single assembly (MySite.dll) and call it good.

ASIDE

The rules changed with .NET 2.0, however.  The compilation model is substantially more complex; heck, the programming model is (IMHO) a bit more complex because it is much less structured.  (I know I'm not the only one who doesn't really care for the App_Code, no-namespace programming model.  I'll discuss that more in depth another time.)

To address these and many other concerns expressed by developers moving to the 2.0 Framework who were comfortable with the 1.1 programming model Microsoft has created what are called Web Development Projects.  If you're comfortable in the .NET 1.x programming model but want the power and flexibility of the 2.0 Framework, I highly encourage you to download the Beta V2 and experiment with it - it's pretty sweet!

In 2.0, however, when each page/folder/whatever gets compiled into its own dll, the attributes applied in the AssemblyInfo.cs don't get incorporated into each dynamic, on-the-fly assembly.  Therefore, calls to the web service SDK fail because it can't find an instance of the attribute within the calling assembly via Reflection.  If you set a breakpoint and inspect the assembly name you get the name of a dynamically created assembly (e.g. App_Web_y7sgdlhd.dll). 

The trick with 2.0 is simply to move the [assembly: myattribute()] from the AssemblyInfo.cs into the same page as the ASPX page that needs to call the web service. Then, when the runtime compiler grabs the file and compiles it, the [assembly:...] attributes get applied to the dynamic assembly as well.

Today I'm off to Dallas, Texas for Microsoft's Convergence Conference 2006 with Experlogix.  We've had the annual tradition of attending these conferences showcasing our software in the expo hall and each year it's been a blast!  We are very much looking forward to meeting the various Microsoft Partners, talking to the Microsoft CRM team, and interacting with customers.

If you're going to be in Dallas and/or are going to be at the conference, drop me a line and let's get together!  I look forward to a fun weekend!

Last week we had overwhelming success with our SQL Server 2005 Overview event, that people have been banging down the doors for more.  By popular demand, therefore, we are pleased to invite you to a follow-up event.  If you were unable to attend the first session for one reason or another and would like to attend this one, please check it out!  We had a great time doing it and it was a lot of fun.

Three separate seminars are presented: SQL Server Development Platform, Business Intelligence, and Infrastructure.  The event is to be held on March 9th from 9:00 AM to 5:00 PM at the Microsoft offices in the International Center.

Date / Location:

March 29th, 2006, 9:00 AM - 5:00 PM
Microsoft Corporation
123 Wright Brothers Drive, Suite 100
Salt Lake City, Utah 84116
(801) 257-6400
http://www.microsoft.com/mscorp/info/usaoffices/rockymtn/saltlakecity.mspx

Registration:

Register today at http://www.microsofttraining.com/devonsites
Class / Invitation ID: 304560

We had, today, our first board gaming session in which we tried something completely different.  For some time now we've wanting to play Puerto Rico after hearing so much goodness about it.  In our usual monthly get-togethers we play Settlers of Catan, Carcassonne, Shadows over Camelot.  This time, however, we opted for a completely new game, seeing that one couple wasn't able to make it tonight.  Not one of us had ever played it so we were on even ground to start, which made for a lot of fun and discovery.

Wow! What a cool game!  At first the rules looked daunting - even after having read them some 3+ times.  They didn't really make a lot of sense until putting them into practice and then it was oh so simple!  The game was extremely well balanced and everyone had a great time.  We will definitely need to try the 6-player unofficial variation when we get together in our normal 3 couple gatherings.

If you're a board gamer and haven't tried it out, or are wanting something quite different and a blast, I highly recommend Puerto Rico.  I can't say that I've developed a strategy yet, as the first two games have been focused on learning the rhythyms and patterns in the game and learning how what I do and choose affects all the other players (and myself), but I'll be watching for more of the subtle nuances and tricks in future games.  I'm looking forward to it!

I have both the .NET 1.1 and .NET 2.0 frameworks installed on my laptop because I frequently write software on both platforms.  I recently had the need to create a new ASP.NET 2.0 website.  I set everything up in IIS first (because I like to be able to dictate the name of the virtual directory and have it routed somewhere other than the InetPub\wwwroot folder for development.

Aside: VS2005 happily supports having a virtual directory pointed at a folder with a name other than the virtual directory name :)  VS2003 and prior didn't support this, so I didn't have nearly as many hoops to jump through when setting it up.  For instance, my virtual directory might be named TestSite and point to a folder named Source within the TestSite folder.  (I might have other peer folders, such as DbScripts, Documentation, etc all within the TestSite parent folder.  I no longer have to jump through hoops to make that work. :)

Anyway, I set it up and began writing some framework code for the site, setting up some master pages, themes, et al.  When I went to browse to the page I was greeted with a 'Mutex could not be created' error page.  Not deterred (and, frankly, half expecting the exception in the first place), all I had to do was this:

1. Grant myself (rather the user the site impersonates) Full Control to the %WINDIR%\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files folder.
2. Then, as I have the tradition of doing, delete the 'TestSite' folder (and all others for that matter) from the 'Temporary ASP.NET Files' folder.
3. Perform an IISRESET.

Once those steps were done, the site worked like a charm!  Happy Coding.

Today is something of a sad day.  For the first time in the many years of the Utah .NET User Group we're having to cancel the meeting.  All week long everything was looking to a great day today, but we got hit pretty hard with snow and wind creating perpetual white-out conditions.  All the meteorologists are saying it's going to continue and to be bad into the weekend.

We don't want anyone to unnecessarily put their lives at risk to come to the meeting nor do we want to put lots of time and money into the meeting to have no one show up.  Therefore, we've opted to cancel today's meeting in lieu of the weather.  Perhaps we can simply postpone it for a week or so.  If not, we'll pick up in April where we would have been today.

I was experimenting last night with a friend of mine (I would link to him, but he doesn't yet have a blog, the bum) and we came up with a pretty cool solution for application configuration files.  Generally, the practice and recommendation is to create/add an app.config file into your VS.NET project.  The compiler will then take the responsibility of copying the configuration file to the appropriate output directory (e.g. Debug, Release, etc) named after the executable (e.g. MyApplication.exe.config).  Then, when your application needs to access information within the configuration file via AppSettings or a call to GetConfig, it can do so via the ConfiurationSettings (in .NET 1.1) or ConfigurationManager (in .NET 2.0).  All is well, and most everybody is happy.

Suppose, then, that you have several applications that get deployed across the computer (maybe into the same folder, maybe not).  These applications may each require their own app.config file.  What can escalate the issue further and introduce maintenance problems is the concept of Library Assemblies.  Library assemblies (DLLs) will look for settings within their host .exe's app.config file.  If you have a 'family' or 'suite' of tools that share a common set of libraries, you will end up repeating the same settings across a multitude of configuration files for the dlls to read.  This easily gets out of control and it makes troubleshooting an application suite cumbersome to deal with, especially when settings must be updated.

By default, as mentioned, your application will look for configuration settings in a configuration file named after the host executable (e.g. MyApplication.exe.config) in the same working directory as the application.  An exception to this is a COM+ component which will look in either %windir%\system32 or the application folder as specified in the application.config (except on Windows 2000) as discussed here.  You do, however, have the means to override this default behavior on both the .NET 1.x and .NET 2.0 platforms.  This overriding must occur prior to any access to the configuration file, so it's a good practice to include this call at the start of your application.

You simply need to tell the AppDomain where to look and this is done via the simple call:

AppDomain.CurrentDomain.SetData("APP_CONFIG_FILE", @"c:\myconfig.config");

Of course, it's probably not a good idea to hardcode the path to the configuration file in your application, so reading it from the command line, a registry setting, or some other known location (but not a config file) might be a good idea.  The cool thing about this is you then can have a single, centralized location for all settings and a single location to edit them to have global effect.  Goodbye several configuration files.