Framework 2.0 to Framework 3.5

[Blasting Cap]

I'm using VS 2005, and have a dll in some code (system.core.dll) that
was included in something someone sent me to run on my system.

I have production on a server using Framework 2.0 that I want to keep
intact.

Will upgrading my development box to Framework 3.5 preclude any
development or functionality in the 2.0 environment I am responsible for?

BC

 

[David Wier]

You should be just fine with your 2.0 work - - I have 2.0 work still on my
computer, as well as VS2005 and VS2008
When I want to work with 3.5 stuff, I use VS2008
When I want to work with 2.0 stuff, I use VS2005 - -

David Wier
http://aspnet101.com
http://iWritePro.com - One click PDF, convert .doc/.rtf/.txt to HTML with no
bloated markup

 

[Blasting Cap]

Will 3.5 not work with VS 2005?

You should be just fine with your 2.0 work - - I have 2.0 work still on my
computer, as well as VS2005 and VS2008
When I want to work with 3.5 stuff, I use VS2008
When I want to work with 2.0 stuff, I use VS2005 - -

David Wier
http://aspnet101.com
http://iWritePro.com - One click PDF, convert .doc/.rtf/.txt to HTML with no
bloated markup

 

[Andy]

From what I understand...

To run mixed .NET assemblies on a computer, first install each .NET
framework the assemblies call.

A single Windows process can only load and run one .NET framework.
This means that a process can only run assemblies targeted for
the .NET framework that was first loaded by that process. This will
be the .NET framework used by the first assembly that the process
loads.

The major impact this restriction has appears in IIS where each
application pool runs as a single process with one framework. This is
why you can't mix .NET frameworks in a web application or webservice
running on IIS.

In a similar way, Visual Studio .NET also runs as a single process.
As Visual Studio .NET is itself written in .NET, the framework that
gets loaded is the framework the VS IDE was written in. This means
you won't be able to link assemblies targeted for a different version
of .NET into projects you developed with that version of Visual
Studio.

If the mixed assemblies run under different process so that each .NET
framework can run, and you have a mechanisim in place to communicate
between the processes (ie messaging), then you can have a mix of .NET
Framework targeted assemblies for the same application.

 

[Blasting Cap]

Ok -

I think I understand.

I guess I didn't ask the question I really wanted the answer to very
well. But from what I understand about your response, it shouldn't
affect it.

What I have is a system with VS 2005, and framework 2.0 on it, that I
develop from. Also in the mix is a server (Server 2003) running
framework 2.0 as well.

If I were to install Framework 3.5 on my machine (XP, VS 2005) and work
on the app that resides on the server (Server2003), as long as I don't
change the .net property in IIS, that property should stay the same.
Meaning, when I code & test on my machine, where I have IIS and that
website installed, make changes, etc - when I deploy it (or copy code
to) the server with framework 2.0 installed, as long as I haven't made
reference to anything beyond 2.0's framework, or changed the property on
MY IIS (or the server's) to reference dotnet framework beyond 2.0 -
things on the website in my test (local) environment and the production
environment - should function as before.

Right?

;-)

BC

 

[Juan T. Llibre]

re:
!> as long as I haven't made reference to anything beyond 2.0's framework,
!> or changed the property on MY IIS (or the server's) to reference dotnet
!> framework beyond 2.0 - things on the website in my test (local) environment
!> and the production environment - should function as before.
!> Right?

Right.

 

[Tirrell Cotton]

Why not just use VS 2008 for both? One of it's features is that you can
target the runtime that you want to run against? I use VS 2008 for 2.0 and
up.