Update on .NET Framework 3.5 SP1 and Windows Update
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 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: | 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 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: | 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.
About Newsletter
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.
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.
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?
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.
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.
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.
Was that supposed to be a dig at Apple, or recognition that backward compatibility isn't necessarily important for market success?
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>
There is a new FxCop rules-set that will catch you doing that sort of issue. check out Dave Kean's blog entry
> anymore, interestingly ;) )
So why can't my .Net Windows XP shell extension run on Vista?
[rhetorical question]
Do you call Microsoft Update "Moo"?
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 ;-)
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.
> 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
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
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.
"(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.
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.
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
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?
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. ;-)
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.
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 ;)
Thanks,
Franck
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.
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
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?
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
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
So something must be up with that control! Unknown runtime errors are gone..
Thanks in advance.
(note: this works pre sp1)
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.
Personally, I think the application compatibility is great. I also think Microsoft could learn from what Apple did.
Comments are closed.
How is that possible? AMD64 versions of Windows removed DOS and Win3.x app support! (No, a virtual machine doesn't count.)