Unicode support in NSIS

To support Unicode TP installer has been updated to Unicode NSIS v.2.46-1. Here is how to start using new version:

1. Install it. New installer can be found in the same trunk/Utilities/NSIS folder as the old one. After installation copy the contents of trunk/Utilities/NSIS/NSIS folder (i.e. Include and Plugins folders) to the directory where NSIS has been installed (most probably c:\Program Files(x86)\NSIS). Do not forget to update Path variable for NSIS if necessary.

2. Convert NSI-scripts to Unicode. Usually, all that needs to be done to convert old installation scripts to Unicode NSIS is convert the NSI script file from an ANSI text file to a UTF-16LE file or as of 2.42.3, UTF-8 file.

3. Update NSIS plugins. Newer versions of some plugins (such as AccessControl, OLEDB, some others) provide Unicode support so you won't have to make any changes in the way these plugins are used.

4. Update NSIS scripts if necessary. If some plugins don't have Unicode version then CallANSIPlugin.nsh (can be found in trunk/Utilities/NSIS/NSIS/Include) will help you: use PushAsANSI, PushAsUTF8, PopAsANSI, PopAsUTF8 to convert string arguments before passing them to and after retrieving result from a macros/function. If you are using System plugin make sure that you are not calling the ANSI specific Win32 API. Most such API end with the letter A, for example: MessageBoxA(). Such API should either be converted to the tchar version such as MessageBox() or the wide-char version such as MessageBoxW().

And that's it.

DateTime and JavaScritSerializer

Hi, all!

Let me show you a small unit test

1 [Test]
2 public void ShouldSerializeDateCorrectly()
3 {
4 var date = new DateTime(2011, 8, 8);
5 var serialized = new JavaScriptSerializer().Serialize(date);
6 var deserialized = new JavaScriptSerializer().Deserialize<DateTime>(serialized);
7 Assert.That(deserialized, Is.EqualTo(date));
8 }

How do you think it will behave? I'll surprise you: it fails.

The reason of such a strange behavior is described here. The main point is that deserialization assumes the value is serialized using GMT time.

Ok, that's funny, but how exactly it can affect TargetProcess? We're moving to REST little by little, but there are still many places where client javascript code communicates with TP server through web services using the power of ScriptServiceAttribute. Guess how the data passed to server is deserialized?

So, please be careful when accessing DateTime objects passed from client javascript and don't forget to convert it to local time as I would do to make my test pass.

1 [Test]
2 public void ShouldSerializeDateCorrectly()
3 {
4 var date = new DateTime(2011, 8, 8);
5 var serialized = new JavaScriptSerializer().Serialize(date);
6 var deserialized = new JavaScriptSerializer().Deserialize<DateTime>(serialized);
7 Assert.That(deserialized.ToLocalTime(), Is.EqualTo(date));
8 }
9