VS 2003 and framework2.0

Hi,

How can I point VS2003 to framework 2.0

I have both 1.1 and 2.0 installed on my development machine and for some reason I cant install VS2005. How can I point VS 2003 to 2.0 framework.

In this scenarion, will I be able use new features of 2.0 such as datagridview, enhancements in ADO.net and other new features

Thanks,

Windows Forms1

I am very sorry but you are not going to be able to get Visual Studio 2003 to target the 2.0 Framework without a great deal of work as VS is very tightly tied to it’s associated Framework version.

If you really need to use the 2.0 Framework for development you may want to look into making VS 2005 on your system... what exactly is the problem there

The problem is not technical but political...and I cant really do much about it :(

Do you know the difficult way of working with 2.0 in VS2003

Thanks,

Short of ****ping a few Microsoft engineers and nabbing the source code to both 2003 and 2005 you are out of luck on getting it to work in 2003.

You may want to look into the Visual Studio Express Editions which are language specific free IDE’s that are simply slightly stripped down versions of the higher ones and target the exact same 2.0 Framework... otherwise you are stuck using 2003 for 1.0/1.1 only development.

There are some C++ applications that use framework 1.1 VS2003 as compiler. The fear is that if 2.0 and VS2005 is installed on the machine then there is a risk that existing application might get dependent on some parts of 2.0 which will make things messy. Is there any easy way of verifying/refuting this claim

Before we can go any further... do these C++ applications actually use the 1.1 framework (ie using the /CLR flag (managed extensions) or are they just run of the mill windows/console/MFC applications that just happen to be built in Visual Studio 2003

They use VS2003 to build win32 project and to compile it they do ctrl+shift+B...

Does this not mean that they are using .net framework as a compiler they say they dont...

They are correct, for a regular run of the mill win32 project they are not using the .NET Framework in anyway (unless they are using Managed Extensions with the /CLR flag).

If you were to build this same application under Visual Studio 2005 with it’s native C++ compiler you *might* run into a couple of issues because of the upgrade (sadly it happens from time to time when changing compilers), however the only other likely issue you would have would be that you would need to make sure that any user of the application has the upgraded Visual C++ 8.0 runtime on their system so as to be able to use the application... which is quite normal as very few compilers build binaries that do not require any kind of external libraries or runtimes.

They dont need to compile C++ app in 2.0. They can continue to work on 1.1 and VS2003 with their existing application...

What if they simply install 2.0 and VS2005 and run it side-by-side to compile other 2.0 applications , would it effect their existing C++ apps written in 1.0 and VS 7.0 Are there any risks involved here

As I mentioned in my previous post that the concern is that older applications written in 1.0 and VS2003 might get dependent on newer .net version which will mess things up....

No, the installation of the 2.0 Framework or VS2005 will leave the dependencies of 2003 unaffected for both apps already built and to be built later under 2003 as they will still require the same Visual C/C++ runtime that it always has as defined by the compiler.

Thanks a lot. So to conclude we can say the c++ applications using native compiler of VS2003 will remain unaffected if we install framework2.0 and VS2005. The 2 versions of VS and framework can run side-by-side and the apps built on either of them remains uneffected by the presence of any other version of VS or .net

One thing I would like to ask though for my understanding. .net compiler is embedded in framework and not in VS. VS simply links with the compiler and CLR embedded in framework, rite

What exactly does a "native" C++ compiler mean when we build a C++ app in VS, is it by default considered to be written in managed code and hence compiled by relevant compiler components of .net framework or we need /CLR extension to make it managed and be compiled in framework if we dont use /CLR and keep c++ code unmanaged then where does the native C++ compiler come from do we need to install C++ native compiler separately and link it to VS

Thanks,

You are more or less correct in that a .NET compiler is embedded in the framework as the framework itself is able to internally compile C# and VB.NET code for instance... but Visual Studio 2002-2005 targets more than just the .NET framework.

Remember that .NET applications are CPU independent and portable, provided a compatible .NET framework exists on a given CPU platform a properly written .NET app can be used without concern of if the processor below is an x86, IA64, Sparc, or a hamster in a wheel.

When it comes to native applications though, the code is built specifically for the targeted processor which makes it very difficult to take a binary compiled for Windows and x86 and have it run on a different processor architecture.

The question of which compiler you are using and if it uses the .NET framework is dependant on what kind of project you select and what project attributes you use within. If you built a .NET project from the beginning then it would require the .NET Framework. If on the other hand you built an ATL, MFC or Win32 project, then unless you are using the /CLR flag you are not dependant on it.

One way to think about this is that with all of the old school C/C++ code in the world, Microsoft didn’t want to force everyone to recode their applications for .NET, learn a new language or even be forced to use or learn the Framework... instead they provided two separate paths. On one you are in the managed world with the framework right at your side... on the other path you are in the unmanaged world and able to write and use exactly the same code you did/could before .NET ever existed and along the way there are multiple frontage roads connecting the two paths to make it easy for you to gradually work your way from one into the other as the need arises.

Does this better clear things up

Great, thanks.

It would be nice though if win32 apps using native C++ compiler were also independent of VS or framework versions even if they were recompiled in other versions as they use native C++ compiler and not CLR.