Blogs

At its heart, a message pump is just a thread waiting for an event. Upon receipt of the event, some state data will instruct the thread how to proceed. In this article, we'll manage the state data by enqueuing and dequeuing task objects on a queue. The event is triggered by the producer thread once a task item has been enqueued. Many threads may add task items to the queue, but one thread reads from it.

I've long been a frequent user of the "Command Prompt Here" context menu plugin. But over time, it seems people haven't kept up with it or many of the implementations simply don't work. So I'll be maintaining this page with the latest versions of "Command Prompt Here" for Visual Studio users:

• Visual Studio 2008 Command Prompt Here (x86)
• Visual Studio 2008 Command Prompt Here (x64)

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.