Xerratus
Happily stressed out, since 1974


 
Sunday, August 03, 2008

Over the weekend I helped launch a website that was located in the US but opted to host the site on a Canadian dedicated server.  One of the first things I did while setting up the server was to change the regional settings from "en-CA" to "en-US" (control panel -> regional and language options).  After pushing the site up to the server, I noticed during my testing that everywhere I was displaying dates (using the built-in .ToLongDateString() function of the DateTime object), the incorrect format was showing up.  Further more, transaction dates were being entered into the database incorrectly as well.

en-CA formats:

Short date: "dd/MM/yyyy"
Long date: "MMMM-dd-yy"

en-US formats:

Short date: "M/d/yyyy"
Long date: "dddd, MMMM dd, yyyy"

So, the computers region was setup correctly but the incorrect dates were still being shown.  Since the dates were being driven by a .NET object, I next looked at the .NET Framework (I'm running 2.0).  The solution I found was to modify the globalization element of the web.config by adding the following to the <system.web> element:

<globalization
   fileEncoding="utf-8"
   requestEncoding="utf-8"
   responseEncoding="utf-8"
   culture="en-US"
   uiCulture="en-US"
/>

Furthermore, since this was a dedicated server and all of the sites were going to be US sites we moved this from the web.config to the machine.config so that all new sites would not run into this problem.

Thursday, July 31, 2008

Here's one I just had to solve.  I had an xml string that was being passed to a sproc that used sp_xml_preparedocument to insert the values using OPENXML.  Problem was that the sproc was throwing the following error:

'An invalid character was found in text'

The odd thing was that the xml in question was valid in Visual Studio before it passed it to the sproc and did not have any illegal characters.  What I found was that by simply changing the input value from varchar(max) to nvarchar(max) sp_xml_preparedocument was able to parse the xml just fine. 

For a quick refresher, read up on nchar and nvarchar in T-SQL.

Friday, March 28, 2008

The other day, Visual Studio 2005 threw an odd error, seemingly out of the blue, that stated something to the effect "Error loading property page" (sorry didn't grab a screen shot of it because I didn't think it was anything) while trying to open a config file.  After clicking "OK", the file opened without any formatting, just black and white text.  To say the least, I was a little bummed; I love formatting.



Unfortunately, the day it happened, I was a bit swamped with work.  In all actuality, this happened over two weeks ago, I've just been too busy to look into it.  This morning however, I decided to take a few minutes before my day got started and look into fixing this problem.  First off, I wasn't sure what to Google and the vague things I could come up with were yielding little useful results.  I then decided to see if I could see if Visual Studio could tell me anything further.

I opened up "options", selected "Text Editor" then "XML".  The general property page seemed fine.  I then clicked on the "Formatting" option and there it was: "an error occurred loading this property page".  I now had something to search for.



Going back to Google, I searched for visual studio 2005 options xml formatting "an error occurred loading this property page" and the first result was this forum post which held the answer by Benson Yu - MSFT.
The issue was resolved by running “devenv /setup” in Visual Studio 2005 Command Prompt.
Nice!  So, I tried it out.



Note: I did this while Visual Studio was open and yes, it worked without needing to close it.

After the command prompt ran (which did take a minute or two, so be patient) I went back to Visual Studios XML formatting option and saw that my options were there again.



The web.config file I had opened was still black and white, so I closed and reopened it and my formatting was returned.



All is well again... now, back to work.
Monday, March 17, 2008

Happy St. Patty's Day...



Drink up!
Thursday, January 17, 2008

Recently, I uninstalled Vista and reinstalled XP on my work laptop.  Upon doing so, I had to reinstall all of my developer tools.  One of them was Visual Studio 2005.  Oddly enough, When I installed Firefox I opted to have it run as my default browser (when I was on Vista I had IE).  It didn't occur to me that this would cause any problems.  That was until I started debugging applications.

At first, all seemed fine.  Actually I thought it was going really good because after stopping the debugger, the web page remained open, something that didn't happen with IE.  But, as time went on, I found that my system slowed down once I started debugging anything.  Looking at the processes, I found that Firefox was using about 2 GB's of RAM.  Try sucking that into Visual Studio to debug.  Yeah, that'll cause some slow downs.  

So, I decided that, as much as I like Firefox, I'll set IE as my default browser.  Unfortunately, after doing this, Visual Studio kept debugging with Firefox and causing havoc with my machine.  So, I did a quick search and found this obscure forum thread that explained how to reset Visual Studio's browser.  And it's pretty simple.

First, open a web project.  Find any .aspx page and right click it and select "Browse with.."



There you should see a list of all available browsers plus the built in one.



Select IE from the list and click "Set as Default".



Close either by clicking "Browse" or "Cancel".  It doesn't matter which because the setting has been saved by this point.

Debug your application and notice that IE now opens up.  And much faster I might add.