I’ve been using a Mac for over a year now. Before that I was a Windows user since 1988.

Why did I switch? Quite simply, the Mac feels clean. When you turn it on you feel welcomed and embraced; understood even. Sounds silly, but it’s true. The small things make all the difference.

Take Microsoft Outlook for instance. When I switched to the Mac I stopped using Microsoft Outlook and began using Mail and iCal to manage all my email and tasks. These applications work good and I never really thought about Outlook or even missed it. However, yesterday, for work reasons, I started running Windows again as my primary development computer. In doing so I started using Outlook again.

Wow! What a nice application. When Microsoft Outlook first opens it is clean, tidy and well organized. I felt in control immediately. That’s how all software should be. Clean.

How do your products make your customers feel? What is their first impression of you and your company? Do you make them feel clean? Do you help them to feel in control? Let me encourage you to put in the extra effort to make a strong, positive first impression. It will pay dividends in customer satisfaction and loyalty.

    Three days ago my machine hung. I still don't know why. I had been away for a while, came back, moved the mouse... hang! Oh bummer. So, my only choice was to hard boot it. I really hate to do this, especially when I have an active development environment open and a Parallels session running. Nonetheless, it was my only option.

When I started Parallels after the reboot Windows dropped into disk check mode to make sure all systems were go; they were not. The Windows disk scan started spitting out all kinds of corrupted, orphaned, lost filenames, but after a while it said it had everything repaired and booted into the Windows desktop. After poking around a little everything appeared to be OK. Nothing lost. Nice. However, when I opened Visual Studio and tried to login to the Web Application I was working on, the login failed.

Argh! I was *just* working on this application yesterday without problems. <sigh> Something obviously went wrong on that hard reset. It took a whole day to figure out, but I finally realized that my SQL Server setup wasn't working properly. When I opened SQL Enterprise Manager, right clicked a table and selected "Display All" or "Display Top..." it would chug for a bit then pop up an error message that simply read "Unknown Error." Nice. I'd like to give a gold star to the guy that wrote that error dialog.

I tried everything I could think of to get SQL Server to work again. even replaced my virtual C drive with a back up virtual C drive from several months ago. When I did that it worked, but the back up drive was too old to utilize, so I had to revert back to the drive that was giving me troubles. However, with this new knowledge that the DB was not corrupt and SQL Server would work under the right conditions I pressed on. I twiddled the registry. I uninstalled and reinstalled SQL Server 2000 (twice). Still, nothing worked. Same error.

After much poking around on the Internet I finally came across this post. Down near the bottom Fotis Tsitsirigos writes "I had the same problem. The solution was to run the Norton Win Doctor. It found some kind of error in the registry, regarding the "msadce.dll" and fixed. Since then, everything works fine." Ah hah! So, I searched around a bit for how to "fix msadce.dll", but again, no success. Finally, I took Fotis' advice, went to Symantec and bought System Works, which includes WinDoctor.

Once I got everything installed, ran WinDoctor and let it fix the problems it ran across... Walla! SQL Server Manager is working again! Praise the Lord and Thank you Fotis Tsitsirigos!

Can't say this will work for everyone who gets the "Unkown Error" dialog, but it worked for Fotis and me!

Have a blessed day.

I'm a recent Mac convert, but that's a different story I'll tell another time.

What's important is that I am able to do my job, which is to write Windows software, on the Macintosh. I can do this because of an incredible application called Parallels. Parallels allows me to run Windows on my Mac, but better yet when run in Coherence mode Windows applications run seemlessly along side Mac applications as if the Mac were able to run Windows apps out of the box. It is truly an amazing thing to see.

I've been running in Coherence mode since one of the beta releases of Parallels and quite frankly have become adicted to it. I didn't realize how badly until it quit working one day. All of a sudden I started getting an error dialog in Parallels each time I would try to start it in Coherence mode.



I tried everything I could think of to get it working. I even posted a case on in the forums at Parallels to see if anyone else has had this problem. However, I got no response. So, since I had gotten so used to running in Coherence mode it just about drove me bonkers to run in "Full Screen" or "OS Window" modes. So, I kept trying to figure out what was going on.

Once day I got a core dump in Windows. You know, the BSOD, Blue Screen of Death. When that happened I took the time to investigate it a little and noticed that it was my video driver. Hmmmmm... So, as one of my last ditch efforts I tried reinstalling the Parallels Tools in Windows from the ISO image that ships with Parallels in hopes that it would reinstall the video driver and perhaps fix Coherence mode. Sure enough, after reinstalling the Parallels Tools... Walla! Coherence mode worked again! Praise the Lord! Thank you Jesus!

So, in an effort to share my joy, I wanted to post my results here in hopes that it helps someone else. Below are the steps I took to reinstall the Parallels Tools in Windows.

How to reinstall the  Parallels Tools in Windows:

1. On the Parallels menu select Devices -> CD/DVD-ROM 1 (or whatever the CD option is on your machine) -> Connect Image
2. Locate the file called "vmtools.iso" It should be located in the "Macintosh HD\Library\Parallels\Tools" directory.
3. Select the "vmtools.iso" file and press the "Open" button. This should cause the Parallels Tools installer to start automatically.
   
4. Follow the instructions given in the setup dialogs for Parallels Tools.
5. When the install is complete, restart Windows.
6. You should now be able to run in Coherence mode again.

I hope this has been helpful. Have a blessed day.

I use Windows XP for my development machine. I also work on two web applications that both want to be the default web site and will not run in a virtual directory. Therefore, I find that I’m always switching back and forth between these websites in IIS. So, today I went looking for a better solution and found this:

XP Pro IIS Admin
http://jetstat.com/iisadmin/

I’ve installed it on my machine and am pleased. To the best of my knowledge this is truly a free utility and not spyware, but I don’t know that for a fact. I hope you find it useful.

I added a new option to our web.config file today under the appConfig section. There was nothing special about this entry. It used a key / value pair where the key was a string and the value an integer. Again, nothing special. I added a comment above and closed the file.

Next I ran the debugger to test my recent changes. To my surprise I got a message box stating that the Debugger could not attach to the web server.

"Error while trying to run project: Unable to start debugging on the web server. Server side-error occurred on sending debug HTTP request.

Make sure the server is operating correctly. Verify there are no syntax errors in web.config by doing a Debug.Start without Debugging. You may also want to refer to the ASP.NET and ATL Server debugging topic in the online documentation."

(Note to self: read message boxes more carefully the first time in the future.)

Odd, I just debugged this thing a few minutes ago. Unshaken I rebooted my machine and waited; thinking that IIS had just temporarily gotten hung up. After the reboot, however, I got the following error when opening my project in Visual Studio 2003:

"The Web server reported the following error when attempting to create or open the Web project located at the following URL: 'http://localhost'. 'HTTP/1.1 500 Internal Server Error'.

<Sigh> One of those days I see.

I opened up Google and began to search for the solution. However, after poking around a bit I hadn't found anything that cured my problem. <sigh again>

At this point I started considering what changes I had made. What possibly could have effected the opening of a Visual Studio project. Ah hah! The web.config. I had changed the web.config! So, I opened up the file to look for typos. Hmmmm... nothing there. Everything looked fine. I removed my recent additions anyway, just to see if it would help.

It did! The file opened right up without error. Alright! Now to figure out what the problem was.

As it turns out the problem was part of the comment I had made for my recent configuration key. In my comment I had added multiple dashes (-----) as a separator for a example text I had added. As it turns out these dashes seem to have caused the Visual Studio project launcher to croak. Furthermore, they cause the Visual Studio compiler to be unable to function properly.

Example:
<!--
  This is an example of what *NOT* to do in a web.config file.
  
  You should not use multiple dashes like I do below.

  Example:
  --------
  Blah
  Blah

  or it will cause problems
  -->

So, the lesson here is: do not use multiple dashes (-----) in your comments for a web.config (or I'm guessing any .NET config file) or it will cause problems that are VERY difficult to track down.

We write a lot of code around here. As a result we often run into strange things that seem impossible to figure out. However, over the past 18 years, I have come to realize that with very few, if any, exceptions (no pun intended) the cause of even the most complicated errors can be determined.

Yesterday one of those very odd situations arose. We have a large application that is written in VB.NET and C#. When calling one of the the web methods on a web service written in C# I found that I was getting back nothing instead of the large set of data that was expected. Upon investigation I realized that this was only happening when the code was compiled for release and that the error does not occur in debug mode. Although this is odd, it is not complete unbelievable since it is possible that something was put into the debug only portion of the code that should not have been there. However, this time, that was not the case. The same exact code was getting executed in both modes.

The exception that was occurring was: "Invalid attempt to Read when reader is closed." The code block looked something like this:

---

Hashtable htObjects = new Hashtable();
SqlDataReader sdrObjects = null;

try
{

   sdrObjects = objectRepository.GetObjects(true);

   int intObjectId = 0;
   COurObject theObject = null;

   if (sdrObjects != null)
   {
      while (sdrObjects.Read())
      {
         intObjectId = sdrObjects.GetInt32(1);
         if (intObjectId != 0)
         {
            theObject = new COurObject();
            theObject.Load(intObjectId);

            AddObject(theObject, htObjects);
         }
      }
   }
}
finally
{
   if ((null != sdrObjects) && (false == sdrObjects.IsClosed))
   {
      sdrObject.Close();
   }
}

---

When I examined the logs I found that the SQL exception was being thrown in the loop over sdrTrades.Read(). So, I added a bunch more log entries to track exactly where things were breaking down since I could not trace things in the debugger. What I found was quite intriguing.

I discovered that if I put a log entry in the finally block that the code worked as expected; even in release mode. This is very odd considering that the actual exception was being thrown in the try block above. As I was explaining this to a friend of mine I told him that it seemed as if this were some sort of code generation error. Then it hit me: this piece of code didn't have a catch block.

So, I went back and added a catch block to the above code and walla! It worked in both debug and release mode. Furthermore, it didn't matter how much or how little error code I put in the catch block or whatever other changes I made to the code. As long as the catch block was in place the code works in both debug and release modes with out any strange errors.

I would really like to go back now and examine the IL code for both of the cases to see exactly what is going on. However, I don't have the time right now to do that because we are trying to get a product out the door. If I find the time in the future I'll post the results of that research here.

So, if you find yourself with a strange SQL exception in your C# code that only happens when you compile for release mode, you might just check to see if you are using a try / finally block without the catch. If you are, this might just be what is happening to you also.

I have spent days trying to figure out why my Visual Studio 2003 debugger hangs when trying to debug an ASP.NET application. The symptoms are that after pressing the debug button the application will act like it is going to get into debug mode, but it hangs somewhere in the process, never quite launching the application and never quite returning back to normal when the stop debugging button is pressed.

The error message I was receiving said something like "Auto-attach to process" aspnet_wp.exe Failed. Error code 0x80010012.

After searching and searching newsgroups online, I finally found one small line of advice that solved all of the problems. It simply read: "Sometimes enabling Unmanaged Debugging in your ASP.NET project settings will cause Visual Studio to hang." Walla! Eureka! that was it!

Last week I was trying to debug some historical COM objects and tried turning on this option to see if I could step into that code. However, I had forgotten that I had enabled this and have been struggling ever since.

Praise the Lord for this person who left the advice above. You made my week!