I was listening to a talk on Relevant Radio from their show “Changed Forever” by Father Larry Richards and he described  atheism in a light that I think really illustrates the scary reality of what it means to say that one is an "atheist."   What he said might be something you've already thought about, as I have, but it's definitely worth remembering in case you ever get into a conversation about your faith with a professed ‘atheist.’

In a nutshell:  An atheist will never know if he is right, a believer will never know if he is wrong.

We all know that no one can prove that God exists, nor can we prove he doesn't.  So, you've got a 50% chance of being right no matter what you think.  Those odds might sound really great if the were the odds of winning the lottery, but they might sound really horrible if you're about to play an involuntary game of Russian Roulette!

As an atheist, if you are right, you'll never ever, ever, ever, ever, ever (on to infinity) know if you are right because you'll be dead and death is forever.  There is no way for a dead person to tell the living about life after death unless there actually is life after death, in which case the atheist would be wrong.

As a person of faith, you'll never ever, ever, ever (etc) know that you're wrong because you'll be dead.

As an atheist, if you are wrong, you will spend eternity knowing that you were wrong.  An eternity, mind you, knowing that you denied God's existence when you were alive, so I wouldn't expect that He would be willing to give you the ‘royal treatment’!

As a believer, if you are right, you'll spend eternity knowing that every moment of your life that you invested in following in Jesus’ footsteps was infinitely worth it.

So, do you know anyone who is “a gamblin' man”?

While attempting to retrieve a list of installed databases on my PC using SQLDMO in C#, I found that the named instances of SQL never showed-up no matter what I did.  Since my PC only has two named instances of SQL server installed and no default instances, this created a problem!

As it turns-out, the Windows Firewall was blocking calls to the SQL Browser’s UDP port 1434.  If you turn-off your Windows Firewall, you should be able to retrieve all named instances of SQL Server that are installed on your PC.  I opted to un-block this port so my app would work.

When trying to test a long web form, it gets really annoying having to manually populate the form with information only to submit the form to see your error and then have to do the whole thing over again once you think you’ve fixed the problem.

Since I don’t own a copy of Visual Studio .NET 2005 Testing Edition, I haven’t had much luck with finding good ways to test the UI (i.e., good ways to pre-populate forms for testing.) Of course, one way to test a form is to actually set all the values in a form on the ASPX page and then hope you remember to delete all those values once you publish the site. However, this becomes very annoying if you don’t get things right the first time.

To make my life easier and make UI testing less painful, I came-up with a nifty way to "cheat"... I’ve started using conditional compilation to populate my forms when Visual Studio is in DEBUG mode, but leave the forms blank when in RELEASE mode. So far, it works pretty slick, provided that I remember to compile my code in release mode before publishing it!

I wish I would’ve know about conditional compilation a while ago… it’s a really neat feature. It took me a while to get it working properly, and here is how.

1. Start with a Visual Studio 2005 Web Application Project instead of the Visual Studio 2005 Web Site Project.  Note that you’ll have to download the Web Application Project because created after Visual Studio was released.  The application project behaves more like the Visual Studio 2003 web project and gives you “Build” options in the project’s Properties menu.
   
2. Once you have the web project created, right-click on the project title and select Properties and then the Build tab.  You should see a screen like this.
   
   
3. While Configuration is set to Debug, leave Define DEBUG constant and Define TRACE constant checked.  Then switch Configuration is set to Release and uncheck Define DEBUG constant and Define TRACE constant.
   
   
4. The rest is easy.  In your code, you can use the conditional compilation directive #if to make sure the code you use to pre-populate your forms only exists in your code when Visual Studio .NET is in Debug mode:
   
   protected void Page_Load(object sender, EventArgs e) {
   

           if (!Page.IsPostBack) {

   #if DEBUG

               this.txtFirstName.Text = "John Doe";

   #endif

   }
   }

5. Run your site in Debug mode and you should see your textbox named txtFirstName populated with “John Doe”.  Run it in Release mode and your form should be blank.  Sweet!

Obviously, to keep your code a bit cleaner, you should probably create a method that contains all your form population code and you can mark that method with a conditional attribute by marking it with [Conditional(“DEBUG”)].  Note that you will have to add the System.Diagnostics namespace to your file in order for this attribute to work.

So there you have it!  Make your UI testing a bit easier and still keep your production code clean.

Ok, ok... it's not stealing because Microsoft said we can do it!   If you've ever wondered if you could use the icons in Visual Studio for other applications, apparently you can: Brad Abrams Blog: Standard Microsoft Icons

One thing that was painfully lacking in Visual Studio 2003 was the ability to work with XML and XSLT.  Most people opted to purchase third party tools like XML Spy to deal with VS.NET's inadequacies.  However, Visual Studio .NET 2005 has a group of new tools that add things such as XSLT debugging and Intellisense that make working with XML related files much more tolerable.

In addition, the .NET Framework 2.0 has undergone some significant improvements in the System.XML namespace.  If you work with XML on a frequent basis, you'll want to be sure to read through these MSDN articles and see what's new in version 2:

• An Introduction to the XML Tools in Visual Studio 2005
• XML Namespaces and How They Affect XPath and XSLT
• What's New in System.Xml for Visual Studio 2005 and the .NET Framework 2.0 Release