Confused about 3.5 SP1

  • Thread starter Thread starter rvgrahamsevatenein
  • Start date Start date
R

rvgrahamsevatenein

I've installed VS2008 SP1 with .net Framework 3.5 SP1 on my
development machines... The apps I'm building (or rebuilding) seem to
run fine on client machines that are at 3.5. Is there a reason to
install 3.5SP1 on the users machines?

Bob
 
Here is my off the top of my head advice.

I don't think the CONTRACT for SP1 breaks anything with the 3.5 framework.
Therefore, any code you create with SP1 will work on clients with 3.5(SP0)
(SP0 is my notation for "no service pack").

However, if there was a bug in the 3.5_SP0 code that you've encountered and
you want resolution, then you need the clients to install 3.5.

You'll probably get some better advice from others.


Usually the people who really really need SP1 on the clients are the ones
who've encountered the bugs .. fixed by the SP.
 
I guess I consider contract breaks meaning code you have right now, won't
compile in SP1.

New stuff wouldn't break the contract in my mind (unless an interface forced
a new method to implement or something like that).


But I see it the other way as well. He could develop ~new~ code with the
new types that won't run on the old (SP0).

Either way, its good to know and have a reference source.

Thanks for clearing it up.


No public types removed (hopefully!)

SELECT TYPES WHERE IsPublic AND WasRemoved
 
sloan said:
I guess I consider contract breaks meaning code you have right now, won't
compile in SP1.
Click to expand...

That way is fine - although not strictly accurate in this case. I
believe there's at least one bug which was fixed in SP1 which would
previously have allowed code which shouldn't work to work. I can't find
the link now, but basically listOfInts.Cast<float>() would have been
okay before, but will now throw an exception when you try to iterate
through it.

However, my point was against what you wrote before:

<quote>
Therefore, any code you create with SP1 will work on clients with 3.5
(SP0).
</quote>

To be honest, having seen some of the stuff in SP1, it feels more like
a 3.6 than a genuine service pack...
 
To be honest, having seen some of the stuff in SP1, it feels more like
a 3.6 than a genuine service pack...
Click to expand...

Well, to give it it's correct version notation, it should really be called
..NET 2.3.

v3.0 was really 2.1, v3.5 was really 2.2, and the new bangs and whistles
this SP adds push it up to 2.3. At its core it is still, of course, 2.0
with some nice addons.

Weird way to version it if you ask me...
 
Alex Clark said:
Well, to give it it's correct version notation, it should really be called
.NET 2.3.

v3.0 was really 2.1, v3.5 was really 2.2, and the new bangs and whistles
this SP adds push it up to 2.3. At its core it is still, of course, 2.0
with some nice addons.

Weird way to version it if you ask me...
Click to expand...

I would personally have called 3.0 => 2.5 and 3.5 => 3.0. There are
enough new features (including *language* features) to merit a major
bump at that point, IMO - I don't think there's a need to keep parity
between CLR and Framework version, for instance.

The fact that core libraries were amended and added to makes it a
bigger version change than the straight additions from 2.0 to 3.0.
 
As near as I can tell, it's all pretty much random, with the only real
constraint being that the names/numbers are monotonically increasing for
any given component. Frankly, I'm not sure that we'll even be able to
count on that long-term. :)
Click to expand...
How About .NET Windows Foundation 1.0 being the new name for .NET4?! ;-)
 
If you are not using the new stuff (ADO.NET Entitities, AJAX enhancements,
routing, dynamic data, data services, etc.), then the app can work fine on
the client machines without SP1. There are also fixes in the SP, but you
have to decide how much "pain" you need at this time. I would imagine this
SP will be a suggested update on Windows Update at some time and they will
update then.

As far as "is there a reason" is concerned, I have not looked at a list of
fixes in the SP, so I cannot definitively give a reason to update now.

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

Subscribe to my blog
http://feeds.feedburner.com/GregoryBeamer#

or just read it:
http://feeds.feedburner.com/GregoryBeamer

********************************************
| Think outside the box! |
********************************************
 
That way is fine - although not strictly accurate in this case. I
believe there's at least one bug which was fixed in SP1 which would
previously have allowed code which shouldn't work to work. I can't find
the link now, but basically listOfInts.Cast<float>() would have been
okay before, but will now throw an exception when you try to iterate
through it.
Click to expand...

Here's the link:

http://blogs.msdn.com/ed_maurer/arc...s-using-explicitly-typed-range-variables.aspx

Basically, they've used IConverter in Enumerable.Cast before, so you
could do some value-type conversions using it as well - such as float-
int - but the semantics of those were different from C# casts. In
Click to expand...
SP1, they've changed it to use a plain C# cast, which means that value
conversions won't work anymore, only the usual object reference
upcasting/downcasting.

I wish they've introduced an argumentless Enumerable.Convert() to
provide the old behavior on explicit request, though.
 
Back
Top