Scott Hanselman

Update on .NET Framework 3.5 SP1 and Windows Update

September 23, '08 Comments [53] Posted in ASP.NET | ASP.NET Dynamic Data | Bugs | Programming | Windows Client
Sponsored By

The .NET Framework 3.5 SP1 included a bunch of new features, but as a Service Pack it also included a number of bug fixes and many improvements. These fixes included all aspects of the .NET Framework from ASP.NET to WPF and the CLR.

Will the .NET Framework 3.5 SP1 break my 2.0 apps?

Almost certainly not.

Why Not?

Remember that 3.5 (and 3.0 before it) all have the 2.0 CLR at their core. If you want excessive detail on this, I've got it. Because the 2.0 CLR is the engine underneath and 3.0 and 3.5 are primarily additive*, there's inherently high application compatibility between these releases.

Realize that 2.0, 3.0 and 3.5 are not different products, no matter what anyone says. They are not different "Side By Side" releases, like 1.x and 2.0 were. They are evolutionary; if anything, our naming could have been better (you think?), but rather each adds functionality to the one before it. They are really additive releases to the same core product.

But, I've hit an edge case…

We’re committed to application compatibility. However you may have heard or reported issues or bugs around 3.5 SP1 and I’ll go into how we’re dealing with those below. Most of these are corner-case/edge-case situations.

It may be cold comfort when it’s your bug and your company and it sounds like a marketing line, but it’s true. There are a lot of resources working to minimize impact to you.

I’ve now been on both sides, when working in a large ISV and trying to get a hotfix, and now on the inside trying to keep compatibility while keeping things secure and correct. There is a massive amount of unit and integration testing that goes into the .NET Framework (that includes all technologies under that umbrella).  That means that every effort is made not to break stuff. That’s why Visicalc still runs nicely on my Vista x86 machine (although I can’t run OS 9 apps on OS X anymore, interestingly ;) ) 

Software testing is a combinatorial problem, and as such all software has bugs, but sometimes when a bug comes back it’s called a “regression.” That means it was fixed before, and now it doesn’t. Sometimes folks call a new bug a regression their software worked before and it doesn’t now. This might be because they relied on an incorrect behavior that was later corrected, or that it was just a bug.

It IS possible that something could break, so as with all SP’s you should do compatibility testing to make sure you’re not hitting an edge case.  If you are affected by a bug at some point, we’re trying to get you a very fast response. Notice in the table below there’s a “How Found” column. You can report on Forums, contact PSS or use Connect to report bugs.

When will the .NET Framework 3.5 SP1 be pushed to Windows Update?

Later this year, probably November-ish, the .NET Framework 3.5 SP1 will begin show up on Windows Update in a rolling and throttled fashion so that all machines that have .NET 2.0 or higher will be automatically upgraded to 3.5 SP1.

If you’re an ISV or Hoster, you might be concerned that you’d wake up one day and find machines updated to 3.5 SP1 via Windows Update before these bugs are fixed.

There will be an update/patch made to .NET 3.5 SP1 before it goes live on Windows Update. We are holding SP1 on Windows Update (Microsofties call it “WU” or “Woo”) until this patch is finalized. 

That patch is called a GDR, or General Distribution Release, coming for .NET 3.5 SP1. A GDR is a Microsoft TLA (Three Letter Acronym) for an update that is for everyone. This update’s goal is to fix bugs that have been found in .NET 3.5 SP1. Many of these bugs were found by the community and reported on the Connect site.

We won’t push .NET 3.5 SP1 to WU until everyone feels confident it’s solid.

I know if you have a particular bug on Connect that you’re watching, you might be a little frustrated and be wondering what its status is. We’re working on getting the Connect Bugs updated and lots of folks (myself included) are trying at every turn to increase transparency. This blog post is an example. If they stop abruptly, I’ve finally been fired for them. ;)

Transparency

Sometimes your app might break and the issue isn’t “fixed,” but closed with “By Design” or “Workaround.” This can be frustrating (believe me, I know) but some fixes can break other things, and there’s always security to consider. In the near future I’m going to try to dig into some really icky details of a few of the more interesting bugs and get some color commentary on them. I’m going to encourage the other teams to do the same. I know the BCL team had a few interesting issues and have expressed an interested in digging in and blogging some wonky technical details.

If you don’t want a bunch of details, you can stop reading now.

Wonky Technical Details

In the interested on transparency, here’s some of the bugs I’m tracking for this GDR. Note you can find most, if not all, of these bugs/issues on Connect and each team will be updating those with as much details as they have. Watch the issues there for the most up-to-date information we've got. If you feel something isn't getting attention, let me know and I'll poke the right manager.

Title

Product Unit

Details

How Found

.NET 3.5 issue - Dynamic Data Issue

ASP.NET

Dynamic Data fails on Entity Framework data models that contain 1->0..1 and *->1 database relations with an error like "'System.Web.UI.WebControls.EntityDataSourceWrapper' does not contain a property with the name 'Orders.OrderID'". These types of relationships occur in many databases including Northwind and AdventureWorks.

The error is caused by a naming mismatch that Dynamic Data has with the wrapper objects being returned by the EntityDataSource. We have a temporary fix available at: http://www.codeplex.com/aspnet/Release/ProjectReleases.aspx?ReleaseId=16367 which replaces the data model provider with one that names the properties correctly.

3rd party Forum

Hidden files/folders inside App_Browsers are not ignored

ASP.NET

This customer applied FrontPage Server Extensions (FPSE) to the site.  Normal behavior is to add metadata files inside _vti_cnf folders for each file in the site.  Therefore, inside App_Browsers folder, after applying FPSE, we get a hidden folder called _vti_cnf that contains the file called BrowserFile.browser
Trying to parse that file will result in this error, since this is not a real .browser file, but instead just a metadata file.

The workaround for now is to delete _vti_cnf folder, but we'll fix this.

PSS DTS Issue

After installing .NET 3.5 SP1, a web site using a derived version of the UpdateProgress control may encounter the following exception: “A ProgressTemplate must be specified on UpdateProgress control with ID ‘id’.”

ASP.NET

In the .NET Framework 3.5, the UpdateProgress control enforced the requirement of a ProgressTemplate from its PreRender routine. A derived UpdateProgress control could subvert that requirement by overriding OnPreRender in the derived control, and avoiding calling base.OnPreRender. In the .NET Framework 3.5 SP1, the UpdateProgress control now uses CreateChildControls to instantiate the ProgressTemplate, causing the requirement to be enforced at a different point in the page life cycle, and preventing the OnPreRender technique from subverting the check.

Other

SGEN and Obsolete attribute

WCF

ASMX web methods do not return serialized results. What the customer does is to SGEN an assembly that contains some types with [Obsolete(IsError = true)].  What he sees is SGEN throwing an error and  refusing to generate a serialization assembly. 

Here is the message you get from SGEN:
Microsoft (R) Xml Serialization support utility
[Microsoft (R) .NET Framework, Version 2.0.50727.1432]
Copyright (C) Microsoft Corporation. All rights reserved.
Error: Unable to generate a temporary class (result=1).
error CS0619: 'SGenTest.Program' is obsolete: ‘Testing.'
error CS0619: 'SGenTest.Program' is obsolete: 'Testing.'

Other

.NET 3.5 SP1: JIT generates incorrect code in managed C++ edge case

CLR

This is caused by JIT optimization changes we made in 3.5SP1. We promote some fields to registers when we shouldn't. Limited to structs or classes with four or fewer scalar fields, none of which are managed object references.The scope is additionally reduced in that this bug only manifests when using the cpblk or initblk instructions, which are only emitted by the managed C++ compiler.The issue does apply to both JITted and NGEN'd code.

MSConnect

Obfuscated 1.1 assemblies may fail if they override certain methods in the Framework

CLR

1.1 code that used to run successfully on 2.0 will no longer run on 3.5 SP1 (throws a MissingMethodException).

The underlying problem is as follows. Let’s say you have a 1.1 Framework type that overrode a virtual method, then stopped overriding it in 2.0. This should not be a breaking change, because an implementation of the method still exists (somewhere earlier in the inheritance hierarchy). However, if a customer overrode that method, built against 1.1, then obfuscated the code, the obfuscated code no longer works when run against 2.0 SP2/3.5 SP1.

Obfuscators that are using undocumented techniques to accomplish their task tend to get broken when we optimize things. Workaround is to not obfuscate these few methods, usually by marking them with an attribute. Long term workaround is for the obfuscator to play nice.

3rd party Forum

How .Net 3.5 SP1 broke Rhino Mocks (ExecutionEngineException...)

CLR

This bug has been reported to break Rhino Mocks, an open-source, mock testing framework.The specific impact to Rhino Mocks is that it breaks its support for F#, C++ and Spec# It has 71 validations and 119 ratings (avg. 4.9), which is high for a Connect bug
http://www.ayende.com/Blog/archive/2008/08/13/How-.Net-3.5-SP1-broke-Rhino-Mocks.aspx is the blog which discusses the issue with many community comments This is likely the source of much of the validations.

In 3.5 SP1 we removed a null check as a side-effect of changes we made to support ASLR. As a result, a failure case we used to handle now results in an AV in the runtime which manifests as an ExecutionEngineException and process termination

MSConnect

Serialization hangs or throws an OutOfMemoryException

CLR

This issue is also mentioned on the Rhino Mocks web site, where another breaking change in 3.5SP1 was reported. It is unclear as to whether or not this issue also breaks Rhino Mocks test software.

Due to changes in the type system, types with the following criteria:Generic type instantiated with a reference typeImplements ISerializableContains a static field.

MSConnect

AutoCommit behavior change in Oracle Transactions in .Net Framework 2.0 SP2

DPR

Existing applications which rely on transaction behavior to work correctly will break causing data corruption.

MSConnect

EntityDataSource runtime: Not able to display Dynamic Data's FK Ids in a 1:0..1 relationship

DPR

This breaks web sites/applications created with ASP.NET Dynamic Data because Dynamic Data assumes the property descriptors exist and uses them to obtain labels for their links. The only known workaround requires manually editing Dynamic Data's templates (for wich each site/app has private copies) to capture the exception. The exception generally of the form:
[HttpException (0x80004005): DataBinding: 'System.Web.UI.WebControls.EntityDataSourceWrapper' does not contain a property with the name 'Manager'.]

3rd party Forum

SaveChanges doesn't support inserting an entity and binding as a single operation

DPR

If the resource takes part in a relationship (e.g. 1:1), then while inserting a new instance of the resource, we need to send the link also, since the link is required at the database level. The client does not send the links while inserting such resources

3rd party Forum

DataServiceContext: DeleteObject on an entity with a link fails

DPR

This impacts deletion of any resource which has reference properties.

A link for a reference property should never be in Added or Deleted state. Instead, it should always be modified with reference target to null in case of delete/non-null in case of add/update.

3rd party Forum

.NET 3.5 SP1 breaks use of WPF under IIS

WPF

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=361469

MSConnect

Relative Hyperlinks inside XPS documents broken and causes app to Crash

WPF

Fixed.

MSConnect

Regression: Geometry.Combine creates more points/segments than before in 3.5 sp1

WPF

Performance regression in scenarios with Geometry (drawn shapes).

Other

Related Posts

* Remember, if you're running around edge cases and are concerned, you can happily target 2.0 and 3.0 from VS2008 and use a CodeAnalysis Rule to make sure you're only calling methods for your targeted framework.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web
Tuesday, September 23, 2008 5:44:23 PM UTC
> Visicalc still runs nicely on my Vista x64 machine
How is that possible? AMD64 versions of Windows removed DOS and Win3.x app support! (No, a virtual machine doesn't count.)
Michael Ratanapintha
Tuesday, September 23, 2008 5:49:16 PM UTC
Michael - Sorry, fat fingered that. Should be Vista x86. Thanks!
Tuesday, September 23, 2008 6:03:11 PM UTC
"Because the 2.0 CLR is the engine underneath and 3.0 and 3.5 are primarily additive*, there's inherently high application compatibility between these releases."

That's only true if the CLR remains stable between releases. However, according to an email conversation I have been having with Mike Downen about my SP1 bug (https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=361539, which didn't make your list), attempting to improve the CLR's start-up time involved "re-writing a large portion of our code generation and type loading code." Undertaking such a risky process during a "service pack" release does not seem consistent with Microsoft's message of "commitment to application compatibility" and should give anyone pause when considering the safety of installing SP1.
Tuesday, September 23, 2008 6:08:19 PM UTC
Scott,

First, thanks for the page! I've bookmarked it so I hopefully don't get caught by any more hidden surprises.

Second, can you add this edge case to your list?

Essentially, ASP.NET code that references ScriptReference and is compiled with 3.5SP1 but is deployed to a server without SP1 will throw System.TypeLoadException due to a refactoring of ScriptReference's parent class.
Tuesday, September 23, 2008 6:12:42 PM UTC
I love the backward compatibility stuff (its not 100% as you mentionned, but its close...so all my apps went from 2.0 to 3.5SP1 smoothly, give or take a little detail or two), but I do have to ask: Will you eventually break compatibility?

The whole reason .NET was seen as a superior platform to Java by many (except for cross platform and maturity of certain tools, but Im talking about the raw platform here), was because it did right certain things that Java could not change for backward compatibility reasons.

If .NET always stays backward compatible to this level, it will stagnate and become irrelevant in a few years, except for those who already invested in it. New green field development will not benefit from it. So it is possible in .NET 4.0 or 5.0 that you will (on purpose) break things, on the level of 1.1 vs 2.0, or more? Things like fully integrating nullable in the framework, fixing old design mistakes progressively (not all at once =P), etc? Or will the mistakes of the past haunt us forever?

I figure keeping backward compatibility for most versions, but every couple of years breaking some stuff would prevent .NET from becoming irrelevent in 4-5 years... What do you think?
Francois Ward
Tuesday, September 23, 2008 6:18:48 PM UTC
Francois - I'm guessing, but my gut is that 4.0 will be a whole new side-by-side version, like 2.0 was to 1.x and that will be an opportunity to break things, on purpose, in order to move forward. Of course, things wouldn't really break as 2.x/3.5 will still be around and run code fine, just as 1.x is still around and running code.
Tuesday, September 23, 2008 6:26:15 PM UTC
I converted my 2.0 applications to VS2008 under 3.5SP1 with no issues at all.

I've had more complaints with users running my new code on 2.0 Framework, so I'm glad Microsoft is pushing out 3.5SP1 soon.
Tuesday, September 23, 2008 6:33:39 PM UTC
Scott,
The first part of the post attempts to pacify people into saying that SP1 isn't going to impact their apps.
The second one lists a lot of critical issues that can most certainly kill an app.
And regression is when something that worked before, and was documented to work, no longer work in a new version.

Tuesday, September 23, 2008 6:39:46 PM UTC
Ayende - I'm not trying to "pacify" anyone, rather I'm trying to empower folks by given them more information than they had. I respect your point though.

I agree there are regressions here. However, most of these issues are edge cases. For the VAST majority of folks who don't hit these, they are not going to be affected. For the ones that are, it sucks, and that's why those things are going to be fixed. When you (when a person) hits an edge case, it's no longer and "edge case" anymore, is it? It's the ONLY case, especially if it blocks you.

As I mentioned to you before, I'm going to hook you up with the right devs on the team so that this doesn't happen again.
Tuesday, September 23, 2008 7:05:27 PM UTC
"(although I can’t run OS 9 apps on OS X anymore, interestingly ;) )"

Was that supposed to be a dig at Apple, or recognition that backward compatibility isn't necessarily important for market success?
Tuesday, September 23, 2008 7:10:44 PM UTC
Josh - Touche. It was a little of both. I have an OS 9 app for children I want to run, and I can't. I can still run old games on Vista though. I'm a PC! ;) (With two Macs at home)
Tuesday, September 23, 2008 7:49:55 PM UTC
TMI for me. Doesn't affect any of the web CRUD that I do. People it will affect is those that don't know how to draw a straight line between 2 points. Think I'll wait, I don't need any of the bells and whistles of the upgrade. Too bad they can't make the FTP work faster or better. I guess that is not as glamorous. Entropy sets in.
John A. Davis
Tuesday, September 23, 2008 8:12:30 PM UTC
While .NET 3.5 sp1 won't necessarily break your 2.0 application, Visual Studio 2008 very well might. There are actually 3 2.0 frameworks (2.0, sp1, sp2) and of course the way you detect which version is installed changes with every release, as do the OS requirements and pre-requisites. 2.0 sp1 doesn't even list Windows Installer 3.1 as a requirement, you have to install it to find that out. Then with 2.0 sp2, there's not even a complete redistributable available...

Since VS.NET 2008 doesn't let you specify which 2.0 framework you'd like to target, it's very easy to generate code that doesn't run on client systems unless you hop on the train of endless deployment problems & complexity. It seems like the bizarre 2.0->3.5 architecture re-introduces a lot of the confusion & FUD that we've migrated away from COM to avoid.

Can you tell I've been chasing down framework issues? <Sigh>
Eric Nicholson
Tuesday, September 23, 2008 8:59:10 PM UTC
Eric,

There is a new FxCop rules-set that will catch you doing that sort of issue. check out Dave Kean's blog entry
Tuesday, September 23, 2008 9:41:56 PM UTC
We've been having an issue with FileSystemWatcher.Dispose where it will hang for a good 10-20 seconds. This only started after we installed 3.5 SP1, even though our app targets 2.0. Has this been reported anywhere else?
Tuesday, September 23, 2008 11:10:12 PM UTC
> That’s why Visicalc still runs nicely on my Vista x86 machine (although I can’t run OS 9 apps on OS X
> anymore, interestingly ;) )

So why can't my .Net Windows XP shell extension run on Vista?

[rhetorical question]
RichB
Tuesday, September 23, 2008 11:13:56 PM UTC
> We are holding SP1 on Windows Update (Microsofties call it “WU” or “Woo”)

Do you call Microsoft Update "Moo"?
RichB
Wednesday, September 24, 2008 2:45:21 AM UTC
Though it is beyond the point of the article I think the commentary about Visicalc was the one that caught everyone's attention :-)

This kind of problem just don't happen in a world of open source software. Having to break compatibility for the sake of evolution (OS 9 to OS X) or make a bloated thing for compatibility's sake (Win) is the end result of closed source software. But, in the real world it is impossible to have everything open, so either breakage or bloat will happen. The difference is that system that compromise and make the break every 10 years or so can move faster into the future - as we've already seen ;-)
Fabio
Wednesday, September 24, 2008 4:35:48 AM UTC
RichB - What kind of ShellExtension? I've got a bunch running under Vista, like TortoiseSVN...you mean a Namespace Extension?
RichB^2 - Yes, "moo." ;)

Fabio - Are you saying that Open Source just goes and breaks stuff and folks get over it? That's been my experience. ;)

JamiePenney - I will ask about your FileSystemWatcher issue.
Wednesday, September 24, 2008 7:50:21 AM UTC
> RichB - What kind of ShellExtension? I've got a bunch running under Vista, like TortoiseSVN...you mean a
> Namespace Extension?

"Windows 95 introduced (and Windows Vista removed) the concept of ShellExecute hooks"
http://blogs.msdn.com/oldnewthing/archive/2008/09/10/8938051.aspx

"Note Support for IColumnProvider has been removed from Windows Vista. "
http://msdn.microsoft.com/en-us/library/bb776147.aspx


RichB
Wednesday, September 24, 2008 10:46:26 AM UTC
Scott,

glad to hear that you did the right thing! The ExecutionEngineException bug really sucked for us (it's actually our Connect bug, not Ayendes). As I've <a href=http://www.re-motion.org/blogs/team/archive/2008/08/14/.net-3.5-sp1-broke-some-scenarios-for-mixins.aspx">mentioned</a> to other people at MS before, we have discovered a lot of rather low-level CLR bugs in the past while creating our re-motion framework, and it's all in our unit tests. I'm surprised that nobody followed up on my offer to share our unit test with you. I think the SP1 problems really show that something like an app compatibility lab would be a good thing. So I'm offering it one more time here.

cheers, Stefan
Wednesday, September 24, 2008 11:59:27 AM UTC
I recently did a post on one of the "breaking" changes that I spotted in SP1. Specifically, it relates to risks that devs can have if they are developing on an SP1 machine but deploying to machine that doesn't have the service pack. See here for details.
Wednesday, September 24, 2008 2:43:33 PM UTC
Scott,
These 2 sentences seem to be at odds with each other:
"They are really additive releases to the same core product."
"Due to changes in the type system..."

Changes to the type system seem awfully low-level for a service pack that does not change the fundamentals of the CLR.
Jason
Wednesday, September 24, 2008 3:48:24 PM UTC
How will we distinguish between 3.5 SP1 unpatched and 3.5 SP1 patched? Will it now be called 3.5 SP2? Or maybe 3.5 SP1 SP1!
Wednesday, September 24, 2008 8:03:41 PM UTC

"(although I can’t run OS 9 apps on OS X anymore, interestingly ;) )"
...
"I can still run old games on Vista though. I'm a PC!"

Really? I can't seem to get Multiplayer Age Of Empires version 1 to work on my Vista 64 box.....

I'm an avid read and love most of your articles, but that was a bad dig @ Apple.
Michael
Wednesday, September 24, 2008 8:47:53 PM UTC
Michael - ;) Ah, that's not Vista, the AOE1 servers were shut down a while back. AOE3 works fine.
Thursday, September 25, 2008 7:42:14 AM UTC
"Later this year, probably November-ish, the .NET Framework 3.5 SP1 will begin show up on Windows Update in a rolling and throttled fashion so that all machines that have .NET 2.0 or higher will be automatically upgraded to 3.5 SP1."

That's very good news! That includes both XP and Vista, right? So all Vista systems will "soon" have FX 3.5 SP1, and any XP system that doesn't have .NET installed yet will be able to easily install Client Profile. That will simplify my Paint.NET v4 upgrade scenarios quite a bit, simply by reducing the number of people that need to sit through another .NET installation.

Although by the time FX 3.5 SP1 gets a good installed base, we'll already be wanting to upgrade to FX 4.0 ... and so the cycle repeats.
Monday, September 29, 2008 1:27:56 PM UTC
Greetings all,

Hi Scott

Sure Framework 3.5 can break Framework 2 applications.

Please have a look at my post in MSDN (link below)
Since that time I found several other Applications all with described behaviour.
The latest victim behaves a little bit differently though. When all apps. just wouldn’t start silently, Ketarin
( http://cdburnerxp.se/download ) will thought an Exception

"Could not create or load the database file: The type initializer for 'System.Transactions.Diagnostics.DiagnosticTrace' threw an exception."

The main thread:

http://social.msdn.microsoft.com/Forums/en-US/netfxsetup/thread/5a3188ab-335b-4a00-874d-7b7daa0c30f1

In order to run any Framework 2 app. I need temporarily uninstall SP1 for 3.5 and ten install it back - insanity!

Thanks in advice for any fresh ideas. My regards
vbCat
Monday, September 29, 2008 1:39:34 PM UTC
You're very professional.
Monday, September 29, 2008 10:27:39 PM UTC
Another "edge case"... I'm running Ektron CMS400 v 7.0.4.20 content management system. It runs under .NET Framework 2.0, but installing .NET Framework 3.5 SP1 (which in turn installs .NET Framework 2.0 SP2) breaks certain features.

I can roll back the install of .NET Framework 2.0 SP2 on the production server, but that won't help once the update gets pushed to Windows Update.

Any suggestion how to handle this? Is there a way to block that specific Windows Update once it's released? Is there a way to test the GDR in advance so I can prepare for any potential problems?
frankr
Tuesday, September 30, 2008 1:34:12 AM UTC
Scott, good post.

Our organization adopted SP1 Beta 1 for the Entity Framework support after extensive testing. We've only found one problem with it since it was released. Yet we're concerned about updating to SP1 RTM because of what appears to be the large number of "SP1" bugs reported on Connect since SP1 RTM.

It would comfort us greatly if there was some indication from Microsoft about which of the reported bugs were also bugs in the beta. Since we haven't hit those bugs in three months of heavy use, we would feel comfortable updating to SP1 RTM.

If Microsoft were to indicate in the Connect article whether the bug was present in the beta, it would also be a very subtle dig at those who don't test their code with beta releases, but who complain after RTM. ;-)
John Saunders
Tuesday, September 30, 2008 7:34:28 AM UTC
Scott, di you forget about this one? https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=367761
Tuesday, September 30, 2008 2:13:44 PM UTC
@Busoli,

Scott didn't "forget" it. As you can see from the Connect form, the BCL team does not consider that a bug; you were merely relying on undocumented functionality prior to SP1. You shouldn't be surprised when undocumented functionality changes, and you shouldn't expect them to change it for you.
Tuesday, September 30, 2008 2:35:53 PM UTC
I thought I asked Scott, not David.
Tuesday, September 30, 2008 3:34:07 PM UTC
Ouch. ;) I'm actually still tracking that one, and there should be a complete writeup on it and the issue soon.
Tuesday, September 30, 2008 3:56:42 PM UTC
Thanks a lot Scott!
Wednesday, October 01, 2008 9:55:45 AM UTC
Hi Scott,

Thanks for the informative blog. I have a question too.. I have written an AJAX-enabled ASP.NET backoffice application based upon Framework 3.5 which worked just fine. After applying Sp1 however, I get a lot of "Unknown Runtime Error" messages (JavaScript).

This issue is a real problem and I had to remove Sp1 again to get everything working. It seems to originate when I use controls with AutoPostBack functionality within UpdatePanels. I also use the PageRequestManager's add_endRequest() method to raise an EndRequestHandler() event, which does little things like setting the focus on a control.

The following lines of JavaScript worked before Sp1, but raise the Unknown Runtime Error after:

obj.select();

and

document.selection.empty();

I've worked round these by adding try catch statements, but then it just dies somewhere else.

Do you know whether there are open bugs you're working on which will solve this issue?

Thanks,

A worried .Net developer ;)
Marc S
Wednesday, October 01, 2008 7:32:41 PM UTC
I think you have to triage a portion of an API to have "edge cases" in terms of regressions. If an API doesn't work as documented, that's not an edge case.
Thursday, October 02, 2008 8:09:02 AM UTC
The new 3.5 Client Profile is a very good idea. Unfortunately it's not sufficient to print which in my opinion is something you expect from a full client application. Any chance this could be addressed before SP1 goes to Update?

Thanks,

Franck
Thursday, October 02, 2008 9:25:42 PM UTC
Marc S - From Dave Reed on the ASP.NET team:


Unknown runtime error I think can happen if IE attempts to download and execute a script that actually doesn’t contain a script. For example, if a script reference results in a 500 error, IE would try to run the HTML as script. It can also cause the error to have some really off the wall line number, like line number 29583321.

I suggest trying the page in other browsers, especially firefox. Sometimes a different browser gives you a different take on the error since they report errors differently. Also, trying to pair down the page to the smallest possible page that still reproduces the error would really help.
Friday, October 03, 2008 7:32:31 AM UTC
Hi Scott and Dave,

First of all, thanks a lot for your replies.

My application also behaves differently in other browsers. When I get the chance, I'll try to write some code which will reproduce the error.

Thanks,

Marc Schlechter
Marc S
Friday, October 03, 2008 5:06:52 PM UTC
Saturday, October 04, 2008 12:18:32 AM UTC
Alright, a few more questions :)

First, I'm planning to release a version of Paint.NET that uses .NET 3.5 SP1 by the end of the year: http://blog.getpaint.net/2008/10/03/change-of-plans-here-comes-paintnet-v35/ . There is already one comment from a user who's concerned about this edge-case scenarios, so I decided to hop over here and ask about this.

If the release of this .NET 3.5 SP1 "B" is soon, then I've got no problem waiting for it to do my Final/RTW release (I need some thorough beta testing anyway). But if it won't make it until after Christmas, then I'd love to know soon so that I can plan accordingly. (So the first question is: When will this be coming out? Calendar year precision is acceptable :))

Second, will I have to update my bootstrapper/chainer that is already bundling the 280kb Client Profile installer? Or, will that same code automatically download all the newer .NET 3.5 SP1 "B" bits?
Saturday, October 04, 2008 8:29:47 AM UTC
Hi Rick,

I have to admit that I was lucky enough to post here (29 September). I am still in the dark regarding the matter. Most Applications requiring Framework 2 would not start here silently and one as mentioned is throwing exception…

...but thank you for your excellent (!) Paint.Net That’s why I said about being lucky:

1) I came across your Software;
2) …and… It will run (!!!) when SP1 for 3.5 is present.

Actually, now I have only two Framework 2 applications that can start - Paint.Net and surprisingly :-) Microsoft’s ICE (Image Composite Editor)

Best wishes
vbCat
Wednesday, October 29, 2008 6:32:39 PM UTC
The infamous InfoPath Form Server 5566 Error "Error accessing datasource" appears to happen after installing 3.5 SP1, tested using the 100% default Hello World web service created in Visual Studio 2008 SP1.

5 Machines with 3.5 SP1 are giving 5566
2 Machines without 3.5 SP1 are working fine.

The error occurs only on web-based forms, it works fines using infopath client.

Both "Publish to SharePoint Library" or "Publish as Administrative Template" give the same results (work without SP1, wont work with it)

Regards,
Francisco
Monday, November 03, 2008 12:44:30 PM UTC
Update for my problem: I figured out that, as soon as I remove the CalendarExtender (AJAX control toolkit) from my page, everything also works in SP1.

So something must be up with that control! Unknown runtime errors are gone..
Marc Schlechter
Monday, November 03, 2008 2:44:21 PM UTC
Hmm, I have downloaded the latest AJAX Control Toolkit and as soon as I use the Calendar control within an UpdatePanel the error occurs. I have testproject now and can send it as a ZIP file if anyone is interested in fixed this issue.

Thanks in advance.

(note: this works pre sp1)
Marc Schlechter
Friday, November 07, 2008 7:53:04 AM UTC
I just ran into the annoying TypeLoadException/Generics bug. Hopefully it gets fixed soon.
Peter
Saturday, November 08, 2008 1:28:42 AM UTC
@Peter,

Unfortunately, the indications are that it will not be fixed soon. In fact, at this point I'm not even sure that it will be fixed AT ALL before .NET 4.0. After the initial confirmation from the CLR team that it was a bug introduced in .NET 3.5 SP1, it has been practically impossible to get any further information. All I do know at this point is that no one who is talking about the upcoming GDR for 3.5 SP1 is mentioning a fix for this bug.
Tuesday, November 18, 2008 3:46:28 AM UTC
Will a fix for the "CLR: ([some assembly]) Rejecting native image because dependency C:\Windows\assembly\GAC_MSIL\System.Core\3.5.0.0__b77a5c561934e089\System.Core.dll is not native" error be included in the GRE?
Tuesday, November 18, 2008 3:46:41 AM UTC
Will a fix for the "CLR: ([some assembly]) Rejecting native image because dependency C:\Windows\assembly\GAC_MSIL\System.Core\3.5.0.0__b77a5c561934e089\System.Core.dll is not native" error be included in the GRE?
Tuesday, November 18, 2008 3:47:58 AM UTC
(sorry about the duplicate comment, got some funny error when posting)
Thursday, November 20, 2008 2:59:30 PM UTC
C'mon Scott, the Mac OS X comment was uncalled for. There are arguments pro and con for both Apple and Microsoft's views in that regard.

Personally, I think the application compatibility is great. I also think Microsoft could learn from what Apple did.
Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.