Category Archives: C#

yield return inside a using block

This a short post to act as a reminder.

I decided to refactor some code to return IEnumerable (using yield return) instead of returning an IList. So I have a method named Deserialize which creates a memory stream and then passes it to an overload which takes a Stream. For example

public IEnumerable<T> Deserialize(string data)
{
   using (MemoryStream memoryStream = new MemoryStream())
   {
      memoryStream.Write(Encoding.ASCII.GetBytes(data), 0, data.Length);
      memoryStream.Seek(0, SeekOrigin.Begin);

      return Deserialize(memoryStream);
   }
}

public IEnumerable<T> Deserialize(Stream stream)
{
   // does some stuff
   yield return item;
}

The unit tests thankfully spotted straight away a simple mistake. In that the using clause is exited before the first yield return takes place. So the stream is disposed of, and therefore invalid, when the overload tried to access it. Doh !

Thankfully it’s easy to fix using the following

public IEnumerable<T> Deserialize(string data)
{
   using (MemoryStream memoryStream = new MemoryStream())
   {
      memoryStream.Write(Encoding.ASCII.GetBytes(data), 0, data.Length);
      memoryStream.Seek(0, SeekOrigin.Begin);

      foreach (var item in Deserialize(memoryStream))
      {
         yield return item;
      }   
   }
}

Obviously we could have alternatively used something like

return new List<T>(Deserialize(memoryStream));

but this then negates the purpose of using the yield return in the first place.

Redirecting standard output using Process

If we are running a console application, we might wish to capture the output for our own use…

Asynchronous output

By default any “standard” output from an application run via the Process class, is output to it’s own window. To capture this output for our own use we can write the following…

using (var p = new Process())
{
   p.StartInfo = new ProcessStartInfo("nant", "build")
   {
      UseShellExecute = false,
      RedirectStandardOutput = true
   };

   p.OutputDataReceived += OnOutputDataReceived;
   p.Start();
   p.BeginOutputReadLine();
   p.WaitForExit();
   return p.ExitCode;
}

The above is part of a method that returns an int and runs nant with the argument build. I wanted to capture the output from this process and direct to my own console window.

The bits to worry about are…

  1. Set UseShellExecute to false
  2. Set RedirectStandardOutput to true
  3. Subscribe to the OutputDataReceived event
  4. Call BeginOutputReadLine after you start the process

Synchronous output

If you want to do a similar thing but capture all the output when the process ends, you can use

using (var p = new Process())
{
   p.StartInfo = new ProcessStartInfo("nant", "build")
   {
      UseShellExecute = false,
      RedirectStandardOutput = true
   };

   p.Start();
   p.WaitForExit();

   using (StreamReader reader = p.StandardOutput)
   {
      Console.WriteLine(reader.ReadToEnd());
   }
   return p.ExitCode;
}

In this synchronous version we do not output anything until the process completes, then we read for the process’s StandardardOutput. We still require UserShellExecute and RedirectStandardOutput to be setup as previously outlined, but no longer subscribe to any events or use BeginOutputReadLine to start the output process.

ReactiveUI 5.x changes

I’m not sure when these changes were made, but I just updated an application to use both .NET 4.5 and the latest NuGet packages for ReactiveUI (version 5.4) and looks like quite a few things have changed.

This post is just going to show some of the changes I’ve hit whilst migrating my code. This is probably not a full list as I haven’t used all the parts of ReactiveUI in my applications thus far.

RaiseAndSetIfChanged

// old style
this.RaiseAndSetIfChanged(x => x.IsSelected, ref isSelected, value);

// new style
this.RaiseAndSetIfChanged(ref isSelected, value);

See the post on CallerMemberNameAttribute for more information on how this works. With this we no longer need to write the lambda expressions required by earlier versions.

Note: For raising events on properties other than the current property, i.e. if IsSelected is a property above and IsUpdated should also raise a property change event we use

this.RaiseAndSetIfChanged("IsUpdated");


RxApp.DeferredScheduler

It would appear that the RxApp.DeferredScheduler has been renamed as RxApp.MainThreaScheduler. Admittedly a better name.

RxApp.MessageBus

Looks like we just use the MessageBux.Current instead.

ReactiveAsyncCommand

It appears that ReactiveAsyncCommand has merged into ReactiveCommand, so changes look like this

// old stype
ClearSearch = new ReactiveAsyncCommand(null);
ClearSearch.RegisterAsyncAction(o =>
{
   // do something
});

// new style
ClearSearch = new ReactiveCommand();
ClearSearch.RegisterAsyncAction(o =>
{
   // do something
});

but there’s more

// old style
OK = ReactiveCommand.Create(_ => true, DoOK);

// new style
OK = new ReactiveCommand();
OK.Subscribe(DoOK);

If we need to enable/disable commands then we can pass an IObservable into the first parameter of ReactiveCommand, for example

OK = new ReactiveCommand(this.WhenAny(x => x.Text, x => !String.IsNullOrEmpty(x.Value)));


IReactiveAsyncCommand

As above, IReactiveAsyncCommand has been merged into IReactiveCommand.

ReactiveCollection

This has been renamed to ReactiveList.

Supporting initialization using the ISupportInitialize

This post doesn’t really explain anything too exciting, it’s more a reminder to myself on the existence and possible use of this interface

Admittedly the ISupportInitialize interface tends to be thought of, almost exclusively at times, as an interface used by UI controls/components. In that if you look at the code in the designer.cs file you may find controls which support ISupportInitialize, for example

((System.ComponentModel.ISupportInitialize)(this.grid)).BeginInit();

this.grid.Name = "grid";
this.grid.Size = new System.Drawing.Size(102, 80);
this.grid.TabIndex = 5;

((System.ComponentModel.ISupportInitialize)(this.grid)).EndInitInit();

But this interface is, ofcourse, not limited to controls/components. It’s defined for “simple, transacted notification for batch initialization” so why not reuse it for initialization of other code if need be.

In situations where your code might be getting setup/initialized and you maybe not wanting events to fire or the likes during the initialization phase, why not just implement the ISupportInitialize interface and use the BeginInit, EndInit pattern.

How about creating a simple helper class to automatically call a classes BeginInit and EndInit methods if it supports the ISupportInitialize

public class SupportInitialization : IDisposable
{
   private ISupportInitialize initSupported;
   public SupportInitialization(object o)
   {
      initSupported = o as ISupportInitialize;
      if (initSupported != null)
         initSupported.BeginInit();
   }

   public void Dispose()
   {
      if (initSupported != null)
         initSupported.EndInit();
   }
}

Is my application’s UI still responsive ?

We might, on occasion, need to check whether an application we’ve spawned has a responsive UI or ofcourse we might wish to check our own application, for example within a timer polling the following code to check the application is still responsive.

Firstly, we could use the property Responding on the Process class which allows us to check whether a process’s UI is responsive.

Process p = Process.Start("SomeApplication.exe");

if(!p.Responding)
{
   // the application's ui is not responding
}

// on the currently running application we might use 

if(!Process.GetCurrentProcess().Responding)
{
   // the application's ui is not responding
}

Alternatively we could use the following code, which allows us to set a timeout value

public static class Responsive
{
   /// <summary>
   /// Tests whether the object (passed via the ISynchronizeInvoke interface) 
   /// is responding in a predetermined timescale (the timeout). 
   /// </summary>
   /// <param name="si">An object that supports ISynchronizeInvoke such 
   /// as a control or form</param>
   /// <param name="timeout">The timeout in milliseconds to wait for a response 
   /// from the UI</param>
   /// <returns>True if the UI is responding within the timeout else false.</returns>
   public static bool Test(ISynchronizeInvoke si, int timeout)
   {
      if (si == null)
      {
         return false;
      }
      ManualResetEvent ev = new ManualResetEvent(false);
      si.BeginInvoke((Action)(() => ev.Set()), null);
      return ev.WaitOne(timeout,false);
   }
}

In usage we might write the following

if (IsHandleCreated)
{
   if (!Responsive.Test(this, reponseTestDelay))
   {
       // the application's ui is not responding
   }
}

Hosting IronRuby in a C# application

After writing the post Hosting IronPython in a C# application I decided to see how easy it was to host IronRuby in place of IronPython.

Before we go any further let’s setup a project. Create a console application (mine’s just named ConsoleApplication) and then, using NuGet, download/reference IronRuby. The version I have is 1.1.3.

Allowing our scripts to use our assembly types

Let’s look at some code

public class Application
{
   public string Name { get { return "MyApp"; } }
}

class Program
{
   static void Main(string[] args)
   {
      string code = "app = ConsoleApplication::Application.new\n" + 
                    "puts app.Name";

      ScriptEngine engine = Ruby.CreateEngine();
      ScriptScope scope = engine.CreateScope();

      engine.Execute("require 'mscorlib'", scope);
      engine.Execute("require 'ConsoleApplication'", scope);

      ScriptSource source = engine.CreateScriptSourceFromString(code, 
                     SourceCodeKind.Statements);
      source.Execute(scope);
   }
}

Here, as per the IronPython post, we create some scripting code, obviously this time in Ruby. Next we create an instance of the Ruby engine and create the scope object. We then execute a couple of commands to “require” a couple of assemblies, including our ConsoleApplication assembly. The next two lines will also be familiar if you’ve looked at the IronPython post, the first of the two creates a ScriptSource object from the supplied Ruby code and the next line executes the code.

All looks good, except I was getting the following exception

An unhandled exception of type ‘System.MissingMethodException’ occurred in Microsoft.Dynamic.dll

Additional information: Method not found: ‘Microsoft.Scripting.Actions.Calls.OverloadInfo[] Microsoft.Scripting.Actions.Calls.ReflectionOverloadInfo.CreateArray(System.Reflection.MemberInfo[])’.

I found the following post IronRuby and the Dreaded Method not found error which demonstrated a solution to the problem.

If we insert the following line of code, after the last engine.Execute line

engine.Execute("class System::Object\n\tdef initialize\n\tend\nend", scope);

or in Ruby code we could have written

class System::Object
   def initialize
   end
end

this will solve the problem – I don’t have any explanation for this, at this time, but it does work.

What if we already have an instance of an object in our hosting application that we want to make available to IronRuby ?

As per the IronPython example, we can simply set a variable up on the scope object and access the variable from our script, as per

string code = "puts host.Name";

ScriptEngine engine = Ruby.CreateEngine();
ScriptScope scope = engine.CreateScope();

scope.SetVariable("host", new Application());

engine.Execute("require 'mscorlib'", scope);
engine.Execute("require 'ConsoleApplication1'", scope);

ScriptSource source = engine.CreateScriptSourceFromString(code,        
          SourceCodeKind.Statements);
source.Execute(scope);


Using a dynamic to create our variables

Even cooler than creating the variables using SetVariable on the scope object, if we change our scope code to look like the following

dynamic scope = engine.CreateScope();

we can add the variables directly to the scope dynamic variable, for example

scope.host = new Application();

Hosting IronPython in a C# application

Let’s use IronPython as a scripting language within our C# application.

Note: an application I work on uses an earlier version of IronPython and they’ve significantly changed the way you use it, so this information is only relevant for version 2.7.x of Python

What are we trying to do here ?

So, the premise is this. I have a C# application and I want to allow a user/ops or whoever to write scripts which can interact directly with the running instance of the application and/or the types within an assembly. Standard scripting fair I’m sure we’d all agree.

Let’s start off by downloading the package IronPython via NuGet. The version installed is 2.7.4.

To create the Python scripting engine we use the following

ScriptEngine engine = Python.CreateEngine();

We could alternatively create a runtime and then get the engine from it, as per

ScriptRuntime runtime = Python.CreateRuntime();
ScriptEngine engine = runtime.GetEngine("Python");

Now, unlike earlier versions of the scripting engine, it appears (unless I find information that differs from this view) that we no longer really have a global scope for writing our scripts but instead create a scope ourselves (i.e. in earlier versions we could add variables and execute code on what appeared to be a global level).

So we need to create a script scope using

ScriptScope scope = engine.CreateScope();

Now we can interact with this scope, importing modules, executing code and adding variables.

Allowing our scripts to use our assembly types

Let’s assume our application adds a bunch of types/classes that we might instantiate from IronPython. To make these available to the Python code we need to use the CLR from Python to add references to our assemblies, but in this instance we don’t want the script writer to have to do this every time, so we write

scope.ImportModule("clr");

engine.Execute("import clr", scope);
engine.Execute("clr.AddReference(\"MyAssembly\")", scope);
engine.Execute("from MyAssembly import *", scope);

In the above we import the CLR module into the scope object and then execute some Python code using the engine, against the scope we created. As eluded to, we could have written these commands in every Python script as per the code below

import clr
cl.AddReference("MyAssembly")
from MyAssembly import *

but I think you’d agree it’s much better to let the host setup this code instead, especially if we wanted to add lots of assemblies.

Now from Python we can instantiate classes from MyAssembly. For example, if my host application included an assembly called MyAssembly, with the following class definition

public class MyLibrary
{
   public void Run()
   {
      Console.WriteLine("MyLibrary run called");
   }
}

then, from Python we could write the following

r = MyLibrary()
r.Run()

Putting this altogether to show how we can reference an assembly and create the types within the said assembly, just create a console application project called ConsoleApplication and enter the following

public class Application
{
   public string Name { get { return "MyApp"; } }
}

class Program
{
   static void Main(string[] args)
   {
      string code = "app = Application()\n" +
                    "print app.Name";

      ScriptEngine engine = Python.CreateEngine();
      ScriptScope scope = engine.CreateScope();

      scope.ImportModule("clr");

      engine.Execute("import clr", scope);
      engine.Execute("clr.AddReference(\"ConsoleApplication\")", scope);
      engine.Execute("from ConsoleApplication import *", scope);

      ScriptSource source = engine.CreateScriptSourceFromString(code, 
                     SourceCodeKind.Statements);
      source.Execute(scope);
   }
}


What if we already have an instance of an object in our hosting application that we want to make available to IronPython ?

So in this instance we use the following, from the hosting C# application

scope.SetVariable("host", this);

where, in this example, we pass in an instance of the hosting application. Now from Python we can call methods on the variable host, i.e. assuming the hosting application has a method named ShowMessage, we could write the following

host.ShowMessage("Hello from Python")

Finally, let’s say we have everything setup and we have a text editor embedded in the hosting application with a run button, when run is pressed we want to run the code entered into the text editor, thus

var source = engine.CreateScriptSourceFromString(code, SourceCodeKind.Statements);
source.Execute(scope);

the above code takes the source code (the code variable), then executes it in the given scope.

We could load the script from a file if we wished using

engine.CreateScriptSourceFromFile(filename);

where filename is string representing the location and filename of the Python script file.

Putting this all together into a simple example, just create a console application project and enter the following code

public class Application
{
   public string Name { get { return "MyApp"; } }
}

class Program
{
   static void Main(string[] args)
   {
      string code = "print application.Name";

      ScriptEngine engine = Python.CreateEngine();
      ScriptScope scope = engine.CreateScope();

      scope.SetVariable("application", new Application());

      ScriptSource source = engine.CreateScriptSourceFromString(code, 
                     SourceCodeKind.Statements);
      source.Execute(scope);
   }
}

Using .NET reflection to dynamically create methods with generic parameters

Following on from my post Dynamically creating C# code using the CodeDomProvider I’ve created a new type dynamically using the CodeDomProvider and I now need to use the type within a generic method call.

So to start with, I have a DataSerializer class (the basics are shown below – I’ve just distilled it down to the method signature that we’re interested in for this post)

public class DataSerializer<T> where T : new()
{
   public static IList<T> Deserialize(IDelimiterSeperatedReader dsr, 
              string data, DelimitedDeserializeOptions options)
   {
      // method implementaion
   }
   // other methods
}

From the previous post I have a dynamically created type (so I just have a Type object, the variable generatedType shown in the code below). I need to create a call to the static method (Deserialize) with this type as a type generic parameter.

Type generatedType = cr.CompiledAssembly.GetType("CsvGeneratedData");

Type[] arguments = { typeof(IDelimiterSeperatedReader), 
                  typeof(string), typeof(DelimitedDeserializeOptions) };

Type dataserializer = typeof (DataSerializer<>);
Type typedSerializer = dataserializer.MakeGenericType(generatedType);
MethodInfo mi = typedSerializer.GetMethod("Deserialize", 
               BindingFlags.Public | BindingFlags.Static, 
               null, arguments, null);

In the above the arguments variable is an array of Type’s in the order of the arguments the method Deserialize takes. We then use

This code creates the MethodInfo object but we now need to invoke the method itself, so we use the following Type dataserializer = typeof (DataSerializer<>) to create a DataSerializer but at this point it does not have the generic parameter assigned to it, so we then use MakeGenericType to assign the generic parameter to the dataserializer. Finally we get the method info. for the static method we want to call.

Now we need to invoke the method using the following

mi.Invoke(null, parameters);

where parameters is an object array with the relevant method arguments.

Dynamically creating C# code using the CodeDomProvider

I’ve been working on some code which generates C# classes. Basically it creates POCO classes to allow me to serialize/deserialize data from a data file into the POCO classes. The data file format can change and so this code allows me to easily regenerate the classes I need. This works fine, but I thought it might be better if I could create the code on the fly and use in without having to recompile the application (that would otherwise include the compiled source). In other words I wanted to create the C# classes and then generate the types and use them all dynamically at runtime.

.NET includes the CodeDomProvider class which can easily be used to create an assembly with our types created on the fly.

Here’s the code

CodeDomProvider provider = CodeDomProvider.CreateProvider("CSharp");

CompilerParameters cp = new CompilerParameters();
cp.GenerateInMemory = true;
cp.TreatWarningsAsErrors = false;
cp.ReferencedAssemblies.Add("putridparrot.Data.dll");

CompilerResults cr = provider.CompileAssemblyFromSource(cp, source);

The above is pretty self explanatory, but let’s go through it anyway.

First off, we create a CodeDomeProvider specifying the provider we require for C# code. We can (currently) create code dom’s for the following languages

  1. CSharp – C#
  2. VisualBasic – VB.NET
  3. JScript – JavaScript
  4. Cpp – C++

Next we create the compiler parameters. In this instance we want the code generated in memory, as opposed to using a file and I don’t want “warnings as error’s” in this instance. I do however need to add any of my referenced assemblies. In this case the code uses one external assembly, the putridparrot.Data.dll (as the generated code uses attributes from this assembly to mark the properties of the POCO for serialization/deserialization).

Finally we compile the code into the assembly from the source code supplied (in this case the string source contains the C# class to be compiled). The CompilerResults may include errors, so we can check this by using the following

cr.Errors.Count

Assuming we’ve no errors, then we can now access a compiled type by interacting with the assembly created by the CodeDomProvider, for example

Type type = cr.CompiledAssembly.GetType("AutoGeneratedDataType");

The CompiledAssembly is just a standard Assembly at this point, so obviously you can do all the standard things you can do on any other Assembly object.

Side note

As a side note we can iterate over the languages supported via the CodeDomProvider using the following

CompilerInfo[] compilerInfo = CodeDomProvider.GetAllCompilerInfo();
foreach (var ci in compilerInfo)
{
   string[] languages = ci.GetLanguages();
   foreach(var language in languages)
   {
      Console.WriteLine(language);
   }
}

Beware an exception in a ReactiveCommand

The Reactive UI class ReactiveCommand can be used to implement a view model’s commands as per the following:

Synchronize = ReactiveCommand.Create(_ => true, DoSynchronize);

This is excellent and works like RelayCommand and DelegateCommand from other MVVM frameworks, in that the first argument of the Create method handles the CanExecute and the second is the Action to be executed when ICommand.Execute is called.

One problem this usage has, is in the case of an exception within the command’s action. As Reactive UI uses Reactive Extensions it also handles errors in the same way.

When an error occurs in Reactive Extensions the default behaviour after an OnError is that subscribers are unsubscibed, in other words no further calls are made to your subscribed Action.

In the case of ReactiveUI’s ReactiveCommand this means if an exception occurs during the Action the command essentially disconnects itself and further commands are ignored. So a simpler way of solving this is to use ReactiveAsyncCommand.

Synchronize new ReactiveAsyncCommand(null);
Synchronize.RegisterAsyncAction(_ => DoSynchronize());

This way a new IObservable is created each time a command is executed, thus an exception will simply stop the current IObservable and the next time the command is called a new one is created.