Preventing usage of .NET features in VS .NET 2003

[Senapathy]

Hi,

We are in the process of migrating from VS 6.0 to VS .NET 2003.
Our code base in VS 6.0 is mainly C++.
As a first step we do _not_ want to use the .NET framework features, but
just continue to use unmanaged C++ code. We are only looking to use the more
standard-compliant C++ compiler, usage of Boost libraries etc.

Is there any way to disable / prevent the usage (intentional / deliberate)
of any .NET features? By features, I mean some new headers / controls / APIs
available only with VC7.

Say, some compiler switches, preprocessor definitions etc? Googling did not
help me much...

Regards,
Sena

 

[Antti Keskinen]

Hello !

VS .NET 2003 does not integrate with .NET Framework unless you create an
application that exclusively uses the framework. For example, if you create
a standard Win32 application with it, it will not include any .NET stuff by
default. The only thing it might do is include the MFC component (if you
specify it to do that), but no .NET as default.

To create a .NET application in VS .NET 2003, you'd need to either create a
C# project (which .NET-only) or reference the .NET libraries from a C++
application.

-Antti Keskinen

 

[Nemanja Trifunovic]

In order to make a .NET application from VC++, you must use compiler
switch /clr That will instruct the compiler to produce IL rather than
machine code.

 

[Carl Daniel [VC++ MVP]]

Hi,

We are in the process of migrating from VS 6.0 to VS .NET 2003.
Our code base in VS 6.0 is mainly C++.
As a first step we do _not_ want to use the .NET framework features,
but just continue to use unmanaged C++ code. We are only looking to
use the more standard-compliant C++ compiler, usage of Boost
libraries etc.

Is there any way to disable / prevent the usage (intentional /
deliberate) of any .NET features? By features, I mean some new
headers / controls / APIs available only with VC7.

Say, some compiler switches, preprocessor definitions etc? Googling
did not help me much...

Don't compile with /clr and you can't use any .NET features. Simple.

-cd

 

[Senapathy]

Hello group,

Thanks Antti, Nemanja and Carl ! The answer seems to be simple !

Now I just need to figure out a way such that no developer uses the /clr
option - either by mistake or intentionally. ( I am thinking from the
central production point of view and we have many developers checking in
sources and project files ). I am sure that for this, there will be some
simple means by which I can flag a production time error if someone uses the
/clr option - I can't seem to recollect any method just off my head, but I
think I can find that out.

Thanks for the help!

Regards,
Sena

 

[adebaene]

Hi,

We are in the process of migrating from VS 6.0 to VS .NET 2003.
Our code base in VS 6.0 is mainly C++.
As a first step we do _not_ want to use the .NET framework features, but
just continue to use unmanaged C++ code. We are only looking to use the more
standard-compliant C++ compiler, usage of Boost libraries etc.

Is there any way to disable / prevent the usage (intentional / deliberate)
of any .NET features?

If you do not compile with /clr, the C++ compiler will produe native
code, not .NET IL and will refuse any managed C++ construct.

By features, I mean some new headers / controls / APIs
available only with VC7.

I think you confuse 2 things : There is on one side all the .NET stuff
you can avoid by not using the /clr compiler switch.

On the other hand, VC 2003 also adds new unmanaged functionnalities
(for example, MFC and ATL have evolved, the STL if far more compliant,
etc...) You have no way to disable those new features, but you have no
reason to want to avoid them in the first place.

Arnaud
MVP - VC

 

[Serge Baltic]

S> We are in the process of migrating from VS 6.0 to VS .NET 2003.
S> Our code base in VS 6.0 is mainly C++.
S> As a first step we do _not_ want to use the .NET framework features,
S> but
S> just continue to use unmanaged C++ code. We are only looking to use
S> the more
S> standard-compliant C++ compiler, usage of Boost libraries etc.
S> Is there any way to disable / prevent the usage (intentional /
S> deliberate) of any .NET features? By features, I mean some new
S> headers / controls / APIs available only with VC7.

As you wish to use the new compiler, it will inevitably use the new headers
and APIs "available only with VC7". But VC7 on its own has nothing to do
to .NET (unless you explicitly allow using .NET features in the project properties).
So just do not turn on any options for "Managed", CLI/CLR, C#, etc, and that
will be it.

 

[Arnaud Debaene]

Hello group,

Now I just need to figure out a way such that no developer uses the
/clr option - either by mistake or intentionally. ( I am thinking
from the central production point of view and we have many developers
checking in sources and project files ). I am sure that for this,
there will be some simple means by which I can flag a production time
error if someone uses the /clr option - I can't seem to recollect any
method just off my head, but I think I can find that out.

I don't know of any source control system that would do so complex
verifications on check-in. Developpers are supposed to be responsible
people, so threatening to fire anyone who use /clr should be enough
More seriously, if you have dedicated test machines, do *not* install the
..NET framework on them. This way, the .NET programs won't be able to run on
them.

Arnaud
MVP - VC

 

[Steve McLellan]

There's a preprocessor definition _MANAGED that is set under a CLR
compilation (if memory serves), so you could check for that. My guess is
you'd get a lot of other compile errors in a complex project.

Steve