Asp Forum - Confused about 3.5 SP1 - microsoft.public.dotnet.framework

rvgrahamsevatenein

8/13/2008 5:18:00 PM

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

13 Answers

sloan

8/13/2008 5:32:00 PM

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.

<rvgrahamsevatenein@sbcglobal.net> wrote in message
news:fa6330ff-8290-47be-b5db-2d6ff519860f@z6g2000pre.googlegroups.com...
> 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

Jon Skeet

8/13/2008 6:40:00 PM

sloan <sloan@ipass.net> wrote:
> 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").

That's not the case. There are lots of new public methods and types in
SP1:

http://codebetter.com/blogs/patricksmacchia/archive/2008/08/1...
sp1-changes-overview.aspx

--
Jon Skeet - <skeet@pobox.com>
Web site: http://www.pobox....
Blog: http://www.msmvps.com...
C# in Depth: http://csharpi...

sloan

8/13/2008 7:45:00 PM

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

"Jon Skeet [C# MVP]" <skeet@pobox.com> wrote in message
news:MPG.230d3aee22617d8cebf@msnews.microsoft.com...
> sloan <sloan@ipass.net> wrote:
>> 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").
>
> That's not the case. There are lots of new public methods and types in
> SP1:
>
> http://codebetter.com/blogs/patricksmacchia/archive/2008/08/1...
> sp1-changes-overview.aspx
>
> --
> Jon Skeet - <skeet@pobox.com>
> Web site: http://www.pobox....
> Blog: http://www.msmvps.com...
> C# in Depth: http://csharpi...

Jon Skeet

8/13/2008 8:06:00 PM

sloan <sloan@ipass.net> wrote:
> I guess I consider contract breaks meaning code you have right now, won't
> compile in SP1.

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

--
Jon Skeet - <skeet@pobox.com>
Web site: http://www.pobox....
Blog: http://www.msmvps.com...
C# in Depth: http://csharpi...

Alex Clark

8/13/2008 8:23:00 PM

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

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

Jon Skeet

8/13/2008 8:44:00 PM

Alex Clark <quanta@noemail.noemail> wrote:
> > To be honest, having seen some of the stuff in SP1, it feels more like
> > a 3.6 than a genuine service pack...
>
> 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...

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.

--
Jon Skeet - <skeet@pobox.com>
Web site: http://www.pobox....
Blog: http://www.msmvps.com...
C# in Depth: http://csharpi...

Peter Duniho

8/13/2008 10:35:00 PM

On Wed, 13 Aug 2008 13:05:45 -0700, Jon Skeet [C# MVP] <skeet@pobox.com>
wrote:

> [...]
> To be honest, having seen some of the stuff in SP1, it feels more like
> a 3.6 than a genuine service pack...

For that to be a valid comment there would have to be some rhyme or reason
to how Microsoft assigns version names/numbers to the .NET technologies.
:)

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

Pete

Druid

8/14/2008 5:47:00 AM

> 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. :)
>
How About .NET Windows Foundation 1.0 being the new name for .NET4?! ;-)

Cowboy

8/14/2008 12:55:00 PM

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

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

********************************************
| Think outside the box! |
********************************************
<rvgrahamsevatenein@sbcglobal.net> wrote in message
news:fa6330ff-8290-47be-b5db-2d6ff519860f@z6g2000pre.googlegroups.com...
> 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

Pavel Minaev

8/14/2008 1:20:00 PM

On Aug 14, 12:05 am, Jon Skeet [C# MVP] <sk...@pobox.com> wrote:
> sloan <sl...@ipass.net> wrote:
> > I guess I consider contract breaks meaning code you have right now, won't
> > compile in SP1.
>
> 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.

Here's the link:

http://blogs.msdn.com/ed_maurer/archive/2008/02/16/breaking-change-in-linq-queries-using-explicitly-typed-range-vari...

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

microsoft.public.dotnet.framework

Confused about 3.5 SP1

rvgrahamsevatenein

sloan

Jon Skeet

sloan

Jon Skeet

Alex Clark

Jon Skeet

Peter Duniho

Druid

Cowboy

Pavel Minaev

x Login to ForumsZone