framework 2.0 coexistance

[- Dan -]

i will be installing on my new computer sql server 2005 beta 2 which
installs sql workbench. this also installs the .net framwork 2.0. i will
also already have installed on my machine vs.net 2003 enterprise architect.
by default today i use the DNF 1.1. when 2.0 is installed, will i have to
do anything to tell vs.net 2003 to not use any part of the 2.0 framework or
will it "just know" ??

 

[Brian Henry]

I thought 2005 was still in alpha? wasnt the last build issued still a
prebeta build?

 

[- Dan -]

you are correct but my question was really towards an existing install of
vs.net 2003 and ignoring the dot net framework 2.0. simply put, since 2003
came out before the dnf 2.0, will it not even take the dnf 2.0 into account
and still function using 1.1? if i start a new project in vs.net, how do i
check what version of the dnf i'm coding against? maybe that is a better
way to put it.

 

[Brian Henry]

I don't think having 2.0 installed will have any effect on 2003, it uses 1.1
only and when you install new frameworks the older ones stay there also. so
there should be no bad effects

 

[Brian Henry]

You can find which on you are useing in the project properties (right click
on the project get properties) and the build item in the left tree there is
a supported runtimes. that will tell you what runtimes you app will be
supported on you can change this setting (backwards only, you can not use a
newer framework then what VS.NET was designed for)

 

[- Dan -]

excellent! your assistance was greatly appreciated.

 

[Herfried K. Wagner [MVP]]

i will be installing on my new computer sql server 2005 beta 2 which
installs sql workbench. this also installs the .net framwork 2.0. i will
also already have installed on my machine vs.net 2003 enterprise architect.
by default today i use the DNF 1.1. when 2.0 is installed, will i have to
do anything to tell vs.net 2003 to not use any part of the 2.0 framework or
will it "just know" ??

I would not install alpha software on a production environment. I
assume that VS.NET 2003 will keep using .NET 1.1.

 

[- Dan -]

but herfried, if no body installed alpha/beta code in production
environemnts then we would not benefit as a whole. software has to be
tested with real world data or else we'd all be saying hello world and
working at northwind. ( or some java pet store :-O )

 

[Herfried K. Wagner [MVP]]

but herfried, if no body installed alpha/beta code in production
environemnts then we would not benefit as a whole. software has to be
tested with real world data or else we'd all be saying hello world and
working at northwind. ( or some java pet store :-O )

What I wanted to say: If you depend on the machine, do not install the alpha
version onto this machine.

 

[Sven Groot]

i will be installing on my new computer sql server 2005 beta 2 which
installs sql workbench. this also installs the .net framwork 2.0. i
will also already have installed on my machine vs.net 2003 enterprise
architect. by default today i use the DNF 1.1. when 2.0 is
installed, will i have to do anything to tell vs.net 2003 to not use
any part of the 2.0 framework or will it "just know" ??

Since VS2005 can't actually use .Net 2.0, it'll keep using 1.1.

 

[Sven Groot]

Since VS2005 can't actually use .Net 2.0, it'll keep using 1.1.

I ment VS.NET 2003 of course.

 

[Jay B. Harlow [MVP - Outlook]]

Dan,
I normally install alpha/beta code in a VPC (Virtual PC, VM Ware) this way
my "production" development system is protected and I will not be down for
two days to rebuild the system when the alpha/beta "trashes" things.

For "production" data I would setup a second server (VPC if needed) that
parallel the "production" server. Until said time when the test server
proved a problem, allowing us to cut back to the "production" server.

Another reason to install to a second machine (physical or VPC) is that most
alpha/beta code does not upgrade to the released code all the time, nor does
it uninstall cleanly either...

Hope this helps
Jay

but herfried, if no body installed alpha/beta code in production
environemnts then we would not benefit as a whole. software has to be
tested with real world data or else we'd all be saying hello world and
working at northwind. ( or some java pet store :-O )







have

to

framework

 

[Eric Sabine]

ack! ( as herfried would say!!)

i am a "super" vpc user these days since it hit msdn downloads! i use if
for exactly stuff like that like yukon, fedora core 1, etc). i now have hit
my personal stage where i want to take yukon beyond the vpc stage and work
with it full time.

these days i find myself actually installing stable software like
adminpak.msi, exchange system manager, and other apps into my VPC machine
because i rebuild my computer often (not cause i break it but i like too)
and i like to devote the full GHZ and memory to my dev apps. sounds
backwards i know!

Dan,
I normally install alpha/beta code in a VPC (Virtual PC, VM Ware) this way
my "production" development system is protected and I will not be down for
two days to rebuild the system when the alpha/beta "trashes" things.

For "production" data I would setup a second server (VPC if needed) that
parallel the "production" server. Until said time when the test server
proved a problem, allowing us to cut back to the "production" server.

Another reason to install to a second machine (physical or VPC) is that most
alpha/beta code does not upgrade to the released code all the time, nor does
it uninstall cleanly either...

Hope this helps
Jay