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.
Almost certainly 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.
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.
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. ;)
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.
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.
.NET 3.5 issue - Dynamic Data Issue
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
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’.”
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.'
.NET 3.5 SP1: JIT generates incorrect code in managed C++ edge case
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.
Obfuscated 1.1 assemblies may fail if they override certain methods in the Framework
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.
How .Net 3.5 SP1 broke Rhino Mocks (ExecutionEngineException...)
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
Serialization hangs or throws an OutOfMemoryException
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.
AutoCommit behavior change in Oracle Transactions in .Net Framework 2.0 SP2
Existing applications which rely on transaction behavior to work correctly will break causing data corruption.
EntityDataSource runtime: Not able to display Dynamic Data's FK Ids in a 1:0..1 relationship
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'.]
SaveChanges doesn't support inserting an entity and binding as a single operation
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
DataServiceContext: DeleteObject on an entity with a link fails
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.
.NET 3.5 SP1 breaks use of WPF under IIS
Relative Hyperlinks inside XPS documents broken and causes app to Crash
Regression: Geometry.Combine creates more points/segments than before in 3.5 sp1
Performance regression in scenarios with Geometry (drawn shapes).
* 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.
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. I am a failed stand-up comic, a cornrower, and a book author.
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.
Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.