Month: July 2014

Using NUnit for a .Net 4 project in a Jenkins installation

I have migrated my MBUnit tests to NUnit, considering MBUnit has been “on hiatus” for about a year now. NUnit is not much more agile, but at least there is a semblance of life on their Github account.

The switch has been surprisingly easy: change the namespace, change TestRow with Test, and change Row with TestCase. Easy!

Run unit tests in your continuous integration platform

In order to integrate the tests in our continuous integration platform, while minimizing build time, I have split the setup package build and the unit tests run. So I have a job that runs at each commit, that builds the project and generates the setup packages; and another job running at midnight, that only builds the project and runs unit tests.

Apparently, using the automatic package restore from Visual Studio is now obsolete with the latest Nuget versions. So I followed the instructions and migrated to Nuget package restore. Remember to download nuget.exe from nuget.org, add it to the CI server’s PATH, and restart Jenkins.

Add the NUnit Nuget packages to the test projects, and remember to add the NUnit Runner Nuget package to the solution! It will be much easier to run the unit tests this way (no need to install NUnit on the CI server).

I’m using PSAke for my build process (awesome tool!), so now my script looks like this:

And now my Jenkins jobs consist of a simple batch line:

I have sumbled on a System.BadImageFormatException while running tests in Jenkins using nunit-console, or trying to add the assemblies to the NUnit GUI runner. Here are a few things to remember:

Do not use AnyCPU

Your test assemblies, assemblies linked by your tests, and really your whole project, should be built in 32-bits mode, so that they can be run by the 32-bits test runner. Personnaly, I created a “NUnit” solution configuration just for this. It allows me to select which assemblies are built in which case: no need to build tests in the general build, and no need to build stuff like bootstrapper exes in the test build.

Check your build paths

If you create a new configuration like I did, remember to change the build path! My main project builds in the \build\app folder, and my tests are located in \build\tests. I spent a few minutes wondering why the platform change did nothing, before finding out that my x86 test assemblies were in bin\x86\NUnit (the default value).

Check the framework version

Select the proper .Net framework with the /framework:net-4.0 switch. NUnit should be able to find out automagically, but sometimes it doesn’t.

WPF/SOAP configuration for third-party webservice with empty security headers

I am writing a program that accesses a SOAP webservice written by a third-party provider.

I need to provide a user and login in the SOAP headers, which is kind of easy, in theory:

  • add the webservice reference to Visual Studio
  • instantiate a new “XXXXClient” generated class
  • set xxx.ClientCredentials.UserName.UserName and xxx.ClientCredentials.UserName.Password

Easy as pie. Except when it’s not. You see, the provider’s webservice is written using php, it does not behave nicely with .Net. When you send the request, you can see on Fiddler that the query is sent and gets a response, but .Net does not like this response, and throws exceptions around.

First problem: it throws a MesssageSecurityException because of empty security headers in the response (see here). I first thought that I had the same problem, so I spent the day resolving the issue following this blog post, but it turns out it’s much more simple. To fix this, you must set the enableUnsecuredResponse in the binding’s security node to true. And in order to do that, your binding must be a customBinding. If you have a complicated binding, good luck switching.

Second problem: the mime type for the request and the response are different (“text/xml” vs “application/soap+xml”). To fix this one, you have to write your own custom text encoder (download the WCF examples at the top), and to do that… you have to create something like a thousand classes with a hundred lines each. Just for a simple mime type mismatch! Do not forget to also copy, from the downloadable examples, the BindingElement, BindingSection, ConfigurationStrings, and MessageVersionConverter !

So, for such a simple task, as is too often the case with Microsoft, I need to rewrite (or copy, here) a whole bunch of stuff, just to modify some pretty mundane and common behavior, which should be configurable in the first place. It shows how extensible WCF is, and how bloated the extending is.

Anyway, here is a working app.config. For the code of the custom text message encoding class, as I said, just copy the MS examples (and don’t forget to rename the types in the bindingElementExtensions).

 

Debug integrated WPF WebBrowser scripts using Visual Studio

Copied and modified from another blog for future reference.

Note that in order to debug the Javascript inside a WebBrowser control, you don’t need the source code of the application (neat!).

  1. Open Internet Explorer, go to Settings, tab Advanced, and, in the “Navigation” section:
    • Uncheck “disable script debugging” (both IE and Other)
    • Uncheck “Display friendly HTTP messages”
    • Check “Display a notification about every script error”
  2. Open an instance of Visual Studio. Open the Tools menu, Attach to Process, and on the “Attach to” line, click “Select…”, and only check “Script”.
  3. Run the program including the WPF BrowserControl
  4. Attach the Visual Studio instance to its process.

Now, open the “Solution explorer” tab/toolbox. You will see every Javascript file loaded by the WPF WebBrowser control, and you can add breakpoints where you want.

Tested with IE 11 and Visual Studio 2010.

Creating a C++/CLI wrapper around a C library

So, following my previous post, I have decided that I might try C++/CLI after all, since the SWIG way goes nowhere except “down in flames”, and I really need to implement it.

Turns out that creating a C++/CLI wrapper around a fairly well-made C library is not that hard.

Considering the following .h file from the C library (which are the methods and structures to interface):

Add the .h and .c files to a new C++ CLR DLL project, then add a new cpp file, in which we will replicate all the C structures as classes.
We have to name our classes differently than the C structures, otherwise there will be conflicts, both with the compiler, and in our heads.

The annoying thing when like me, you know pretty much nothing about C/C++, is that you never know where to specify pointers and stuff, and it’s mostly trial and error (it says it can’t build, let’s add a *… nope, a & ? Yes, that seems to work).

A few things to note:

  • Provide internal ToNative() methods on the structure wrappers to ease up marshalling from managed objects to native structures.
  • Also provide internal constructors taking a native structure as parameter, to ease up marshalling from native to managed.
  • The “^%” syntax (for the “images” parameter of the “Pack” method) builds to a “ref” in the .Net method signature. Otherwise the calling C# can’t get the values back.

As you can see, it’s not that difficult after all. I guess for an experienced C/C++ developer it would be even more simple.

Using SWIG to create a .Net wrapper around a C library

A consultant has written a C library to neatly pack images on a space. They have integrated it in their Ruby On Rails / Node.js online app through the power of extending Ruby. I’m quite jealous, because it’s not quite as easy to do in .Net. Especially when, like me, you know absolutely nothing about C/C++.

Two options are available to me:

  • Create a C++/CLI project, that will generate a .Net DLL
  • Use SWIG to generate a .Net wrapper around the C code.

Now, since I can’t change much the C code (it must be built on Mac through Ruby), I thought that I couldn’t easily switch it to CLI (I was wrong ; see the next post).

So I tried using SWIG. And it’s a pain to use. Let me walk you through creating a wrapper around a non-trivial C library.

Generating basic wrapper methods is pretty easy: it’s a matter of creating a .i file with a few lines of code:

Run SWIG on this file to generate a few C# files and a C wrapper class:

Then, you create an empty C/C++ library project with Visual Studio, include all the necessary files, and generate it. It builds a DLL, and you can include both the C# files and the DLL in your .Net project to use. Very nice, very simple.

A problem arises when you have a C method taking an array as argument: SWIG generates a C# signature taking a single instance as argument:

You can tell SWIG to create an “intermediate” array type by adding this to your .i file:

This creates an “image_t_array” class, with methods for setting and getting items, old-school-style. There is also a method to cast it as “image_t”, with pointers handling to go back and forth in the array.

Now, creating an array class, and cast as instance to pass it as parameter is not very intuitive, and I’m trying to create a usable wrapper. I want to pass an actual, managed array to my method. Is that so hard?

The SWIG documentation has a whole part about passing managed arrays to non-managed code. The problem is that (once again), the documentation is incomplete. It shows an example for a managed arrays of ints… but not an array of structs. Apparently it doesn’t work the same way, because SWIG complains about a missing typemap when using this:

Actually, a totally undocumented feature needs to be called just above this line:

Thanks to a nice fellow on StackOverflow for reading the SWIG sources… Googling for “CSHARP_ARRAYS” yeilds exactly zero result in the documentation, but only a few relevant results on forums and mailing lists. Why is it not documented, while it’s obviously necessary? If it’s not the right way, which is? Why not documenting the warning message that appears when you don’t use it?

So anyway, now my C# method takes a managed array as argument, which makes this library so much more easy to use. It throws a memory access exception when running the “pack” method, though (System.AccessViolationException).

Thankfully I have both the source files, and the pdb file for the unmanaged dll. I just have to copy the pdb to the target directory (using my test program post-build events), and once I activate unmanaged code debugging (managed project properties / debug  /activate unmanaged code debugging), I can step through the library, using the actual C code! Awesome.

At the actual point that an error occurs, I can see that the library tries to access an image in the array that is not defined. Weird. By adding a few breakpoints in the C library (I can’t imagine how I would have debugged that without the source code…), I quickly notice that my “*images” (in the pack) have very weird values, and that they do not correspond to the sent values at all.

Since passing values as arrays might do weird things with pointers, I decide to switch back to using the “image_t_array” class… and sure enough, now the values are correctly passed. I still have memory access problems, though, but that seems to be on the C side… but it runs nicely when a C++ program calls it, so I still have some digging to do.

At this point, debugging the wrapper becomes very complicated with all the layers involved, so I decided to try the C++/CLI way which, as you may see in my next post, is not that hard after all.