Short answer

You should consider that it’s a very risky and costly idea that may not give you as many benefits as you think it might.

Long answer

You should consider the following:

C++ is a language that can be used at a very high level, that is cross platform (though that depends on how much you used the VC proprietary extensions) and for which many very mature tools exist. C++11 will add even more juicy bit to handle annoying use cases.

If you’re thinking about a full rewrite, don’t forget that rewriting fully debugged code is time you won’t be implementing any new features. If you don’t have a clear benefit for using C#, this is throwing money and time through the window.

If the team knows C++, then for a long time writing code in C# will be slower despite any advantage that C# brings.

You have two option for migrating your apps : restart from scratch (and see http://joelonsoftware.com/articles/fog0000000069.html , already posted), or add new features by maintaining a mapping layer between the C++ and C# code. While C# is quite good as far as calling native code go, it’s still some pretty complex code to write. If you either use P/Invoke or C++/CLI, both will force you to know much deeper detail about the platform than would be required for a pure C# solution. Also, you’ll spend an awful lot of time marshalling data between managed and native code. A better option may be COM, though I hope you like ATL programming.

The biggest benefits of C# are its simplicity and garbage collector that free you from thinking about a lot of corner cases. That mean it can be developed by developers that are less hardcore than what you need for C++. In your case, your team already know C++ so those benefit are much less present. If you use unique_ptr, shared_ptr, RAII and such, much of the dangerous part of C++ can be managed. Yes, you have more options to shoot yourself in the foot, but you avoid the dangerous parts.

But still…

If you’re not talking about a full rewrite, yes, it could be possible to develop some part of the application in C#. But always keep it mind the cost of the mapping layer between C++ and C#. I would recommend exporting your C# parts as COM modules and calling that from C++. Be sure it bring a real advantage. If you must constantly convert vector<> to IList<> and must constantly convert your C++ type to C# one, any speed advantage of C# will be lost. You gain most of converting to C# and .NET when everything can stay inside the CLR. Getting everything inside the CLR mean a complete rewrite of a complex application and that is dangerous proposition.

All in all, I wouldn’t recommend it.

It sounds like your’e about to make a lot of really bad decisions.

Highlight the development time is comparatively lesser in C# than C++.

That sounds incredibly suspect. It’s certainly not true if your team knows C++ but doesn’t know C#, for instance.

I feel there are many features in C# like Collections, Generics, and other libraries which can be used to build the current application in a better and efficient way.

C++ definitely has those things and in fact generics are more facile in C++ than any other language. It sounds like you just heard somewhere that C# is better, so want to spend weeks rewriting everything into C#, then not actually be any better at doing things in C# than you are in C++. Start with STL and boost…

Use a Design pattern, which will help us to maintain the application in a better way.

You seem to have no idea what a design pattern is.

Long story short: You cannot make a sound engineering case based on hearsay. You must make it on technical knowledge.

We currently have a complex VC++ software application, which uses a
library like ObjectARX to build the dll. I feel there are many
features in C# like Collections, Generics, and other libraries which
can be used to build the current application in a better and efficient
way.

_{(Remark. ObjectARX is the extension API for AutoCAD. Thus, OP is asking about a domain-specific application known to require deep domain-specialized knowledge.)}

Take a deep breath and ask yourself whether the complexity of the software comes from the domain (computer-aided design and computational geometry), or from the choice of language. If the complexity comes from the domain, changing language may not significantly make your job easier.

Case in point, using a dumb example: a Polygon is not the same as IList<Point2>. How would an IList know how to check for repeated points? Self-intersecting segments? Embedding a coplanar 2D polygon into a plane in the 3D space?

Occasionally, the lack of some syntactic sugar in some languages will indeed complicate domain-specific software development. A prime example is lambda function. With C++11, these essential syntactic sugar can be used to simplify and modernize the code. If this is the case, modernizing the C++ code may be a better choice than migrating to C#.

_{Another remark to other readers: Each release of ObjectARX for Visual Studio is tied to a specific version of Visual Studio, and is neither backward nor forward compatible. As of ObjectARX 2013, use of VS2010 SP1 is required. (Thus, OP cannot easily recommend using VS2012 unless the vendor release a new version of ObjectARX and the customer (OP’s employer) upgrades to it.) http://usa.autodesk.com/adsk/servlet/item?id=12257036&siteID=123112}

_{Fortunately, VS2010 SP1 also supports a useful subset (but not all) of the C++11 syntax. In particular the iterator for-loop would simplify newly-written code somewhat. The benefit, however, might not justify modifying old code, though.}

I have been thinking about it, but I am not sure on how to present it
to my Supervisor and colleagues.

The best way is to just informally ask your supervisor (ideally the software architect) for consideration. It is his/her job to keep an eye on every possibility, including platform choices, migrations and the long-term viability of the project.

_{If you actually find yourself more knowledgeable than your supervisor / software architect (which is highly unlikely), find another job.}

I would appreciate any help, to help me think in the right direction
and highlight the points to bring it to the team.

My suggestion:

Roman wasn’t built in a day.

At any point in time in your hypothetical re-implementation, the application as a whole needs to be demonstratable (at least runnable and testable). Thus, it will contain parts written in VC++ and parts written in C#. If you can demonstrate that the application still works in a satisfactory way (no major bugs, issues or inefficiency), you have found a “jungle path” from the project’s C++ present to the C# future.

A sample worksheet:

• Suppose 5% of the project will be migrated to C#.
  • Which modules or components in the project would you choose to be migrated to C#?
  • How do they interoperate with the rest of the application?
  • Do you foresee any difficulties?
• Repeat the question for 20%, 40%, 60%, 80%, and 99%.

Another important question to ask:

• Are there other teams in the company (or paying customers) that depend on the application being C++? Will these teams agree to migrate to C# as well, or will your team be able to provide interoperability for that team?

If you have done this, present your findings to the software architect, who will then be responsible for identifying roadblocks ahead in the remaining sections of this jungle path.

If you don’t know how C++ and C# can interoperate … _{I suggest you close this question ASAP before a torrent of downvotes burn away your hard-earned reputation points …}

I have done some applications in C++ and some in C#.

Granted, C++ can be more complex than C# and C# has LINQ, garbage collection etc.
However, features like Collections and Generics are also available in C++, please have a look at STL, Boost and C++11.

“Modernizing” your C++ code seems the better choice for me, e.g.

• using containers like std::list and std::vector instead of C-arrays
• avoiding normal pointers whenever possible and switching to std::shared_ptr etc.
• using std::string instead of char*
• Boost provides a library for nearly everything
• etc.

You should avoid using both C++ and C# in your application (CLR or P/Invoke), unless it’s absolutely necessary, e.g. DLL for a device is written in C++ and application has been done in C#. The mapping layer will cause you headaches.

99 times out of 100, it’s better to refactor code than to rewrite it from scratch.

As for reimplementing into another language: make damn SURE that the benefits outweigh the costs and risks, both short term and long term. FYI: as the application’s size and/or complexity goes up, the chances that this decision makes sense goes down.