A doubt in VC++.net

Hot Topic

debug information and classes with virtual functions
Tracking Reference (%), value, ref??
LNK2019 errors using DX9 libs
Link for .NET Framework 2
runtime error
Update on buffer over-run bug in ATL::CPath functions - FDBK26503.
C++ Build Failure
Custom Preprocessor as Custom Build Step
Strange overlaod ambiguity
VS .Net 2005, how to disable intellisense...

Visual C++

Framework 2.0 pin_ptr problem after migration from 1.1
Importing class from dll
Pause in action with MSVC++.NET
number counter issue
Problem compiling a program
new to VC++ 2005, have a few problems
how can i detect why the error caused by new()?
CString assignment operator causes memory exception
Getting LNK4224 with B2 - what's the story?
Fail to include "atlstr.h"

A doubt in VC++.net

hi,
I have a doubt in VC++.NET's IJW feature. If we compile an existing VC++ 6.0 application inVC++.NET, almost (with slight code changes may be) it works. Even if the application contains objects from MFC or others, this technique works.

I need to know
1. whether these will run under .NET CLR or not.
2. what is .NET's role & contribution to these application. will they still use older dlls
3. if i ship these application to a system where only the .net framework is installed, will they work

Please make me clear

thanks,



Answer this question

A doubt in VC++.net

  • Deuce Loosely

    hi,

    i need one more clarification. if i compile a vc++6.0 app in VS.NET 2003, and copy the app files to a machine where the .net framework is not installed. but the app runs successfully without showing any errors in that machine. then watz the point in compiling in VS.NET doesnt it have any impact on exe/dll files

    Pls clarify.

    Thanks



  • Bond007

    Nishant Sivakumar wrote:
    Yes, and to add to the list of disadvantages, /clr is not compatible with static CRT linking.

    Ohh yes... Thanks for your comment.
    I forgot this, because I still program in native mode mainly...



  • Brent McCulloch

    If you take a Visual C++ 6.0 project and do nothing else other than re-compile it with Visual C++ .NET 2002 then you will end up with an executable that does not require the .NET framework. Just because ".NET" appears in the name of the product does not mean that every application that you build with Visual C++ .NET 2002 requires the .NET framework. This is a point of confusion that our marketing dept has finally caught on to and hence the latest version of Visual C++ is named "Visual C++ 2005" with no .NET in the name.

    There were a lot of improvements to the native tools in Visual C++ .NET 2002 (though the improvement in going from Visual C++ 6.0 to Visual C++ .NET 2002 is not as great as it is when going from Visual C++ .NET 2002 to Visual C++ .NET 2003 or from Visual C++ .NET 2003 to Visual C++ 2005) - when upgrading from Visual C++ 6.0 you get a better C++ compiler and a better optimizer.



  • matsuoka

    Jonathan Caves MSFT wrote:
    3) No it won't - even if your application targets the CLR if it also uses MFC then it will still need the MFC DLLs to be installed on the target machine.

    Just to add this:

    You still can link the CRT and the MFC statically to your project. In this case you don't need to provide any extra files.
    But the disadvantages are well known: No support for MFC Extension DLL's, no sharing of MFC classes between DLL's and so on...



  • Travis McPhail

    1) If all you have done is recompile that application then it won't run under the CLR: it will continue to run as it did when you compiled it with Visual C++ 6.0 - to make the application run under the CLR you need to target the CLR - for this you need to compile your application with the /clr option

    2) Unless you specifically target the CLR then the CLR won't have any contirbution to your application

    3) No it won't - even if your application targets the CLR if it also uses MFC then it will still need the MFC DLLs to be installed on the target machine.



  • elargento

    wow, Thanks a lot guys. so many responses within the day. thanks a lot.

  • JPJofre

    Martin Richter wrote:

    Jonathan Caves MSFT wrote:
    3) No it won't - even if your application targets the CLR if it also uses MFC then it will still need the MFC DLLs to be installed on the target machine.

    Just to add this:

    You still can link the CRT and the MFC statically to your project. In this case you don't need to provide any extra files.
    But the disadvantages are well known: No support for MFC Extension DLL's, no sharing of MFC classes between DLL's and so on...

    Yes, and to add to the list of disadvantages, /clr is not compatible with static CRT linking.



  • A doubt in VC++.net
Answer this question