A framework confusion

  • Thread starter Thread starter ....DotNet4Ever....
  • Start date Start date
D

....DotNet4Ever....

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?
Click to expand...

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\... ?
Click to expand...

No Idea. Presumably for organisational purposes.
Shouldn't Visual Studio 2.5 not restrict itself to showing only
Framework 2.0 assemblies?
Click to expand...

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.
 
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! |
********************************************
 
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! |
********************************************
 
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?
Click to expand...

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.
 
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.
Click to expand...


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
 
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! |
********************************************
 
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) said:
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! |
********************************************
Click to expand...
 
Back
Top