I am writing C# code that interfaces to a legacy (Feb 2012) C program, using DllImport. It works fine, but I need to call more than 30 different functions, turning my normally impeccable, exquisite code into something of near-elephantine proportions. Surely there must be a way around this? [Warning: those with weak stomachs may want to avert their eyes from what follows]:
[DllImport("C:\\Users\\mitt\\Documents\\Visual Studio 2010\\Projects\\mrSolution\\mr\\x64\\Debug\\mrDll.dll", CallingConvention = CallingConvention.Cdecl, CharSet = CharSet.Ansi)]
public static extern bool mrEngine_initialize( [In, Out, MarshalAs(UnmanagedType.LPStruct)] PLOT_SPEC PlotSpec);
[DllImport("C:\\Users\\mitt\\Documents\\Visual Studio 2010\\Projects\\mrSolution\\mr\\x64\\Debug\\mrDll.dll", CallingConvention = CallingConvention.Cdecl, CharSet = CharSet.Ansi)]
public static extern bool mrEngine_getDataPoint( [In, Out, MarshalAs(UnmanagedType.LPStruct)] PLOT_SPEC PlotSpec);
This is fairly inevitable with a C style api. The Windows api being a prime example of one with thousands of functions. Tying them together with handles. With the handle being the C style equivalent of this, the object reference for a class object.
The next leg up is a COM interface, it allows building an object model. Very common in Windows apis, looks like you lost out on that one.
This however doesn't stop you from creating your own object model, using C# classes whose methods and properties map in a logical way to the underlying C style api. The fugly code that implements your class members and makes the pinvoke calls can be hidden in a #region that you hopefully never have to look at again.
There is more than one benefit to doing it this way. Thinking about the object model mapping really helps you to understand the underlying api. And gives you plenty of unit test extension points. And makes you feel really good about creating order out of chaos.