Posted by admin on Aug 10, 2009 in
Windows Mobile UPDATE: Apparently, there is a different technology than Authenticode that I should be using for Windows Mobile.
Most of the documentation to sign code for the Windows Mobile device assumes you want to do it all through the Visual Studio enviornment. Well I don’t. Here is what you need to do to get your application signed as well as the install cab created and signed using the command line.
First, get your certificate from verisign, godaddy, or some other certificate authority. Follow their directions to install it in your store and create a *.pfx file. I used godaddy http://help.godaddy.com/article/5087.
Sign the exe using the signtool.exe
signtool sign /f {yourcert.pfx} /p {yourpassword} /t {http://yourtimeserver} {yourexe}
Second, You will need an ini file that cabwiz.exe will use to create the cab file. The easiest thing is to create a SmartDeviceCab project and use Visual Studio to determine what you will install on the device. When you compile this SmartDeviceCab project, it creates an ini file. You use this ini file to create your CAB file as your starting point. Run the following command to create the cab file:
cabwiz.exe your.inf /cpu CEDevice /compress
After you have created your cab file, you can then sign the cab file the same as you signed your EXE. That should be all there is to it.
Posted by jason on Aug 10, 2009 in
Windows Mobile Looks like I’ll be doing some Windows Mobile development again since it is going to pay the bills for a bit. Working with CloudSync on their GPS Logging utility. The devices basically log the GPS data at 5 second intervals. This data is then sent in batch to the servers for further processing.
The issue I worked on was making sure the data gets the server in a format that the PHP folks can recognize. Internationalization (i18n) created a problem because the dates and numbers were being sent in a different format. In Chile for instance, the dates and numbers were not coming out as we expected.
currentLatitude.ToString("#0.00000");
// this came out as 0,00000
gpsTime.ToString("MM/dd/yyyy HH:mm:ss");
// This came out as MM-dd-yyyy HH:mm:ss
Apparently, .NET converts these for you based on the NumberFormatInfo object and the DateTimeFormatInfo objects. I thought an easy way to correct this would be to set the current thread locale to be that of US so I could send the data in the expected format. In the full .NET world, you could write something like this to accomplish it:
http://msdn.microsoft.com/en-us/library/system.globalization.cultureinfo(VS.71).aspx
Thread.CurrentThread.CurrentCulture = new CultureInfo("en-US");
Unfortunately, the CurrentCulture property on the thread object is not available in the compact framework. Instead, you need to pass the culture object along with the format in the toString methods. You could create a CultureInfo object such as “en-US” and pass this, but .NET provides a better alternative. The CultureInfo object has a property called InvariantCulture. Using this object ensures that the behavior is consistent across all the different cultures.
currentLatitude.ToString("#0.00000", CultureInfo.InvariantCulture);
gpsTime.ToString("MM/dd/yyyy HH:mm:ss", CultureInfo.InvariantCulture);
After doing this, it is exactly as one would expect.