I got a problem in one of my solutions and ran into something that I suppose
is what I think but I find the versioning a bit confusing.

I was trying the Add Reference in Visual Studio and noticed that it lists
both "Version" and "Runtime". Apparently the .NET Framework version is in
the "Version" but all of them (v2.0, v3.0 & v3.5) have the same runtime
"v2.0.50727" which maps to the
c:\windows\Microsoft.NET\Framework\v2.0.50727\

So, System.NET shows as follows:
System.Net 3.5.0.0 v2.0.50727 c:\Program Files\Reference
Assemblies\.....
System.Messaging 2.0.0.0 v2.0.50727 c:\Windows\Microsoft.NET\Fra....

why does the v3.5 framework DLL shows the same runtime as the v2.0 and v3.0
frameworks? and why is it in a different directory root (C:\Program
Files\Reference Assemblies\*) instead of the standard
C:\Windows\Microsoft.NET\Framework\v3.5\... ?

Shouldn't Visual Studio 2.5 not restrict itself to showing only Framework
2.0 assemblies?

Emilio

Hello ....DotNet4Ever....,

> So, System.NET shows as follows:
> System.Net 3.5.0.0 v2.0.50727 c:\Program Files\Reference Assemblies\.....
> System.Messaging 2.0.0.0 v2.0.50727 c:\Windows\Microsoft.NET\Fra....


> Why does the v3.5 framework DLL shows the same runtime as the v2.0 and
> v3.0 frameworks?

Becuase there is no 3.0 or 3.5 runtime. There are only 1.0, 1.1 and 2.0
runtimes.

> and why is it in a different directory root
> (C:\Program Files\Reference Assemblies\*) instead of the standard
> C:\Windows\Microsoft.NET\Framework\v3.5\... ?

No Idea. Presumably for organisational purposes.

> Shouldn't Visual Studio 2.5 not restrict itself to showing only
> Framework 2.0 assemblies?

Since VS2005 (I assume thats what you meant) uses assemblies that run on
the 2.0 runtime or below, all current assemblies are fair game.

--
Rory

3.0 and 3.5 sit on top of 2.0, so there is no big deal here. All you will
find in the 3.x directories is extra stuff. Check it out yourself.

Not sure why one is referenced in one spot and not in the main spot. Most
likely someone was working with it from there and did not reset the link. As
long as it works, it is not a big deal.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

Subscribe to my blog
http://gregorybeamer.spaces.live.com/lists/feed.rss

or just read it:
http://gregorybeamer.spaces.live.com/

********************************************
| Think outside the box! |
********************************************
"....DotNet4Ever...." <hate.spam@nowhere.com> wrote in message
news:uOvvpyY7IHA.3480@TK2MSFTNGP03.phx.gbl...
>I got a problem in one of my solutions and ran into something that I
>suppose is what I think but I find the versioning a bit confusing.
>
> I was trying the Add Reference in Visual Studio and noticed that it lists
> both "Version" and "Runtime". Apparently the .NET Framework version is in
> the "Version" but all of them (v2.0, v3.0 & v3.5) have the same runtime
> "v2.0.50727" which maps to the
> c:\windows\Microsoft.NET\Framework\v2.0.50727\
>
> So, System.NET shows as follows:
> System.Net 3.5.0.0 v2.0.50727 c:\Program Files\Reference
> Assemblies\.....
> System.Messaging 2.0.0.0 v2.0.50727 c:\Windows\Microsoft.NET\Fra....
>
> why does the v3.5 framework DLL shows the same runtime as the v2.0 and
> v3.0 frameworks? and why is it in a different directory root (C:\Program
> Files\Reference Assemblies\*) instead of the standard
> C:\Windows\Microsoft.NET\Framework\v3.5\... ?
>
> Shouldn't Visual Studio 2.5 not restrict itself to showing only Framework
> 2.0 assemblies?
>
> Emilio

So if I understand correctly it should be no problem if I reference the v3.5
System.Net assembly (apparently not available in previous frameworks) from a
v2.0 solution?

Emilio
http://www.PanamaSights.com/
http://www.Virtual-Aviation.info/


"Cowboy (Gregory A. Beamer)" <NoSpamMgbworld@comcast.netNoSpamM> wrote in
message news:O6pXjRZ7IHA.4108@TK2MSFTNGP04.phx.gbl...
> 3.0 and 3.5 sit on top of 2.0, so there is no big deal here. All you will
> find in the 3.x directories is extra stuff. Check it out yourself.
>
> Not sure why one is referenced in one spot and not in the main spot. Most
> likely someone was working with it from there and did not reset the link.
> As long as it works, it is not a big deal.
>
> --
> Gregory A. Beamer
> MVP, MCP: +I, SE, SD, DBA
>
> Subscribe to my blog
> http://gregorybeamer.spaces.live.com/lists/feed.rss
>
> or just read it:
> http://gregorybeamer.spaces.live.com/
>
> ********************************************
> | Think outside the box! |
> ********************************************
> "....DotNet4Ever...." <hate.spam@nowhere.com> wrote in message
> news:uOvvpyY7IHA.3480@TK2MSFTNGP03.phx.gbl...
>>I got a problem in one of my solutions and ran into something that I
>>suppose is what I think but I find the versioning a bit confusing.
>>
>> I was trying the Add Reference in Visual Studio and noticed that it lists
>> both "Version" and "Runtime". Apparently the .NET Framework version is in
>> the "Version" but all of them (v2.0, v3.0 & v3.5) have the same runtime
>> "v2.0.50727" which maps to the
>> c:\windows\Microsoft.NET\Framework\v2.0.50727\
>>
>> So, System.NET shows as follows:
>> System.Net 3.5.0.0 v2.0.50727 c:\Program Files\Reference
>> Assemblies\.....
>> System.Messaging 2.0.0.0 v2.0.50727 c:\Windows\Microsoft.NET\Fra....
>>
>> why does the v3.5 framework DLL shows the same runtime as the v2.0 and
>> v3.0 frameworks? and why is it in a different directory root (C:\Program
>> Files\Reference Assemblies\*) instead of the standard
>> C:\Windows\Microsoft.NET\Framework\v3.5\... ?
>>
>> Shouldn't Visual Studio 2.5 not restrict itself to showing only Framework
>> 2.0 assemblies?
>>
>> Emilio
>

Okay, I may have misread.

As long as you are referencing a 2.0 assembly, you should be fine. These can
be found in a variety of locations, but you cannot mix 2.0 and 3.5 without
some form of service boundary. If you need 3.5 funcationality in an app that
cannot be upgraded, you will have to wrap it with a service and call it.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

Subscribe to my blog
http://gregorybeamer.spaces.live.com/lists/feed.rss

or just read it:
http://gregorybeamer.spaces.live.com/

********************************************
| Think outside the box! |
********************************************
"....DotNet4Ever...." <hate.spam@nowhere.com> wrote in message
news:uJdOdFa7IHA.1952@TK2MSFTNGP02.phx.gbl...
> So if I understand correctly it should be no problem if I reference the
> v3.5 System.Net assembly (apparently not available in previous frameworks)
> from a v2.0 solution?
>
> Emilio
> http://www.PanamaSights.com/
> http://www.Virtual-Aviation.info/
>
>
> "Cowboy (Gregory A. Beamer)" <NoSpamMgbworld@comcast.netNoSpamM> wrote in
> message news:O6pXjRZ7IHA.4108@TK2MSFTNGP04.phx.gbl...
>> 3.0 and 3.5 sit on top of 2.0, so there is no big deal here. All you will
>> find in the 3.x directories is extra stuff. Check it out yourself.
>>
>> Not sure why one is referenced in one spot and not in the main spot. Most
>> likely someone was working with it from there and did not reset the link.
>> As long as it works, it is not a big deal.
>>
>> --
>> Gregory A. Beamer
>> MVP, MCP: +I, SE, SD, DBA
>>
>> Subscribe to my blog
>> http://gregorybeamer.spaces.live.com/lists/feed.rss
>>
>> or just read it:
>> http://gregorybeamer.spaces.live.com/
>>
>> ********************************************
>> | Think outside the box! |
>> ********************************************
>> "....DotNet4Ever...." <hate.spam@nowhere.com> wrote in message
>> news:uOvvpyY7IHA.3480@TK2MSFTNGP03.phx.gbl...
>>>I got a problem in one of my solutions and ran into something that I
>>>suppose is what I think but I find the versioning a bit confusing.
>>>
>>> I was trying the Add Reference in Visual Studio and noticed that it
>>> lists both "Version" and "Runtime". Apparently the .NET Framework
>>> version is in the "Version" but all of them (v2.0, v3.0 & v3.5) have the
>>> same runtime "v2.0.50727" which maps to the
>>> c:\windows\Microsoft.NET\Framework\v2.0.50727\
>>>
>>> So, System.NET shows as follows:
>>> System.Net 3.5.0.0 v2.0.50727 c:\Program Files\Reference
>>> Assemblies\.....
>>> System.Messaging 2.0.0.0 v2.0.50727 c:\Windows\Microsoft.NET\Fra....
>>>
>>> why does the v3.5 framework DLL shows the same runtime as the v2.0 and
>>> v3.0 frameworks? and why is it in a different directory root (C:\Program
>>> Files\Reference Assemblies\*) instead of the standard
>>> C:\Windows\Microsoft.NET\Framework\v3.5\... ?
>>>
>>> Shouldn't Visual Studio 2.5 not restrict itself to showing only
>>> Framework 2.0 assemblies?
>>>
>>> Emilio
>>
>

Hello ....DotNet4Ever....,

> So if I understand correctly it should be no problem if I reference
> the v3.5 System.Net assembly (apparently not available in previous
> frameworks) from a v2.0 solution?

Indeed it is technically possible and should work, but you are not allowed
to distribute the additional dll by itself (which would not work anyway)

Your solution would now require the .Net 3.5 framework and your distribution
method should take account of this.

--
Rory

Hello Cowboy (Gregory A. Beamer),

> Okay, I may have misread.
>
> As long as you are referencing a 2.0 assembly, you should be fine.
> These can be found in a variety of locations, but you cannot mix 2.0
> and 3.5 without some form of service boundary. If you need 3.5
> funcationality in an app that cannot be upgraded, you will have to
> wrap it with a service and call it.


I'm not sure why this is an issue....Doesn't it just mean that after the
reference is made, he is developing a 3.5 application under VS2005

They are all runnable under the 2.0 CLR... right? but to distribute he would
need the 3.5 framework in place



--
Rory

The 2.0 framework will work fine with anything that is in the 2.0.x
folder(s), as they are considered 2.0, even if 3.5 has updated them. None of
the interfaces have changed. I know of nothing that breaks this rule.

If one references something out of the 3.0- directory or the 3.5 directory,
you will have to retarget for 3.5, as it will not compile. You can get
around the compilation "problem" by using reflection (late binding), but it
will fail at runtime, which is probably worse.

This is why I state you can use 3.5 in 2.0 if you wrap it with a service
boundary. This can be a web service or a WCF service (as long as it is
exposed like a web service - WCF allows you to expose in ways only WCF
understands). But you cannot directly access a 3.5 assembly that is marked
3.5, unless you move up to 3.5 as your target framework.

There may be some exceptions to this rule, but I don't know of any.

Am I making this clearer or am I just digging a deeper hole? :-)

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

Subscribe to my blog
http://gregorybeamer.spaces.live.com/lists/feed.rss

or just read it:
http://gregorybeamer.spaces.live.com/

********************************************
| Think outside the box! |
********************************************
"Rory Becker" <rorybecker@newsgroup.nospam> wrote in message
news:3af103471a71d8cabbc6344fbbbe@news.microsoft.c om...
> Hello Cowboy (Gregory A. Beamer),
>
>> Okay, I may have misread.
>>
>> As long as you are referencing a 2.0 assembly, you should be fine.
>> These can be found in a variety of locations, but you cannot mix 2.0
>> and 3.5 without some form of service boundary. If you need 3.5
>> funcationality in an app that cannot be upgraded, you will have to
>> wrap it with a service and call it.
>
>
> I'm not sure why this is an issue....Doesn't it just mean that after the
> reference is made, he is developing a 3.5 application under VS2005
>
> They are all runnable under the 2.0 CLR... right? but to distribute he
> would need the 3.5 framework in place
>
>
> --
> Rory
>
>

A co-worker sent an executable (3.5) developed which used an openfiledialog.
For no apparent reason, the SafeFileName property was used in the code.
This is only available in 2.0 SP 1, and therefore was failing on the 2.0
only machine. In this case, the user friendly message was that the property
does not exist.

It was an easy fix though and none of us really know why the new property is
there, but that is another discussion...

"Cowboy (Gregory A. Beamer)" <NoSpamMgbworld@comcast.netNoSpamM> wrote in
message news:ufaeFpl7IHA.5164@TK2MSFTNGP02.phx.gbl...
> The 2.0 framework will work fine with anything that is in the 2.0.x
> folder(s), as they are considered 2.0, even if 3.5 has updated them. None
> of the interfaces have changed. I know of nothing that breaks this rule.
>
> If one references something out of the 3.0- directory or the 3.5
> directory, you will have to retarget for 3.5, as it will not compile. You
> can get around the compilation "problem" by using reflection (late
> binding), but it will fail at runtime, which is probably worse.
>
> This is why I state you can use 3.5 in 2.0 if you wrap it with a service
> boundary. This can be a web service or a WCF service (as long as it is
> exposed like a web service - WCF allows you to expose in ways only WCF
> understands). But you cannot directly access a 3.5 assembly that is marked
> 3.5, unless you move up to 3.5 as your target framework.
>
> There may be some exceptions to this rule, but I don't know of any.
>
> Am I making this clearer or am I just digging a deeper hole? :-)
>
> --
> Gregory A. Beamer
> MVP, MCP: +I, SE, SD, DBA
>
> Subscribe to my blog
> http://gregorybeamer.spaces.live.com/lists/feed.rss
>
> or just read it:
> http://gregorybeamer.spaces.live.com/
>
> ********************************************
> | Think outside the box! |
> ********************************************
> "Rory Becker" <rorybecker@newsgroup.nospam> wrote in message
> news:3af103471a71d8cabbc6344fbbbe@news.microsoft.c om...
>> Hello Cowboy (Gregory A. Beamer),
>>
>>> Okay, I may have misread.
>>>
>>> As long as you are referencing a 2.0 assembly, you should be fine.
>>> These can be found in a variety of locations, but you cannot mix 2.0
>>> and 3.5 without some form of service boundary. If you need 3.5
>>> funcationality in an app that cannot be upgraded, you will have to
>>> wrap it with a service and call it.
>>
>>
>> I'm not sure why this is an issue....Doesn't it just mean that after the
>> reference is made, he is developing a 3.5 application under VS2005
>>
>> They are all runnable under the 2.0 CLR... right? but to distribute he
>> would need the 3.5 framework in place
>>
>>
>> --
>> Rory
>>
>>
>