Why is Visual C++.NET treated different than Visual Basic.NET and Visual C# in Measurement Studio ?

[fransv1963]

At first sight it looks like Visual C++.NET does not get the same attention/support within Measurement Studio .NET as Visual Basic .NET and C#.

It even looks like Visual C++.NET users are recommended to use a totally different set of classes (which are even MFC-based for the GUI components).

Is this a correct observation ? If so, what's the idea/strategy behind this ?

Any comments are highly appreciated.

Thanks.
Frans.

[TonyH]

Many Measurement Studio users using Visual C++ are not .NET programmers, or do not want to require the .NET Framework to be present in order to run their applications. The native libraries, MFC classes, and ActiveX controls Measurement Studio provides for Visual C++ also require typical C++ programmers to learn fewer new concepts and let them get to writing their applications more quickly than if they had to learn about .NET and the Managed Extensions to C++.

For a .NET programmer who wants to write an application in Visual C++ .NET, the Measurement Studio .NET class libraries do work with Visual C++ .NET. However, the syntax of the Managed Extensions to C++ can be cryptic and definitely requires a greater understanding of managed code than writing an equivalen
t application in VB .NET or C#. For these reasons, we currently don't recommend using the .NET class libraries in Visual C++ .NET for most people unless you have a specific need for it.

Tony H.
Measurement Studio

[drohacek]

From one particular perspective, your observation is correct. From another perspective, it is fair to say that Measurement Studio provides equal support for C#, VB.NET, and unmanaged C++, but Measurement Studio provides lesser support for managed C++.

It will probably be helpful to state explicitly what I mean by "support". Measurement Studio defines support as: class libraries that work natively in the language, example programs in the language, project wizards that generate project shells for the language, MSDN-integrated help in the language, help code snippets in the language, National Instruments Assistant code generation in the language, various other Visual Studio .NET integration features for the language, and customer support for using the Measurement Studio class libraries in the language. Of course, decisions must always be made about how far to go along each of these dimensions for various class libraries, but this is a good general definition of Measurement Studio support.

Measurement Studio supports not only individual languages, but also application development frameworks. Providing this support is extremely straightforward for C# and VB.NET. The .NET Framework is the obvious application development framework to use with C# and VB.NET. Providing this support is not so straightforward with C++, especially with Visual C++ .NET because there are many application development frameworks and 2 language "flavors" that we could support. The two language "flavors" are unmanaged C++ and managed C++.

If we consider only unmanaged C++, there are still many different application development frameworks that Measurement Studio could support. These include ATL, WTL, MFC, "straight Win32", and other 3rd party frameworks. For Measurement Studio, we chose to support MFC. This decision was made for version 1.0 of Measurement Studio, which released in early 2000. MFC was chosen because it was (and still is) the most widely used of the Microsoft-supplied C++ application development frameworks. There was no .NET at that time, so supporting managed C++ was not even an option. There is no migration path from MFC to the .NET framework, so Measurement Studio plans to support MFC as long as Microsoft supports it and our customers are using it. This "disconinuity" is also why Measurement Studio includes two different sets of libraries for C++ and C#/VB.NET.

We made the decision to support managed C++ only through the .NET class libraries. The Measurement Studio .NET class libraries are Common Language Specification (CLS) compliant. This means that the .NET class libraries are usable from any CLS-compliant language, including managed C++. However, we decided to not provide customer support, code generation, example code, and all of the other dimensions of support that we provide for C#, VB.NET, and unmanaged C++.

There are many reasons why we decided to limit our support for managed C++; I'll go through only some of them here. One reason is that practically, we can support only so many languages. We would spend all of our time writing example programs if we chose to provide full support for Ruby .NET, COBOL .NET, FORTRAN .NET, or any of the other .NET languages. Our customer support engineers cannot be expected to learn all of the .NET languages that Visual Studio .NET supports. Another reason is that managed C++ is a very advanced language. We expect customers who use it to learn it completely and therefore be able to themselves map C# support to managed C++ support. A managed C++ user can always use the full Measurement Studio C# or VB.NET support to generate class libraries that are easily callable from his or her managed C++ code. Yet another reason is that Microsoft has positioned managed C++ as primarily a transtionary language - one that you use to migrate old code bases to the .NET platform rather than one that you use to develop new applications.

National Instruments will continue to watch how Microsoft evolves managed C++ and how our customers use it. If enough customers want to use managed C++ and find our current level of support to be inadequate, we will consider filling out support for managed C++.

So to summarize (you thought it would never happen):

Measurement Studio provides full support for C# & .NET Framework, VB.NET & .NET Framework, and unmanaged C++ & MFC.

Measurement Studio provides only class libraries for managed C++ & .NET Framework.

David Rohacek
National Instruments

[fransv1963]

Thanks for the clarification.
These were the clear statements I was looking for and was unable to find until now.

Thanks again.
Frans.

[Colin hughes]

Direct use of NIDAQ.dll and I assume DAQMX.DLL can be used in managed C++ with "it just works".