What are the pros and cons of creating a .NET wrapper of an unmanaged DLL?

Question

Is it a waste of time or there is an obvious & measurable benefit of creating a .NET wrapper of an unmanaged DLL?

More information:

• I don't control the DLL, however I can decide not to replace it with the newest version.
• The DLL has many classes. And many supporting enumerations.
• The DLL provides the project with critical features.

Answer 1

The DLL has many classes

This is a strange question but important details are missing. If you want to use these classes from managed code then you have no choice but to write a C++/CLI wrapper for them. Only the C++ compiler can properly construct them. P/Invoking the constructor isn't technically impossible, although it is quite painful to find its exported function name, you cannot guess how much memory to allocate for the object. Only the C++ compiler knows.

Writing wrappers isn't very difficult, it is largely mechanical. You'll find more details about it with links in this answer.

Answer 2

Pros:

1. It's a lot easier to use the functionality of the DLL in .NET projects
2. You could write your own loader of the unmanaged DLL so that you don't have to rely on the algorithm in LoadLibrary.
3. You could add isolation later so that the unmanaged DLL stays out-of-process

Cons:

1. It's a lot of work

If you can wrap the DLL and then also provide a simpler, smaller interface with just what you need, then it might be worth it.

Also, I know that you said that you can't control the DLL, but if you could, a C++/CLI wrapper of a .lib is a lot nicer way to use unmanaged code in .NET (mostly, this is for others that see this question, or if you can get access).

Answer 3

A few benefits that I know of:

1. You can put xmldoc in your managed wrapper and therefore have documentation available to all developers inside the IDE.
2. You can abstract away all IntPtrs, which can be a source of trouble and bugs for less experienced developers.
3. You can build higher-level operations for common scenarios out of lower-level building blocks in the unmanaged DLL, reducing the possibility of errors. (Of course, this one isn't specific to wrapping unmanaged DLLs).

Answer 4

You can wrap the management of resources used by the 3rd party code with code that implements IDisposable which will allow the .NET garbage collection to be used to free up resources (file handles etc.) that you are no longer using.

Other benefits - standard for pretty much all 3rd party code include:

You are insulating most of your code from any changes that might occur in the 3rd party dll in the future. If anything changes you just have to change the implementation in your wrapper class. The rest of your code remains unchanged.

You could also build in caching, validation and error checking into the wrapper class if any of these were lacking in the unmanaged code.

Answer 5

Pros:

1) Some sort of security of your algorithms if they are in unmanaged dll;

2) Prevent bottlenecks of GC. Full control of memory;

Cons:

1) You must support both of 32bit and 64bit builds of your unmanaged dll if you want to use 64bit .Net environment;

2) Must create very tiny interface (bridge) between managed and unmanaged code for prevent degradation of speed. Sometimes it is impossible;

Answer 6

If you want to use this DLL in a C# or VB.NET project (or any other .net language except C++/CLI), I don't see any reasonable alternative (provided you are not going to recreate a managed version DLL completely from scratch). Of course, you could use COM instead, but in most cases that be will be harder and much more work with a much worse result from the view of a .NET client project.

EDIT: ok, according to your comments the DLL is already a COM Dll. Then you don't need a .NET wrapper any more, of course. My answer was intended for the case were you have a plain-old-native C++ DLL, where using COM means "adding a COM wrapper" to it.