windows

You are currently browsing articles tagged windows.

I have created a simple C# WinForms sample to interface CDYNE.com SMS API. More information on the API can be found here: http://wiki.cdyne.com/?title=SMS_Notify!

The API source code is on GitHub: https://github.com/gunsh/CDYNESmsSample

Additionally, here is a simple video showing the process of simple console app creation. Enjoy!

kick it on DotNetKicks.com

Tags: , , , , ,

New Microsoft® Surface® 2.0 SDK has been released along with the Microsoft® Surface® Migration Power Toy which is aimed at helping all the Surface 1.0 code to the new SDK.

There have been numerous changes in the new SDK to play along with the WPF 4 and its integrated touch support. The Power Toy is there to help migrate all the Surface 1.0 code with a very low estimated manual work needed for seamless transition.

I tried the Power Toy and immediately hit the brick wall. I kept getting a failure from the tool.

Error: Project "System.__ComObject" could not be loaded. Error: Object not set to an instance of an object.

When I dug a little deeper in the source code it turned out that one specific case was not handled properly. Luckily there is a simple fix without getting much deeper into understanding the specifics of the code. There is a method RemoveReference() in ProjectExtensions.cs on line 31 that is doing a C# “as” instead of a cast but not checking for a null. Actually, “as” is perfectly valid here but the null check is definitely missing. All of my Surface 1.0 projects have a “Miscellaneous Files” Project but these do not cast to VSProject and thus the exception.

Luckily, all that needs to be done is to just add a single line of code and all starts working beautifully. Add the following on line 34 and life will be good again.

            if (vsProject == null) return false;

Hopefully this saves someone a sleepless night. Cheers!

kick it on DotNetKicks.com

Tags: , , , ,

I encountered a XAML puzzle today. Luckily, it was easy to solve although it did take some time to find out.

Suppose that you want to keep part of your WPF UI in a file external to your main application. Normally, all of your XAML is embedded as a Page resource in your application. This translates to a compiled XAML, also known as BAML. Allowing the outside world to specify a piece of XAML that you will show in your app can be useful in a number of scenarios. It is not something you will do every day but there are applications that could hardly do without this.

Now let’s suppose you create a brand new UserControl in your Visual Studio project. You will get a UserControl1.xaml and a UserControl1.xaml.cs. We can’t (or don’t want to) load code so just remove the .CS file. Now, we add something specific. We want to reference say some attached property from our own project. Let’s say the namespace is Email and the property is Caption on class Details.

<UserControl x:Class="Email.UserControl1"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:Email="clr-namespace:Email"
             Email:Details.Caption="Test">
    <Grid>
        <TextBlock Text="Hey!" />
    </Grid>
</UserControl>

How can we load this XAML file in our application and make it work as if it was compiled as part of the project? XamlReader comes to mind. Let’s try.

var userControl = XamlReader.Load(fileStream) as UserControl;
var caption = Email.Details.GetCaption(userControl);

Ok, this works but if we check the value of attached property we will discover it has a default value. Now why is that? Maybe we are using a wrong approach. If we try to load this with Application.LoadComponent() it will succeed beautifully.

var userControl = Application.LoadComponent(new Uri("/Email;component/usercontrol.xaml", UriKind.Relative)) as UserControl;

That worked with a local resource but what if we want to use LoadComponent() to load the file external to the application from an arbitrary URL? No, that won’t work. LoadComponent() will throw an exception complaining about the absolute URL. Basically, you can’t use LoadComponent() on anything but a local URL.

So what are our options? Huh, reflection perhaps? Doing what LoadComponent() does but skipping the relative URL check? No, that won’t work because relative URLs are there for a reason. LoadComponent() really loads from BAML not XAML.

After hours of pondering, searching and trial and error I finally came up with a surprisingly simple solution. We go back to the trusted XamlReader. What we need to do is just slightly change the xmlns:Email declaration by adding the assembly=Email like this:

<UserControl x:Class="Email.UserControl1"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:Email="clr-namespace:Email;assembly=Email"
             Email:Details.Caption="Test">
    <Grid>
        <TextBlock Text="Hey!" />
    </Grid>
</UserControl>

Voila! The XAML is finally loaded properly with our attached property accurately set.

Tags: , , , ,

If you are a serious developer releasing software to the public you are surely already using Authenticode signatures to sign your code and let the world know it came from you. You can obtain an Authenticode certificate at some certification authority (e.g. Verisign). These certificates are normally valid for one, two or three years, depending on how much cash you want to spend upfront. Normally, you get discounts the more years you purchase.

Once you get your Authenticode certificate you can start signing your executables and libraries (DLLs) both managed and unmanaged as well as setup packages (MSI). You can only sign your target files while your certificate is valid. The day your certificate expires, you can no longer sign your files with it. If you want to continue signing, you must purchase a renewal or a brand new certificate.

To do the actual signing you need to run your Visual Studio 2008/2010 Command Prompt and issue a command similar to this:

signtool sign /f key-file /p password /v your-target-exe-dll-or-msi-file

Ok, let’s say you have signed your installer (SETUP.EXE). If you run it from some untrusted location (e.g. download it from the Internet), double-clicking it will produce a dialog similar to this:

Looks good! This is exactly what you want to make your software look professional, right? Well, yes and no. The way we have just signed our file is only good enough for as long as our Authenticode signing certificate is valid! Now, what does that really mean? Well, let’s put it this way. Say you purchased your code signing certificate on January 1st and its validity period is one year. On January 1st next year it is no longer valid. All software you signed with the above method will only show as signed in the current year for as long as signing certificate is valid. As soon as your certificate expires, your software will show as *unsigned* like in the image below!

To prevent this from happening be sure to timestamp your signed files. Timestamping is really just another command line option to the above signing syntax but with a big significance. With timestamping you supply an URL to your certification authority’s timestamp service (this varies depending on where you purchased your certificate).

signtool sign /f key-file /p password /t http://timestamp.verisign.com/scripts/timstamp.dll /v your-target-exe-dll-or-msi-file

Timestamping really means “please make this file be known as valid from here to eternity”. So timestamped files never expire. They will always show as valid regardless of whether your certificate expired or not.

There is another implication of timestamping. You may purchase your Authenticode code signing certificate, use it for say one year for an unlimited number of timestamped code signings. Even if you stop producing software at some point and your certificate eventually expires, your previously signed files will remain signed and shown as valid even to users  in the 23rd century and beyond.

For more information you can also take a look at this Verisign article.

Tags: , ,

I had a quick C++ job once for a client that eventually bailed out on me. So I decided to share the code so other may find good uses for it. This is a short write-up describing the issue the client had and a simple way to get around it.
The client needed RAW access to arbitrary blocks on a Flash drive for both reading and writing, especially in the unused portion of the drive. So I decided to bite the bullet and created a working solution. And it was fun too!
It appears as if Windows will block raw access to certain sectors if Flash drive is NTFS formatted. For FAT or FAT32 there are no problems accessing anything on the Flash drive. The big revelation idea is to simply use DeviceIoControl with FSCTL_LOCK_VOLUME to actually unlock the Flash immediately after opening it like so:
BOOL success = DeviceIoControl(m_hDevice,
    FSCTL_LOCK_VOLUME,
    NULL,
    0,
    NULL,
    0,
    &dwReturned,
    NULL);
After doing this, all of Flash is directly accessible for both reading and writing. Basically, you can render the Flash unreadable and destroy your data unless you know what you are doing. You won’t destroy the Flash physically of course. All you need to do after playing is reformat it and all will be well.
So here is the full source code. Please rename remove DOC extension. It is just a 7-zip file.

Tags: ,