A Programmer's Dream

C Libraries and .NET

Posted by Stephen Wrighton on 02 Apr 2007

This is still insane. I spoke early last week about .NET and my C Library problem - which is the root cause of me not having any spare time to blog about programming and have discovered a bit more.

If I run the library directly through a C++.Net Console application it works without a problem. But if I try to use the DLL version even in the Console application it gives me the NULL REFERENCE exception.

The only thing that makes sense to explain this issue is that since the DLL version uses a class as a container for the various methods where I pass data to/from the library in a "managed" way this is setting aside a certain bundle of memory for the library. Which the library tries to get outside of by doing a MALLOC call, and thus resulting in the NULL REFERENCE exception.

So I'm faced with three possibilities (excluding retiring the project, which is a decision I can't make):
  1. Rewrite the libraries in a .NET language
  2. Write a C++.Net console application and call that from the VB.Net GUI when I need to do something - passing data through the command line and file I/O
  3. Write a Windows Service in C++.Net and pass data to/from the service via the Message Queues
Option 1 was shot down in an earlier meeting - but it's always there. So that leaves us with options 2 and 3.

Now, I can admit it's been years since I've done any serious C++ programming. Not since I graduated college - it's an atrophied skill as my job is a VB shop. The closest I've come is a bit of C# programming when the task I need/want to do is easier to implement there than in VB.

So with that in mind, I came up with this table to determine which of the last two options I should consider.




Use a Windows Service and Message Queues to send/receive data


Use either a series of task-specific console applications or a single console application with task flags. Use VB.Net to launch those applications and feed in parameters on the command line. Output saved to a file which the VB.Net application then reads in.


· Simpler to maintain than a series of task specific applications

· Can pass well-defined data easily through the message queues

· No File I/O


· Easier to develop


· Harder to code

· More complex system


· Memory Intensive from launching all the small applications

· Slow due to File I/O

Need to Learn

· Coding windows service in C++.Net

· Using Message Queues in C++.Net

Need to Learn

· How to launch other applications within VB.Net via its internal scripting system

· Refresh how to pass arguments into a console application via the command line when the system begins executing

Tweet me @kidananubix if you like this post.