Preventing usage of .NET features in VS .NET 2003

  • Thread starter Thread starter Senapathy
  • Start date Start date
S

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
 
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
 
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.
 
Senapathy said:
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...
Click to expand...

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

-cd
 
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
 
Senapathy said:
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?
Click to expand...
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.
Click to expand...
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
 
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.
 
Senapathy said:
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.
Click to expand...

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
 
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
 
Back
Top