Blog.Write()

The easiest way for me to decide what to blog about here is to share the solution to problems I couldn't find an answer for with a simple Google search. This is one of those cases. First, there is a great quick reference for using P/Invoke at Code Project. So if you're new to the subject read that first and consider this a supplement.

The particular case being examined here is for dealing with a pattern where a native assembly returns a pointer then later needs you to pass a double pointer to that object.

On any project of sufficient complexity, there comes a time when things need to be setup a particular way in order for the product to function correctly. It could be late-bound assemblies, native libraries, data files, etc. Visual Studio provides a means to perform pre- and post-build actions on a given project in the project properties dialog. There are countless other blogs out there which cover this in detail. In this post I make the case against that approach and why you should probably use a dedicated project for all your postbuild needs.

Windows services can be the most frustrating things to develop. You carefully write all your code in a library separate from your service facade. Maybe you even write a console facade for debugging. You create an army of unit tests which all pass. The only thing left is this small bit of code in the Windows Service project which instantiates and runs your library... and it crashes.

Here's a tool I've recently added to my personal library: Future Delegate

A Future Delegate is essentially an encapsulation of an asynchronous delegate inside a generic class which handles all the details of calling and waiting for the delegate to return. It works like this:

1. Write a method to do some work asynchronously.
2. Create a Future and pass in a delegate to your method.
3. Do other stuff...
4. Call Future.Value whenever you need to result of the operation.