Category Archives: Programming

My Visual Studio 2012 C++ 32-bit application is “exe is not a valid Win32 application”

I have a C++ application which I’ve just updated to be built using Visual Studio 2012. The original solution was developed in Visual Studio 2010, so I updated the project properties, Configuration Properties | General | Platform Toolset to Visual Studio 2012.

The application is a 32-bit application, everything was built for 32-bit and all worked well on Windows 7, but on Windows XP (which is still used by some of our users) it failed with the “exe is not a valid Win32 application”.

Checking the configuration manager suggested it was indeed a 32-bit application. Running dumpbin /headers app.exe confirmed it definitely was a 32-bit application but XP said no it wasn’t.

Here’s the thing – I hadn’t noticed when setting the Platform Toolset, there was a second option Visual Studio 2012 – Windows XP (v1100_xp).

Changing to this toolset fixed the problem. So 32-bit does not mean 32-bit on all Windows.

Populating random data

I was working on a small utility which generates XML based upon a given class (which is already XML serializable). I wanted to generate random data just so I could see how the end XML looked in case I needed to tweak the XSD.

Source for the utility is available on AutoGenXml.

I figured somebody must have already approached such a problem, and thankfully I was right. There are a few solutions for populating object data. I ended up trying out two different libraries, AutoFixture and NBuilder.

Disclaimer: I have literally only just started using these libraries, so I’ve yet to find all the good and/or bad points of each library.

Let’s take a real quick look at what these libraries can do.

Test object

Let’s start out by defining an object hierarchy to test this two libraries out on. Mine looks like this

public class Album
{
   public string Title { get; set; }
   public string RecordLabel { get; set; }
   public Artist Artist { get; set; }
   public string Genre { get; set; }
}

public class Artist
{
   public string Name { get; set; }
   public BandMember[] Band { get; set; }
}

public class BandMember
{
   public string FirstName { get; set; }
   public string LastName { get; set; }
   public string Talent { get; set; }
}

AutoFixture

AutoFixture source can be found on AutoFixture.

We can create objects with AutoFixture (hence using it as the factory for our objects) and it returns a populated object hierarchy.

Let’s look at the code (it’s pretty simple)

var fixture = new Fixture();
var album = fixture.Create<Album>();

The album will now have data in all fields and the Artist and BandMember properties are also created and data supplied.

Whilst it’d obviously be easy enough for us to create an object multiple times if we wanted a list of Albums but AutoFixture also supplies this code to do the same thing

var fixture = new Fixture {RepeatCount = 10};
var albums = fixture.
                 Repeat(fixture.Create<Album>).
                 ToArray();

NBuilder

NBuilder source can be found on NBuilder.

NBuilder also supplies a factory pattern for both creating our objects and populating the object.

Here’s the code

var album = Builder<Album>
               .CreateNew()
               .Build();

NBuilder uses a fluent style interface and offers options for creating multiple items (i.e. an IList<> of objects). There’s also a mechanism for us to intercept the object population step and supply our own data. So whilst in the usage shown above, we don’t have the object heriarchy created, we can create this ourselves fairly easily using

var albums = Builder<Album>
   .CreateListOfSize(10)
   .All()
      .With(a => a.Artist = Builder<Artist>.CreateNew()
         .With(b => b.Band = Builder<BandMember>
                    .CreateListOfSize(3)
                       .Build().ToArray())
	.Build())
   .Build();

References

This is a great post on using NBuilder with Faker which allows us to populate the objects with more realistic data than the default process.

Compiling C# code at runtime

Occasionally we might come across a problem which lends itself well to the idea of C# code being compiled at runtime, maybe we’ve created some script like plug-in or in my case I wanted to generate sample XML data from xsd.exe generated classes at runtime.

We can use the CSharpCodeProvider to do exactly this, it can compile some code, create an assembly (in my case in-memory) and then allow us to instantiate the code within that assembly. Let’s jump straight into some code and then we’ll look at how the code works

var param = new CompilerParameters
{
   GenerateExecutable = false,
   IncludeDebugInformation = false,
   GenerateInMemory = true
};
param.ReferencedAssemblies.Add("System.dll");
param.ReferencedAssemblies.Add("System.Xml.dll");
param.ReferencedAssemblies.Add("System.Data.dll");
param.ReferencedAssemblies.Add("System.Core.dll");
param.ReferencedAssemblies.Add("System.Xml.Linq.dll");

var codeProvider = new CSharpCodeProvider();
var results = codeProvider.CompileAssemblyFromFile(param, filename);

if (results.Errors.HasErrors)
{
   foreach (var error in results.Errors)
   {
      Console.WriteLine(error);
   }
}
else
{
   object o = results.
               CompiledAssembly.
               CreateInstance(typeName);
}

In the code above, we’re assuming that the source code we want to compile exists in a seperate C# source code file stored in the variable filename.

Firstly we create the CompilerParameters. I don’t want an executable to be generated and debug information will be of little use to me. I’m going to create the resultant assembly in memory as we’re not intending to write this to disc.

Next up we need to tell the compiler what assemblies will be required, ofcourse this might be best supplied in some alternate way, such as the script itself could be parsed or we might have another file with the assemblies listed, but for my purposes I’ll just list the “standard” assemblies.

We create a CSharpCodeProvider (as we’re working in C#) and passing the compiler parameters and the source code filename we get the code provider to compile the code. If any errors occur we simply list them (in this example, to the console).

Assuming all compiles we use the CompiledAssembly and create an instance of the type we’re interested in. In my example I supplied the typeName (i.e. class name) in the command line arguments to the application which uses obviously allows this code to be a little more flexible.

Once we’ve got the instance of the type we can obviously start interacting with it.

Invoking with generics using reflection

Sometimes we need to run methods or create types with generic parameters at runtime. For example, situation where the type is not known at compiler time but the method(s) we want to use expect the generic parameter to be supplied.

Let’s take a look at the syntax of various scenarios and you’ll get the idea.

Calling an instance method

So let’s assume we have some code like this

public class Runner
{
   public T Create<T>()
   {
      // do something
      return default(T);
   }
}

and we want to invoke this at runtime with an “unknown” (i.e. discovered at runtime) type. We can write something like this

object unknown = CreateType(); // generates some type at runtime

var runner = new Runner();

typeof (Runner).
   GetMethod("Create").
   MakeGenericMethod(unknown.GetType()).
   Invoke(runner, null);

This code would also work if the Create method was a static.

Note: we can ofcourse use typeof(Runner) or runner.GetType() in the above depending upon your preference or use.

Next up, let’s look at the same code but where we need to also pass the method a generic parameter.

public class Runner
{
   public T Create<T>(T type)
   {
      // do something
      return type;
   }
}

So the only real difference here is that we also need to pass the type into the method, a simple addition of the parameters to the invoke will allow this to work, here’s the code

object unknown = CreateType(); // generates some type at runtime

var runner = new Runner();

typeof(Runner).
   GetMethod("Create").
   MakeGenericMethod(unknown.GetType()).
   Invoke(runner, new []{ unknown });

Calling methods on a static class or extension methods

As you will know, extension methods are really just static classes with syntactic sugar to allow them to appear like instance methods, so the procedure for invoking them is the same as the normal static classed, but we’ll cover examples here all the same.

Let’s first look at a static class

public static class Runner
{
   public static T Create<T>()
   {
      // do something
      return default(T);
   }
}

The only real difference to the code for the instance method on a non-static class is that we do not pass a instance to the first parameter of the invoke method, like this

object unknown = CreateType(); // generates some type at runtime

typeof(Runner).
   GetMethod("Create").
   MakeGenericMethod(unknown.GetType()).
   Invoke(null, null);

As extension methods expect a “this” argument, they’re no different to the above code, expect that we need to ensure the first argument is the instance of an object

public static class Runner
{
   public static T Create<T>(this DoSomething doSomething)
   {
      // do something
      return default(T);
   }
}

public class DoSomething
{		
}

So this assumes Create is an extension method for the class, DoSomething. To invoke this Create method we can simply write

object unknown = CreateType(); // generates some type at runtime

var doSomething = new DoSomething();

typeof(Runner).
   GetMethod("Create").
   MakeGenericMethod(unknown.GetType()).
   Invoke(null, new object[]{ doSomething });

Classes with generic parameters

So now let’s move the generic parameter onto the class itself. We’ll begin by looking at static classes

public static class Runner<T>
{
   public static T Create()
   {
      // do something
      return default(T);
   }
}

So now we need to make the generic on the type not the method. We get this

typeof(Runner<>).
   MakeGenericType(unknown.GetType()).
   GetMethod("Create").
   Invoke(null, null);

Notice how the MakeGenericType is used to generate our generic class and the syntax of the typeof.

Obviously we might wish to create non-static classes with generic parameters as well, something like this

public class Runner<T>
{
   public T Create()
   {
      // do something
      return default(T);
   }
}

ofcourse we can’t simply create an instance to this class and use the same techniques of previous because the type of the generic parameter is not known, so we need to create an instance of this class via reflection then invoke the method – this can be accomplished with

var genericType = typeof (Runner<>).
	MakeGenericType(unknown.GetType());

var runner = Activator.CreateInstance(genericType);

genericType
	.GetMethod("Create").
	Invoke(runner, null);

In the above we need to use the genericType twice, so we store it in a local variable. The first time we use it is with Activator.CreateInstance this creates an instance of the class with a generic parameter. Next we use the same type but with the GetMethod call and ofcourse pass the instance variable into Invoke.

What about when we have more than one generic parameter

So what if we had something like this

public class Runner<T1, T2>
{
   public T1 Create()
   {
      var t2 = default(T2);
      // do something
      return default(T1);
   }
}

Obviously this is assuming T2 actually does something of use in our code.

All of the previous sample code will work, the difference is that we declare the typeof(Runner<>) as typeof(Runner<,>) and need to pass the extra parameters in the MakeGenericType method, for example

var genericType = typeof (Runner<,>).
   MakeGenericType(unknown1.GetType(), unknown2.GetType());

var runner = Activator.CreateInstance(genericType);

genericType
   .GetMethod("Create").
   Invoke(runner, null);

Increasing the maximum number of connections with maxconnection

By default when calling webservices etc. we’re limited to 2 maximum connections at a time in an application, so it doesn’t matter if you (for example) create multiple background threads to run webservice calls as you’ll still be limited to two connections.

We can change this using the App.config for our application and adding the following

<system.net>
   <connectionManagement>
      <add address="*" maxconnection="20"/>
   </connectionManagement>
</system.net>

See ConnectionManagementElement.MaxConnection Property

Note: The maxconnection does not apply to local web service calls

PowerArgs, command line parser

I cannot tell you how many times I forgot the name of this project when looking for a command line parser, so I thought the best way to remember it is by writing a blog post on the subject.

The github repository for PowerArgs has excellent documentation, so I will simply cover a few of the basics here, just to get things started.

PowerArgs is available via Nuget using Install-Package PowerArgs.

With PowerArgs we can define a class for our command line arguments and using PowerArgs attribute we define required arguments, optional arguments, argument descriptions and many other options. One very useful options is ArgExistingFile which tells PowerArgs the argument is a filename and it should exist.

Let’s look at some simple code. This class acts as my command line arguments for a simple Csv to Xml file application

public class Arguments
{
   [ArgRequired]
   [ArgExistingFile]
   [ArgDescription("The mapping file")]
   public string MappingFile { get; set; }

   [ArgRequired]
   [ArgExistingFile]
   [ArgDescription("The CSV file to convert")]
   public string CsvFile { get; set; }

   [ArgRequired]
   [ArgDescription("The output XML file")]
   public string XmlFile { get; set; }
}

In our Main method we’d then having something like this

try
{
   var arguments = Args.Parse<Arguments>(args);
   // use the arguments
}
catch (ArgException e)
{
   Console.WriteLine(ArgUsage.GenerateUsageFromTemplate<Arguments>());
}

In the above, we parse the args using the Parse method which will ensure the ArgRequired properties are supplied and the files exist via ArgExistingFile. If any required arguments are missing an ArgException occurs and we use ArgUsage.GenerateUsageFromTemplate to output a list of the command line arguments expect, as well as description of the arguments and we can also list examples.

Go look at the github repository PowerArgs for further documentation.

WPF Resources

Resources in WPF terms, are simply mechanisms for storing data, whether it be strings, colours, brushes, styles etc.

We can store such resources locally, within the scope of a Window or control or we can store the resources globally within the Application resources.

Resources are stored as key value pairs within a Resources section or ResourceDictionary. We therefore need to define a x:Key for each item in the resources, for example

<Window.Resources>
   <system:Int32 x:Key="ButtonWidth">100</system:Int32>
</Window.Resources>

In the above XAML we’re storing an Int32 type in the resource of a Window class. The key is “ButtonWidth” and the value is “100”.

Now let’s look at some example of using the resources.

<Window x:Class="Test.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="MainWindow" Height="350" Width="525">
    <Window.Resources>
        <FontWeight x:Key="Weight">Black</FontWeight>
    </Window.Resources>    
    <Grid>
        <Button Content="Hello World" FontWeight="{StaticResource Weight}" />
    </Grid>
</Window>

In the XAML above we are storing the resources within the scope of the Window. This means everything within the Window class will now have access to these resources but they’re not available outside of this Window.

We’ve created a FontWeight type resource with the key “Weight”. In the Button we use the resource to assign the value from the key “Weight” to the FontWeight of the Button. simply think of the key as a variable name.

Note: I’ll discuss the StaticResource at the end of this post

We can add resources to a top level UserControl (for example) just as we’ve done in the Window example, but we can also add resources to controls within a control or Window, for example, let’s take the Button from the above example but move the resource into the Button.Resources

<Button Content="Hello World">
   <Button.Resources>
      <FontWeight x:Key="Weight">Black</FontWeight>
   </Button.Resources>
   <Button.FontWeight>
      <Binding Source="{StaticResource Weight}"/> 
   </Button.FontWeight>
</Button>

Notice in the code above, we’ve used the Button.FontWeight element instead the FontWeight attribute of the Button (as per the original code). This is simply because when we add the resources in this way, these are now within the scope of the Button and unfortunately this means we cannot apply to the Button attributes themselves.

Application resources are defined in much the same way as for a Window resources but are available to all Windows/controls – in other words have global scope. We might declare our resource as follows

<Application x:Class="Test.App"
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
   StartupUri="MainWindow.xaml">
   <Application.Resources>
      <FontWeight x:Key="Weight">Black</FontWeight>
   </Application.Resources>
</Application>

Finally we can also create XAML files which are of type ResourceDictionary

<ResourceDictionary
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">  
   <FontWeight x:Key="Weight">Black</FontWeight>
</ResourceDictionary>

Now to use this ResourceDictionary from our Window (or control) we need to writing the following

<Window.Resources>
    <ResourceDictionary>
        <ResourceDictionary.MergedDictionaries>
            <ResourceDictionary Source="MyResources.xaml"></ResourceDictionary>
        </ResourceDictionary.MergedDictionaries>
    </ResourceDictionary>
</Window.Resources> 

This will merge the MyResources.xaml into the Windows ResourceDictionary and thus make the FontWeight resource available to the Window as if we’d declared it within the Window Resources. However by using the ResourceDictionary, not only can we create tidier code, removing possibly lots of resources from our views but also create libraries of resources that can be easily reused.

Resource Markup Extension

In the code above, we used the StaticResource markup extension. This is not the only option for binding to resources. We could also use the DynamicResource markup extension.

The use of StaticResource means that resource is resolved once at the point the XAML is loaded. Whereas DynamicResource allows us to in essence, late bind, to the resource. This means we can write XAML which might have a DynamicResource binding to a resource but the resource doesn’t need to exist until runtime. This option also allows the binding to update automatically if the resource changes. Hence if you want to bind to a resource which might change, then you can use a DynamicResource – this is obviously very useful when we’re dealing with the concept of themes.

And finally

In some cases we might want to use the resource in code. If we’re embedding the string for the key within the XAML, this means we’ll have to duplicate the string in code – duplication is not good. So instead we might prefer to store the string in source code to begin with and reference this in our XAML.

So let’s create a C# file named it whatever you like, I’m going to call mine’s Constants.cs

Now let’s just create the following static class

public static class Fonts
{
   public const string Weight = "Weight";
}

We can obviously use this “Weight” in our code, but in XAML we’re going to need to do the following change.

<!-- Original -->
<FontWeight x:Key="Weight">Black</FontWeight>

<!-- Becomes -->
<FontWeight x:Key="{x:Static local:Fonts.Weight}">Black</FontWeight>

.NET CLR Version Tool

I’d not come across this tool before, but whilst checking the location of the sn.exe tool I spotted it and thought I’d see what it did.

So the clrver.exe can be run from the Visual Studio command prompt or found at a location where your SDK exists, for example

"%ProgramFiles%\\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\clrver.exe"

Just running clrver.exe without any arguments will tell you which versions of the CLR are installed on your machine, whilst using the switch -all will result in a list of applications/processes running using the .NET CLR and tells us the version they’re using. If you already know the process id (pid) you can use clrver 123 to list the .NET CLR version being used by pid 123.

Observable.FromEventPattern discussed

I was actually looking through my past blog posts and noticed I’ve never published anything on Reactive Extensions (Rx). I actually have a draft “beginners” guide which I started a couple of years back, but never completed, so I may end up publishing that at a later date.

Note: The best resource for Rx information that I’ve found is Introduction to Rx, I’d definitely recommend you visit that site for complete and excellent documentation on Rx.

Okay, for this post I’m just going to focus on the FromEventPattern. Even though the syntax is pretty simple I have a habit of forgetting it everytime I come to use it, so as this blog is about refreshing my memory, I thought I’d write a blog post dedicated to this method.

Why use Rx instead of handling events in the conventional way?

One of the most obvious reasons to use Rx to handle events is that it can help stop those pesky memory leaks when we forget to unsubscribe to an event. Another reason is the IObservable returned from FromEventPattern is composable and we can filter events that we’re not interested in and/or marshal events from one thread onto another – for example when events are coming from a worker thread we might marshal them onto the UI thread.

Take a look at Observable.FromEventPattern Method to see the current syntax/overloads for this method.

I will not be covering all the overloads here but will instead look at the three I’ve used the most. So let’s get started…

FromEventPattern with an EventHandler which takes no EventArgs

In some cases you might have an event handler which doesn’t use EventArgs, for example

public event EventHandler Reverted;

in such a case we use the overload

public static IObservable<EventPattern<EventArgs>> FromEventPattern(
	Action<EventHandler> addHandler,
	Action<EventHandler> removeHandler)

So our code might look like this

var o = Observable.FromEventPattern(
   x => domainObject.Changed += x,
   x => domainObject.Changed -= x).
   Subscribe(_ => DoSomething());

FromEventPattern with standard event patterns (using the EventHandler class)

Building on the previous syntax…

In many cases, where the events that we want to subscribe to, use the “standard .NET event pattern”, (for example where the handler takes an EventArgs derived class) and were declared using the syntax

public event EventHandler<CellsInViewChangedEventArgs> CellsInViewChanged;

we will use this overload. Note: This version expects an EventHandler<> object.

public static IObservable<EventPattern<TEventArgs>> FromEventPattern<TEventArgs>(
	Action<EventHandler<TEventArgs>> addHandler,
	Action<EventHandler<TEventArgs>> removeHandler
)
where TEventArgs : EventArgs

To use this we simple supply the EventArgs derived type, for example

var o = Observable.FromEventPattern<CellsInViewChangedEventArgs>(
   x => grid.CellsInViewChanged += x,
   x => grid.CellsInViewChanged -= x).
   Subscribe(_ => DoSomething());

FromEvent pattern with standard event patterns (not using the Event Handler class)

Finally, for this post, in some cases we have events which do not use the EventHandler<> class, for example the WPF RoutedEvents use

public delegate void RoutedEventHandler(
   object sender, 
   System.Windows.RoutedEventArgs e)

In such cases we need to supply both the Delegate type and EventArgs type to the FromEventPattern, hence we use the syntax

public static IObservable<EventPattern<TEventArgs>> FromEventPattern<TDelegate, TEventArgs>(
	Action<TDelegate> addHandler,
	Action<TDelegate> removeHandler
)
where TEventArgs : EventArgs

our code will now look like this

var o = Observable.FromEventPattern<RoutedEventHandler, RoutedEventArgs>(
   x => button.Click += x,
   x => button.Click -= x).
   Subscribe(_ => DoSomething());

More…

I don’t intend to cover all the possible uses of the IObservable which is returned by the FromEventPattern, but suffice to say (as mentioned earlier). We can ensure events are marshaled onto the thread which created the observable, so for example if we create this from the UI thread we can write

var o = Observable.FromEventPattern<ValuesChangedEventArgs>(
   x => server.ValuesChanged += x,
   x => server.ValuesChanged -= x).
   ObserveOn(SynchronizationContext.Current).
   Subscribe(_ => DoSomething());

here, the ObserveOn will ensure that the events that might be coming from a worker thread are marshaled onto the current thread. Obviously if this was created on the UI thread this will marshal back onto that thread.

Creating awaitable types

If you’ve used async/await in your applications, you’ll generally await a Task, but you can actually make your own type awaitable. Let’s look at how we’d do this.

Why are Task’s awaitable?

A Task is awaitable, not because it’s a Task type, but its because it supports a specific method name which returns a TaskAwaiter or TaskAwaiter for the Task type. So let’s take a look at what this method looks like

public TaskAwaiter GetAwaiter()

So it’s really that simple, if we want to make our object awaitable we simply define the same method in our type.

What is a TaskAwaiter?

A TaskAwaiter is a struct which implements the ICriticalNotifyCompletion interface and the INotifyCompletion interface (the ICriticalNotifyCompletion derives from the INotifyCompletion). But this still wouldn’t make the TaskAwaiter awaitable it also needs the property IsCompleted and the method GetResult – more on this in “the rules for an “Awaiter” type” below.

It does seem strange that these methods weren’t all put into a single interface, but there you have it.

How do I create a bare minimum awaitable type?

Let’s first review the rules for making our type awaitable

  • Our type should have a method named GetAwaiter which takes no arguments and returns a suitable “Awaiter” type

and now the rules for an “Awaiter” type

  • The type should implement the INotifyCompletion interface or the ICriticalNotifyCompletion interface
  • It should have a IsCompleted property of type boolean
  • It should have a GetResult method which returns void or a result value
    • and now let’s put this together into a somewhat pointless type which demonstrates a bare minimum set of requirements to get this type to be awaitable

      public class MyObject
      {
         public MyAwaiter GetAwaiter()
         {
            return new MyAwaiter();
         }
      }
      
      public struct MyAwaiter
      {
         public void OnCompleted(Action continuation)
         {
            continuation();
         }
      
         public bool IsCompleted { get; private set; }
      
         public void GetResult()
         {			
         }
      }
      

      and now in use, we would have something like this

      var o = new MyObject();
      await o;
      

      Note: if you do not call the conitnuation() action in the OnCompleted method the code will block indefinitely.

      The flow of this code goes as follows…

      await o is called, this calls GetAwaiter on MyObject which returns a MyAwaiter. Next IsCompleted is checked, if the awaiter has already completed then control returns to the line after the await, if it’s false OnCompleted is called which basically blocks until the continuation is called, finally the GetResult method is called.

      Extension methods that are awaitable

      So we’ve discussed creating our own type, making it awaitable and even creating an awaiter type, but another approach which one might use is creating extension methods and instead of going to the hassle of creating an awaiter type, we’ll simply reuse the TaskCompletionSource type which can be used as a puppet task.

      Let’s go straight to some code which I’ve unashamedly lifted from Stephen Toub’s blog post await anything.

      public static TaskAwaiter<int> GetAwaiter(this Process process)
      {
         var tcs = new TaskCompletionSource<int>();
         process.EnableRaisingEvents = true;
         process.Exited += (s, e) => tcs.TrySetResult(process.ExitCode);
         if (process.HasExited)
         {
            tcs.TrySetResult(process.ExitCode);
         }
         return tcs.Task.GetAwaiter();
      }
      

      and we would use this as follows

      await Process.Start(“notepad.exe”)
      

      Looking at the extension method you can see we’re going to use the TaskCompletion classes GetAwaiter to return the awaiter type (in this case a TaskAwaiter) and we simply try to set the result on the TaskCompletionSource if, or when, the process exits.

      References

      await anything
      Design change: new “await” pattern for greater efficiency