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" <go****@christian.netwrote in message
news:uU**************@TK2MSFTNGP02.phx.gbl...

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

[Blasting Cap]

Will 3.5 not work with VS 2005?

David Wier wrote:

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" <go****@christian.netwrote in message
news:uU**************@TK2MSFTNGP02.phx.gbl...

>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

[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

Andy wrote:

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.

[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.

Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
======================================
"Blasting Cap" <go****@christian.netwrote in message news:Ok**************@TK2MSFTNGP03.phx.gbl...

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

Andy wrote:

>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.

[Peter Duniho]

On Mon, 21 Apr 2008 09:45:18 -0700, Blasting Cap <go****@christian.net>
wrote:

[...]
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.
[...]

I believe that's the case. .NET 3.5 still uses the same run-time as .NET
2.0. The only thing that's changed is additional components in the
framework.

That said, as far as I can recall, VS2005 doesn't provide any means for
preventing you from using .NET 3.5 framework components if you have the
..NET 3.5 SDK installed. You can probably get away with installing the 3.5
_framework_ on your development machine without causing problems, but you
should probably not install the _SDK_, to ensure that 3.5 stuff doesn't
accidently get used in your code.

With VS2008, this is a lot easier, as you can set your project settings to
target specific versions and the IDE will take care of making sure you
only get the right SDK.

Pete

[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.

"David Wier" <[e-mail] in message
news:eJ****************@TK2MSFTNGP06.phx.gbl...

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" <go****@christian.netwrote in message
news:uU**************@TK2MSFTNGP02.phx.gbl...

>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

[Alvin Bruney [ASP.NET MVP]]

If you need to ask this question, I think you should consider setting up a
VPC image that you can install VS 2008. That will prevent you from shooting
yourself in the foot.

--

Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The O.W.C. Black Book, 2nd Edition
Exclusively on www.lulu.com/owc $19.99
-------------------------------------------------------


"Blasting Cap" <go****@christian.netwrote in message
news:Ok**************@TK2MSFTNGP03.phx.gbl...

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

Andy wrote:

>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.