If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Hybrid View

[RESOLVED] Comments about initial experience with C++/CLI

I have done some initial programming using the C++/CLI and have some comments about my experience.

I had an existing program which parsed VC 6.0 dsp files to extract a variety of settings and lists of files. As my company goes forward with converting to using the VC 2005, projects are being converted and now use the new vcproj files. I have updated this program to also support parsing the vcproj file. Until all projects are converted, I need to maintain support for dsp files and vcproj files. Since the existing project already does significant work in unmanaged code and there is a managed VCProjectEngineObject available which can load/parse the new files, I made a mixed mode project.

The first thing that I noticed is that although the VCProjectEngineObject is setup to load VC projects, all of the examples for using it are in VB. This seems to be a strange choice (especially for an object that accesses a vcproj file).

Is this a common practice to give code examples in just one language?
Are there any plans to enhance the documentation to provide examples in other languages?

I realize that the syntax changed from managed C++ to C++/CLI, so it may just take a while for the documentation to catch up. I can follow the examples given in VB, but sometimes it is nice to cut and paste an example in the language that I am working in.

The second thing is that I needed to use casts more than I would have expected. For example, the first thing I wanted to do after creating the VCProjectEngineObject was to load a project. The LoadProject member of the VCProjectEngine returns a System::Object^. I used code like this:

I would have thought that the LoadProject() member should return a VCProject^ instead of an Object^, as this is type that it is actually loading.

I haven’t looked at other objects yet to see if this is a common practice or is limited to just the VCProjectEngine.

Is it normal for interface routines to return a System::Object^ instead of a derived type (even though the actual object is really some derived object)?

I try to minimize the number of casts used in the code I write, but this is making me add casts where I wouldn’t expect. I am wondering whether I will see this in other .net objects.

Similarly, after the project is loaded, many of the members of the VCProject use Object^ as the type instead of the only type they can be (such as the Files member, which is used as an IVCCollection^, but is an Object^). This again makes me need to use a cast, but if the member type was specified differently, I wouldn’t need to cast. Some of the members are of type String^, which don’t need casts.

Is it normal for members of objects to use System::Object^ instead of a derived type?
Or is this just the VCProjectEngine and related objects that are using System::Object^ for members when they should really use a specific type?

I did use and like the “for each” support to loop through all the files in the collection – this removed the need for one cast as the variable type in the loop worked without the cast.

I didn’t find the C++/CLI interface to be difficult to use, but just felt that it sometimes makes me type more code than should be needed. This could just be due to the particular object I am using (VCProjectEngine).

I may not done everything using the best practices for C++/CLI – I am still learning and without examples in the C++/CLI language it can be difficult. It took some experimenting to find out how to use the engine to get at the parts that I was looking for.

Re: Comments about initial experience with C++/CLI

Hi,

Your question is more about extending Visual Studio using the VSIP interface and the VCProjectEngine objet model than it is about C++/CLI. Your comments are true whether you use C++/CLI, C# or VB to program against VCProjectEngine.

Re: Comments about initial experience with C++/CLI

Thank you Tarek for responding to me.

I think that I didn't really express myself clearly. I am not really concerned about the specific interface to the VCProjectEngine. While I did run into some issues with using it that I brought up in my initial posting, I was more interested in the general usage of C++/CLI when using .NET components.

My main issues with using the VCProjectEngine really boil down to 2 basic questions about C++/CLI in general:

Is the MSDN documentation going to be updated with C++/CLI examples? I am just not talking about VCProjectEngine - this just happened to be the object that I was using in the first project that I tried with C++/CLI. For example, the DataSet documentation has examples for copying DataSet contents in C# and VB, but no example for C++/CLI. I am sure that there are other instances where the examples provided are in either C# or VB or both. Occasionally I have seen examples for C++ (such as ConsoleKeyInfo.Modifiers, which has examples for C#, VB, C++, J#).

Is it going to be common usage with other .NET objects that I will frequently need cast operators when using them because of the type being a System::Object^ instead of the more specific type? (Or is this just a problem with VCProjectEngine)?

The program I mentioned in the first post has already been updated and uses safe_cast where needed. I don't anticipate needing to make further updates to it. It is just a tool used internally and isn't shipped to our customers.

Re: Comments about initial experience with C++/CLI

Hi jwbarton:

As a former VC++ project system developer that was on the 2005 team (please note: I am no longer affiliated with Microsoft), I can comment on your second question:

The Microsoft.VisualStudio.VCProjectEngine assembly is a Primary Interop Assembly provided by Microsoft so that .NET languages can interop with the Visual C++ Project Engine (which is COM). The VCProjectEngine.LoadProject method actually returns an IDispatch*, rather than VCProject*, which is for historical reasons. The interop assembly converts this to Object^ because it doesn't know the actual interface being given back. This is why a lot of the VCProjectEngine related interfaces return Object^, when they really should give back "better" types.

This is not a limitation of C++/CLI in any way, but more of an interface definition issue within the Visual C++ project engine. If you consumed the VCProjectEngine interop assembly from other .NET languages, such as C#, casting of this nature would also occur.

* The Perfect Platform for Game Developers: Android
Developing rich, high performance Android games from the ground up is a daunting task. Intel has provided Android developers with a number of tools that can be leveraged by Android game developers.

* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.