As I mentioned in a recent post, our test department submitted a defect to us regarding the XML Serializer when running under a Japanese username.

We were able to replicate using a small test application which isolated the call to the XML serializer only, but then we had to isolate the environment which led to this problem.  It worked fine under English usernames, and fine under OTHER systems which used a Japanese username, so after trying a few permutations and eliminating unneccessary steps, we reduced it to the following:

1. Install Windows Vista (we used Ultimate edition)
2. Change System Locale to Japanese
3. Create User using japanese characters
4. Change System Locale to anything other than Japanese
5. Run Test Program - exception

What was curious about this was if we omit Step 2 then we do not get the exception, and if we include Step 2 but omit Step 4 then we also do not get the exception.

We should be hearing from Microsoft soon about this, and I'll post the results here when they are received.  Because of the nature of reproducing this exception is so contrived, I'd be surprised if we can do anything about it.

As I've mentioned, we are currently submitting our application for Vista Certification, and one of the tests we have to pass is that it supports Unicode.

Although the program itself is fine, being a .NET application, our test teams discovered a problem when trying to install to a directory which contained non-Latin characters.

Our installer modifies an XML document, and this is where it fails.

To isolate this problem, we wrote a test install that used the IS XML action to modify an XML file in the install dir.  Sure enough, when we installed it to a directory containing Japanese characters, it reported the same error.

After consultation with Acresso, they have conceded it is a bug in IS.  I'll post news of a patch/workaround if we get one.

Our company is submitting our product for Vista Certification at the moment, so our test department have a list of checks as long as Bao Xishun's arm.

A number of these tests check to see if the program runs correctly under various locales, especially those locales that use non-Latin based alphabets.  As internationalization was never really a design goal, even though we get unicode support by default in .NET, it fell over at this point.

However, what was a surprise was WHY it failed.  The XmlSerializer threw an exception as it could not write to the temp directory of the user, which on Vista, is <UserName>\Local\Temp

The username contained Japanese characters, but the exception report displayed these as '?' - showing that it couldn't properly resolve them.

On a hunch, I didn't really suspect our code was at fault - we weren't doing anything other than serializing a class, which worked fine for other character sets - so I quickly put together a test which just checked the XML Serialization and nothing more.

Sure enough it fell over again, so it will be interesting to see the resolution of this.  It could be that we need to set certain environment settings in the Application, but it could also be a problem with the .NET framework itself.

We're sure to find out soon.

Not rocket science, just put here for my own future reference.

We want to add User Actions to each row of a datagrid.  Using the DevExpress ASPxGridView control, we create a DataColumn and then add a DataItemTemplate to this.

In the code in-front, add the following reference to code-behind:

<p><%#MakeActions(Container.DataItem)%></p>

In the code-behind, the MakeActions method should look something like th

        public string MakeActions(object dataItem)
        {
            StringBuilder sb = new StringBuilder();
            int id = Convert.ToInt32(DataBinder.Eval(dataItem, "ID").ToString());
            sb.Append("<a href=\"" + "Details.aspx?id=" + id.ToString() + "\"><img border=0 alt='Open Record' src='Images/folder_go.png'></a>");
            return sb.ToString();
        }

where DataItem is the bound data object of that row.  Clicking on this item will therefore link to the Details.aspx page, passing through the id on the querystring.