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
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"
news:uURIhs7oIHA.3960@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
>
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"
> news:uURIhs7oIHA.3960@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
>>
>
>
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.
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.
>
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"
> 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.
>>
On Mon, 21 Apr 2008 09:45:18 -0700, Blasting Cap
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
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"
news:eJw%231u7oIHA.4308@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"
> news:uURIhs7oIHA.3960@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
>>
>
>
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"
news:OkfxX88oIHA.3976@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.
>>