Unmanaged code in .Net

Question

We have a custom Listview Treegrid in c++ project built on the Codeproject TreeGrid example from here. The code has been modified quite extensively over time.

I have a requirement to port the c++ project to C# Winforms. I'm thinking of creating a c++ dll for the Listview grid and interoperate with it in Winforms.

Am I asking for for trouble using an unmanaged Listview control in Winforms? Should I just port/rewrite the listview in Winforms? (A task I do not look forward too)

Answer 1

If I were you, I would prefer rewriting the Listview in C# or looking for a free or paid Grid that was written in C# and is meant to be used in Winforms.

Don't forget that you will have to support the code after you do this job, this probably includes fixing bugs and adding features. It's better to know exactly how your code works and how to debug it. You also gives you a chance to write a Listview that is better suited for your needs.

This will be quite difficult if you'll use this C++ Listview and use it in Winforms. But if you decide using it, there are two options that I can think of:

1. Creating a wrapper for the Listview in C++/CLI that will hold the object and show the data in C#, this means that you will have to write a lot of conversion code to move the data from the Listview to the C# objects, but it should work.

2. Using DllImport and working with the ListView as a datasource, I'm not really sure how exactly you will be able to get all the data from it, but it prevents you from writing the ugly CLI code...

So to wrap it up, I recommend using a single language for UI code, and my language of choice for UI is C#, not C++.

Good luck...

Answer 2

I think it would be best to re-write it in managed code.

Interoperability usually works, but there's a reason managed code is preferred. The runtime takes care of so many things for you, and it's just easier to maintain all around. Crossing the boundary can be problematic for some tasks. You also lose Code Access Security, for example. There's some good info here.

If you don't then you'll always need a .NET developer and a c++ developer to maintain it.

There's nothing wrong with c++/native code on its own, but mixing the two. I just think it's better long term not to mix unless you have to.

That said, there are time and budgetary constraints. Interop exists for a reason. If it would absolutely take too long to justify from a business sense, I'd retract the above recommendation.