I received a fax today consisting of a form to be filled out and faxed back to the sender.  Not only did the fax include two copies of the form to be filled out (presumably one for me and one for the sender), but included the following instructions:

Hi,

Please sign both copies, keep one for your records, fax the other back to me.

This is making the rounds lately and it seems to have many developers up in arms - and semi-understandably so.  Somasegar recently announced that while Visual Studio version 2005 (with SP1) would be supported on Windows Vista, Visual Studio 2002/2003 would NOT.  When I first read that it took me aback.  What?  How could they not support them?  I use both VS 2003 and VS 2005 on a daily basis and am planning on moving to Vista promptly.

First of all, let me be clear about this (and this seems to be something of a point of confusion):  Visual Studio 2002/2003 (the products) will not be supported on Windows Vista.  This does not mean that .NET 1.1 applications will not be supported - they WILL.  Even then, that doesn't mean that VS 2002/2003 won't work on Vista...they just won't be supported.

As you're no doubt aware, the Microsoft Windows team has done a tremendous amount of work around security and the locking down of the operating system for the Vista release, many of the changes impact the way that applications (particularly debuggers) work on the OS.

Scott Guthrie has the following to say (taken from Dennis van der Stelt's blog) :

The big technical challenge is with enabling scenarios like advanced debugging. Debuggers are incredibly invasive in a process, and so changes in how an OS handles memory layout can have big impacts on it. Vista did a lot of work in this release to tighten security and lock down process/memory usage - which is what is affecting both the VS debugger, as well as every other debugger out there. Since the VS debugger is particularly rich (multi-language, managed/native interop, COM + Jscript integration, etc) - it will need additional work to fully support all scenarios on Vista. That is also the reason we are releasing a special servicing release after VS 2005 SP1 specific to Vista - to make sure everything (and especially debugging and profiling) work in all scenarios. It is actually several man-months of work (we've had a team working on this for quite awhile). Note that the .NET 1.1 (and ASP.NET 1.1) is fully supported at runtime on Vista. VS 2003 will mostly work on Vista. What we are saying, though, is that there will be some scenarios where VS 2003 doesn't work (or work well) on Vista - hence the reason it isn't a supported scenario. Instead, we recommend using a VPC/VM image for VS 2003 development to ensure 100% compat. Hope this helps - even if the answer isn't entirely what we'd all like it to be, Scott

I've been considering making my primary development environment on a VPC anyway - maybe this is the way I'll have to go in the Vista timeframe.

As an avid proponent of virtual machines (e.g. Microsoft Virtual PC, VMWare, Virtual Server, etc), they play an integral part in my role as a software developer.  While I haven't yet made the switch over to have my primary development environment (which I may do at some point), I find them to be extremely useful especially for testing software or hosting services that I would not otherwise want to install locally.

A virtual machine does tend to get quite large.  I have several virtual machines where the VHD (virtual hard drive) file exceeds 10 GB.  Zipping a 10 GB file takes quite a while.  If I want to burn it to DVD, for example, I have to spend a while zipping it and copying it.  Extracting seems to take even longer and it's a lot of time that I don't really have.

Several months ago I had evaluated a product by Invirtus called the Invirtus VM Optimizer.  While I don't like their evaluation scheme (which only allows for one usage per VPC - and it's easy to do it wrong if you're evaluating the software, rendering it virtually useless), there are many raving reviews online about the product.  We recently purchased the Corporate Edition v2.5 and I took the time today (being that it's a weekend) to 'optimize' my set of clean images.

To expedite the process of building a new VPC I've assembled a collection of 'clean' images.  A clean image in this case has no additional software installed on it except the base OS and hotfixes.  I will periodically dip into the archive, open each VPC and update it to the latest of all hotfixes and patches and then rearchive it with the appropriate date stamp.  I optimized 5 VPCs today and achived an average size reduction on the VHD files of 58.7% (not bad at all).  :)

Now I can put all five back onto a single DL DVD without the need of zipping/rarring them up which makes the whole proposition even more exciting.  Here are my results:

Windows XP SP2:

5,113,091 KB before
1,362,287 KB after
73.36 % savings

Windows 2000 Professional:

2,757,316 KB before
1,163,583 KB after
57.80 % savings

Windows 2000 Server:

2,757,316 KB before
1,268,056 KB after
54.01 % savings

Windows Server 2003:

3,199,792 KB before
1,352,045 KB after
57.75 % savings

Windows Server 2003 + CRM 3.0/SQL Server/etc:

4,248,624 KB before
2,329,179 KB after
45.18 % savings

Total:

18,076,139 KB before
7,475,150 KB after
58.65 % savings

I know this is nothing new and that it's painfully obvious, but I've had it bouncing around in my head for months and months.

Perhaps my love of Greek Mythology coming to a head, but I absolutely love the theme of Greek names in the naming of AJAX, JSON, and Atlas.  Besides, they're just plain cool.  And then to tie it all together we have Atlas, one of the greatest of the titans.

Always a sucker for puns for clever plays on words, I enjoy the fact that we have the convenient acronyms such as AJAX and JSON.  There have been others in the past too.  SOAP and ROPE anyone?

Can anyone think of others?

This has been a tad frustrating but ever since upgrading my computer to a Dell Precision M90 (Dual Core) from a Dell Inspiron 8600 my favorite virtual drive application (DAEMON Tools) has not worked.  This has been a known issue with version 4.03 and well documented in the forums on their website, but on a whim today I decided to check to see if there were any updates.  As it so happens 4.06 was released just today.

I downloaded it and installed it and I'm happy to say the dual-core issue has been fixed - it worked first try!  :)  I'm so happy.

[UPDATE: 09/26/2006]
As it turns out, because I run as a non-administrator there is a bit of an issue running DAEMON Tools 4.06 once I rebooted.  To remedy this, I had to alter the registry to run DAEMON Tools as an administrator rather than my account at startup.  As a side effect, I have to provide admin credentials at boot up, but I'm willing to do this in order to get the software to work.

1. Open the Registry Editor (regedit.exe or regedt32.exe)
2. Open to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
3. Edit the string value called DAEMON Tools to have a value that resembles:

runas /user:MACHINENAME\Administrator "\"C:\\Program Files\\DAEMON Tools\\daemon.exe\" -lang 1033"

In doing a little ASP.NET 2.0 databinding to a DropDownList control I was presented with a nice little error:

"'[ddlcontrolname]' has a SelectedValue with is invalid because it does not exist in the list of items. Parameter name: value"

Well, this is occurring on a postback for one DropDownList on a requery of a dependent DropDownList.  In other words, DDL01 performs an autopostback which forces DDL02 to requery its list.  The error is occurring because the SelectedValue that was originally bound to DDL02 is no longer in the set of data now associated with it.

You might try, as I did, to work around this by setting the SelectedValue property to null or string.Empty prior to rebinding, but that didn't seem to work for me.

There is a very easy solution to this dilemma, however.  In my case, all I had to do was clear the list, then set SelectedValue to null, then rebind as the following method does:

private void bindToList(DropDownList ddl, DataSet ds, string textFieldName, string valueFieldName) {
   // clear out any previous selection to avoid the ugly IndexOutOfRangeException
   ddl.Items.Clear();
   ddl.SelectedValue = null;

   // perform databinding as normal
   ddl.DataSource = ds;
   ddl.DataTextField = textFieldName;
   ddl.DataValueField = valueFieldName;
   ddl.DataBind();
}

I just read this post today and must say that while I don't necessarily share Steve's guilt, I most certainly get pleasure out of taking the occasional nap - especially during the day.  Of late (read as 'over the past 6 or so years') I have not had taken the opportunity to rest my weary eyes as I would have liked to, though I've stolen a few winks here and there.

I very much enjoy when I can crash for about 15 minutes to an hour in the mid afternoon, in part for the wonderful refreshing feeling when I arise, but also because it allows me to get more done.  In truthfulness, when I have the chance I like to indulge.  I find that I'm way more productive and I can focus more on the work that I have to do.

Many years ago I worked in a technical support group at a company in Salt Lake City.  My responsibilities mostly revolved around helping customers with their software issues revolving around the job-costing/AP/AR/GL software that we provided to them and was developed in-house.  Great times.  One of the best memories that I have of that place is that I was able to take a nap over lunch...and everyone knew about it. :)  I'd eat my lunch (which was usually pretty small and consumed in about 10 minutes) and for the remaining 45-50 minutes of the lunch hour I'd retire to a remote room in the rear and rest.  Back in those days my body clock was quite attuned to the time and though I'd close my eyes and be officially 'out of it' for the duration, I would snap-to at exactly the hour and return to my desk completely refreshed and ready to tackle the remaining hours in the day.  Never once was I late, something of which I was quite proud.

I think I gained this measure of control in the preceding years while I was in Mexico on a two-year mission.  There would be the occasional day where my companion and I would return to our house/apartment/room after lunch (during their offical siesta hour) and prepare for the remainder of the day.  I could crash for 20 minutes in a 'power nap' and instantly get up and be fully charged for the rest of the day.

These experiences and more have led me to be an advocate for napping.  They sure get me charged up and moving.

Are you a napper? Are you a sleeper-inner?  What helps you maintain your level of intensity during the day?

I recently created a small WebSite project in Visual Studio 2005, in part, to simply reaquire a feel for it.  In generally, my programming style and thinking falls more in line with the Web Application Projects which are akin to creating web projects in Visual Studio 2003.  The scope of this project is very small so I figured that it would be good to experiment with the WebSite project on a small scale...it seems to fit nicely.

That said, however, I have an ASPNETDB.mdf database that maintains membership for the website with a few canned users.  One thing that I do like in VS2005 is the "ASP.NET Configuration" option which launches a Cassini website for the administration of users, roles, permissions, etc that are maintained in the ASPNETDB.mdf database.

Once the database is moved over to the server, however, you lose the ability to run this management website...or so it may seem at first.

In fact, you have all of the management tools as part of the .NET 2.0 installation, but you have to wire it up.  So, if you want the nice ASP.NET Web Site Administration Tool on your server simply follow these steps:

1. Create a new virtual directory that references %WINDIR%\Microsoft.NET\Framework\v2.0.50727\ASP.NETWebAdminFiles.  I called it ASP.NETWebAdminFiles.
2. Make sure that the appopriate version of ASP.NET is used.  In this case, it should be .NET 2.0.
3. On the directory security tab, disable anonymous access.
4. Set the default document to default.aspx.

Then, to properly manage your website, you need to specify a couple of query string parameters: applicationPhysicalPath and applicationUrl.

For instance:

http://localhost/ASP.NETWebAdminFiles/default.aspx?applicationPhysicalPath=C:\TestWebsite\&applicationUrl=/

For each website, I set up a simple shortcut that provides quick access to the administration console.

Ok, maybe it's just that it's 4:30 AM and I need to get to sleep, but this is something that has bugged me for sometime, and it's just coming to a head right now.

I just don't get how VS2005's Publish Web Site option is all that helpful, especially on a second time around.  Let me explain.

I really like how simple it is to 'push' a website up to a server.  Simply enable FrontPage Extensions on the web site in IIS and viola, you can publish from VS2005.  Slick.  If you're publishing for the first time, it's all smooth and it pushes the entire website (content, databases, etc) as prescribed in your project in VS.

I would argue, however, that that's usually not the last time the website is touched.  Tweaks need to be made, new logic introduced, alternative site navigations added, etc.  In short, there's maintenance.  When you go to publish a second time around it will warn you with a message indicating that "Existing files in the destination location will be deleted.  Continue?".  While appreciate the warning, I think it's completely out of line.  The warning is, in fact, telling you the truth.  When you publish, ALL files, folders, etc in your target folder will be purged.  I think this is a bad thing in several ways.

In an effort to combat this work around this egregious behavior by excluding files from your project in an attempt to not upload them; this will, in fact, work - the files will not get uploaded, but they will disappear from the server all the same.

But the one thing that's really irking me right now is how it handles databases.

Suppose you're creating a website that uses SQL Server Express and have the customary ASPNETDB.mdf in the App_Data folder to maintain membership, profiles, roles, personalization settings, etc.  There's not a convenient mechanism to publish your website from Visual Studio because doing so will effectively destroy the target database, replacing it with the one from your development environment.

So what's the deal?  Why does it a) not give the option to skip the uploading of databases b) have to delete every stinkin' file?