Known Migration Issues in .NET Framework 4 Beta 2

Known Migration Issues in .NET Framework 4 Beta 2

Doc version: 2.0

CLR

Title

In ICorProfilerInfo2::GetStringLayout, bufferLength now points to stringLength – bufferLength has been removed from the internal representation of the string class

Description

To reduce memory footprint, we are eliminating a field from the string class named bufferLength, which saves 4 bytes on each string object. This change impacts a public profiler API named GetStringLayout.

This API is used by profilers to obtain the internal layout of the string object. The API currently returns the offset to stringLength and bufferLength and has been changed to instead return the offset to stringLength for both fields. We are also providing a new API that returns only the stringLength.

Customers should use the new API instead and remove any dependencies they had on bufferLength.

Why did we make this change?

The removal of bufferLength allows us to save 4 bytes on every string object, potentially saving a lot of memory in many scenarios.

Title

Simplification of just-in-time debugger registration

Description

Just-in-time debugging is a feature which allows a debugger to be attached at the time an unhandled exception, failfast or diagnostics API call (e.g. System.Diagnostics.Debugger.Break) occurs. In previous versions, there are two locations where JIT-debugger settings can be registered in the registry. 1)

AeDebug: this is the key that controls OS JIT behavior, i.e. native code. 2) .NetFramework: values in this key control debugger launch for conditions in managed code. Starting in this version, the Framework will only look at the AeDebug key.


This change simplifies the registration of just-in-time debuggers and makes it easier to keep behavior consistent between the .NET Framework and Windows going forward.

Title

COM interop now always passes 1033 for the lcid in IDispatch.Invoke rather than the current culture

Description

Currently the CLR passes along the current culture through to COM callees in dispatch interfaces through the lcid parameter in IDispatch.Invoke. Based on customer requests we are changing this to always pass along 1033 (en-us) instead of the current culture.


This behavior is more consistent with the behavior that most automation servers expect. For example,

Microsoft Excel uses this value to determine the locale in which to parse numbers in Excel spreadsheets, causing data corruption.

Title

By default, you can no longer catch exceptions which represent corrupted process state

Description

In previous versions, we allowed catch(Exception e) to catch all exceptions, including those resulting from a corrupted process state. In this version, this syntax no longer catches all exceptions by default.

This change requires the use of a custom attribute for methods wishing to process corrupted state exceptions (System.Runtime.ExceptionServices.HandleProcessCorruptedStateExceptionsAttribute).

Corrupted state exceptions include: .


Corrupted state exceptions represent serious conditions from which the process often cannot recover.

While it is valid in some scenarios to catch the exceptions (such as for logging), usually it’s an error to try to catch the exception, and, instead, unhandled exception escalation policy is a more appropriate mechanism for dealing with these issues, rather than allowing unstable processes to continue executing.

Title

The .NET Framework no longer throws ExecutionEngineExceptions

Description

In previous versions, ExecutionEngineException was sometimes thrown in unrecoverable situations, and sometimes thrown in recoverable situations. In this version, we have changed to either call FailFast in unrecoverable situations, or throw an exception in recoverable situations (typically

InvalidOperationException). ExecutionEngineException has been obsoleted.


This change improves predictability and reliability in the runtime. In past releases, we had given developers guidance to never catch ExecutionEngineExceptions, which makes it more difficult to deal with exceptions in general. If a situation is not recoverable, a catchable exception is generally not the right way to signal this condition, and will allow an unstable process to continue executing. If the situation is recoverable, an exception that can be caught (such as an InvalidOperationException) is the best way to signal the condition.

Title

The CLR Security System (Code Access Security) has been simplified

Description

The CLR security system has been simplified for .NET Framework 4 and Code Access Security policy has been turned off by default. You may see issues when you recompile for .NET Framework 4 if your assembly is marked with the AllowPartiallyTrustedCallers attribute and you used Transparent/Critical

annotations, or if you depended on Code Access Security policy in your applications. You can find more details on these changes here: http://go.microsoft.com/fwlink/?LinkId=131738 .


The enforcement-related changes make it easier to build a secure library that is accessible to sandboxed code by enabling better auditing and static analysis. The policy-related changes give hosts more control of the permissions their code runs with, and improves application start-up time in common scenarios.

Title

On Windows 7 and later, most globalization data are retrieved from the operating system, rather than the .NET Framework, and globalization data in the .NET Framework has been updated

Description

On Windows 7 and future operating systems, the .NET Framework retrieves culture information from the operating system, rather than carrying all of the data with the .NET Framework. As part of this:



The WindowsOnlyCulture and FrameworkCulture types have been marked as obsolete.

Customers should use other culture types when migrating to .NET Framework 4.



Culture data has been updated to reflect bugs fixed and changes in the world. For example (this is not a complete list): o System.Globalization.RegionInfo.CurrencyEnglishName: The currency name of “de-CH” culture will change to be “Fr.” Instead of “sFr.” o System.Globalization.DateTimeFormatInfo.LongDatePattern: The long date pattern of the “dv-MV” culture will change from “dd/MMMM/yyyy” to “dd/MM/yyyy”. o System.Globalization.DateTimeFormatInfo.PMDesignator: The PM designator of “af-

AZ” will change from “nm” to “PM”.



Sorting and casing data has been updated to reflect updates to standards, bug fixes, and changes in the world. For example (this is not a complete list): The new behavior updates are reflection of the following changes: o Unicode 5.1 standard updates: Adding support for all Unicode 5.1 characters, an addition of approximately 1400 characters. The additional characters include new symbols, arrows, diacritics, punctuation, mathematical symbols, CJK strokes and

Ideographs, additional Malayalam and Telugu numeric characters, as well as various additional Myanmar, Latin, Arabic, Greek, Mongolian, and Cyrillic characters.

Sundanese, Lepcha, Ol Chiki, Vai, Saurashtra, Kayah Li, Rejang, Gurmukhi, Oriya, Tamil,

Telugu, and Malayalam characters and Cham are new scripts that are supported with

Unicode 5.1. o Synchronization with Windows 7 sorting and casing data: Windows 7 has been accumulating sorting and casing bug fixes which improved the behavior over what we used to have in previous versions of the .NET Framework.


This allows us to evolve globalization data over time to reflect changes in standards and the world, and have consistent behavior between managed components and native components. It will also allow us to reduce the size of the .NET Framework over time.

Title

Hosting APIs updated for in-process side-by-side

Description

As part of supporting in-process side-by-side, some of the hosting activation APIs in mscoree.idl/mscoree.h have been deprecated. Customers should migrate to the new, in-process sideby-side-aware hosting APIs when migrating to .NET Framework 4.


While the old APIs are still supported, the new APIs make it more clear what the developer’s intent is in activating different versions of the CLR and prevent some common issues with the old APIs, such as accidentally rolling-forward to a new version of the .NET Framework when a new version is installed.

Title

The Type.DeclaringType property now correctly returns null when the type does not have a declaring type

Description

The documentation for this property states: “A Type object representing the enclosing type, if the current type is a nested type; or the generic type definition, if the current type is a type parameter of a generic type; or the type that declares the generic method, if the current type is a type parameter of a generic method; otherwise, a null reference (Nothing in Visual Basic).” Previous versions of the .NET

Framework accidentally returned “this” instead of a null reference in the final case. This has been fixed to correctly return a null reference.


As part of making it possible to meaningfully inherit from the reflection types, we changed the behavior of the base class to match the documentation. Please note, the derived type that the CLR returns in most cases will still have the old, compatible behavior.

Title

Changing a NullReferenceException to a useful exception in delegate creation

Description

Delegate creating used to throw a NullReferenceException when passed a null value in certain rare scenarios. This has been changed to throw an ArgumentNullException instead.


The previous behavior made it difficult to diagnose or debug this issue.

Title

AssemblyName.HashAlgorithm was incorrect for assemblies retrieved by a call to

Assembly.GetReferenceAssemblies

Description

In the previous version, calling AssemblyName.HashAlgorithm always returned SHA1 for assemblies retrieved by a call to Assembly.GetReferenceAssemblies. This was incorrect if the referenced assembly was not strongname-signed. The CLR now will return None, as it does not know the hash algorithm of the referenced assembly because the assembly is not loaded yet.


The previous behavior was incorrect and could lead callers of the API to assume that referenced assemblies were strongname-signed when they were not.

Title

Unused or unimplemented interfaces have been removed from the metadata APIs in .NET Framework 4

Description

The following interfaces have been removed from public headers in .NET Framework 4:



INativeImageINativeImageDependency



INativeImageInstallInfo



INativeImageEvaluate



INativeImageConverter



ICorModule



IMetaDataConverter


In previous versions, it was not possible to get instances of objects that implemented these interfaces and/or the CLR did not accept 3 rd party objects implementing these interfaces, so they were not useful in any runtime scenarios. They have been removed to avoid developer confusion.

Title

The Global Assembly Cache has been moved in .NET Framework 4

Description

The Global Assembly Cache has been moved in .NET Framework 4 for new assemblies. If your application hardcoded the location of the GAC, it may not work. The GetCachePath API returns the new location by default, and has flags to return all of the locations. Finally, this change causes RegFree-COM components that are installed in the GAC not to work, when run against .NET Framework 4.


This change is required to isolate .NET Framework 2.0 assemblies from .NET Framework 4 assemblies in the GAC.

Title

Fix to make TimeZoneInfo.Local consistent with DateTime.Now on pre-Windows Vista machines that do not have up-to-date daylight savings time rules.

Description

We have changed the following operations to use the current OS set of daylight savings time rules, rather than using historical data, to be consistent with the system clock:



System time conversions



DateTime.Now, DateTime.ToLocalTime() and ToUniversalTime() conversions



TimeZoneInfo.ConvertTime() conversions from or to TimeZoneInfo.Local.


We made this change to ensure that TimeZoneInfo.Local and DateTime.Now are always consistent in this scenario.

Title

Changes in TimeSpan formatting

Description

In .NET Framework 4, we added the ability to format a TimeSpan value. So the ToString and Parse methods now have overloads that accept format strings, which allow users to customize the display of this value type. This does mean that if you were previously using format strings when calling

String.Format on TimeSpan values, those format strings will now be respected. If those strings are invalid, you will get an exception.


This change enables new formatting options with the TimeSpan class.

WPF

Title

BitmapEffects have been disabled for performance reasons

Description

The BitmapEffect APIs still exist in this version but are obsoleted and are mostly no-ops. BitmapEffects for blur and drop shadow are the only exceptions and still work in limited scenarios for compatibility reasons.


The BitmapEffect class has a number of performance issues that customers have been wrestling with ever since they were introduced in WPF 3.0. Because of the customer pain that has resulted from

BitmapEffects, and because we now have a suitable replacement for the bulk of BitmapEffect functionality in the form of the new Effect class, we have disabled legacy BitmapEffects in this version.

We strongly encourage you to use the Effect class and its derived classes, which should not suffer from

any of the performance problems affecting legacy bitmap effects when they are used on modern graphics hardware.

Title

Thread affinity is now enforced for the FileDialog class

Description

The FileDialog class may become corrupted if the class is created on one thread and shown on another.

This change enforces that a FileDialog is created and shown on the same thread.


This change was made to improve the reliability of the FileDialog class and prevent threading-related bugs that are difficult to diagnose.

Title

ListCollectionView instances that used a filter sometimes did not show items in the correction position in the list

Description

When you move an item within a collection, a collection view that filters but does not sort used to sometimes compute the wrong position within the filtered list. It now computes the correct position in all cases so as to preserve the relative order of the original collection, just as if the item had been present initially. APIs like ContainerFromItem and IndexOf enable you to write code that works regardless of the exact position of the moved item.


The old behavior was inconsistent with end-user expectations and caused confusion.

Title

Grouping in collections did not preserve collection order

Description

When you insert a new item into a collection, a collection view that groups but does not sort used to add the new item to the end of its group. It now inserts that item into its group so as to preserve the relative order of the original collection, just as if the item had been present initially. APIs like

ContainerFromItem and IndexOf enable you to write code that works regardless of the exact position of the new item.


The old behavior was inconsistent with end-user expectations and caused confusion.

Title

NavigatingCancelEventArgs.IsNavigationInitiator was not set correctly for an island Frame

Description

If a navigation is initiated directly on a Frame, the NavigatingCancelEventArgs.IsNavigationInitiator property should be true. In previous versions, it was false. This is most useful for navigations that occur after the initial navigation, so the change to set it correctly only affects these cases and not the initial navigation. This avoids additional events being raised during startup scenarios. This corrects the implementation to match what the API was always supposed to do, and did do in most situations.


The previous behavior was incorrect and did not have a reasonable workaround to determine if a navigation was initiated by an application or by the user.

Title

UIA: IsOffScreen property incorrectly reported false in some cases when elements were actually not visible

Description

The UIA IsOffScreen property would incorrectly report false when an element was clipped because of any of its parent’s clip bounds (for example, a ListBox with vertical ScrollBar enabled – in this case the value of IsOffScreen was false even for items which are scrolled out of view). This fix is currently limited to Item Controls only (e.g. ListBox or ComboBox).


This bug prevented UIA applications from working correctly with no workaround.

Title

BitmapSource threw an IOException rather than firing the DecodeFailed event under certain circumstances

Description

If you passed BitmapCacheOption.None or if the pixel format of the bitmap required conversion when creating a BitmapSource, WPF threw an IOException rather than firing the DecodeFailed event. This has been fixed to always fire the DecodeFailed event and not throw an exception.


The previous behavior was inconsistent and confusing, and could lead to an unhandled exception.

Title

Cloned BitmapFrameDecode objects did not fire download events and would not update when the download completed

Description

Customers encountered the previous behavior either when cloning BitmapFrameDecode objects directly. This behavior also prevented Image controls from displaying correctly when setting the Image control’s Source property to a style in a resource dictionary. Both of these scenarios have been fixed with this change. Cloned BitmapFrameDecode objects will now fire download events.


The previous behavior prevented cloned BitmapFrameDecode objects from being useful with no reasonable workaround.

Title

Downloading with chains of BitmapSource objects has been fixed

Description

CachedBitmap (CB), ColorConvertedBitmap (CCB), CroppedBitmap (CrB), FormatConvertedBitmap (FCB), and TransformedBitmap (TB) are all subclasses of BitmapSource. As a result, they inherit its

DownloadCompleted, DownloadFailed, and DownloadProgress events. A BitmapSource chain can be set up, which might look like the following:

TB  CrB  FCB  BitmapFrame where the BitmapFrame provides the pixel data, and each link up the chain does some sort of operation.

A downloading BitmapSource chain is a BitmapSource chain in which the link at the end (in this case,

BitmapFrame) is downloading an image. While the BitmapFrame is downloading, it fires

DownloadProgress events. When the download completes (or fails), it fires the DownloadCompleted (or

DownloadFailed) events.

Under the old behavior, only the BitmapFrame raised these events. The links up the chain do not. They also do not listen to the link down the chain, so they are not even aware that the download completed.

As a result, any images that use the chain show as blank.

After the change, the DownloadCompleted, DownloadFailed, and DownloadProgress events will propagate down the chain. That is, the BitmapFrame will fire DownloadCompleted, then the FCB will fire

DownloadCompleted, then the CrB will fire DownloadCompleted, and finally the TB will fire

DownloadCompleted. The propagating event also causes each link in the chain to update with the downloaded image data, so images that use the chain will now work.


Without the new behavior, chained BitmapSource objects would not update/display correctly, preventing the chaining scenario from working.

Title

The Application.Exit event was not fired when the user’s session was ending

Description

When the session ends (user logoff or shutdown), Application.SessionEnding is raised, while

Application.Exit was not. This behavior was unexpected: irrespective of how an application is shutdown, the application always exits and, consequently, Application.Exit should have been fired. With this fix

Application.Exit is fired if there isn’t a handler for the SessionEnding event.


The old behavior was unexpected and confusing, and could lead to an application not shutting down correctly.

Title

Changing WindowStyle when AllowsTransparency=“True” was not consistently blocked

Description

WindowStyle.None is the only supported WindowStyle when AllowsTransparency=“True”. The

AllowsTransparency feature is implemented using the WS_EX_LAYERED style on the HWND and has strange interactions with the standard window chrome, so to minimize confusion we only support it when the chrome is removed. This style can’t be changed after the Window has been shown and there are several core functions (specifically those that are used when changing the visibility of the Window) that verify that AllowsTransparency implies the WindowStyle is “None”.

When the Window is hidden the checking of this invariant was delayed until the Window was shown again. The old implementation allowed the WindowStyle to be changed while the Window was minimized, and then an exception was thrown when the WindowState was changed to something that makes the Window visible. With this change, WPF enforces the contract, so an exception is thrown when the program initially sets the WindowStyle to an invalid value.


The previous behavior was inconsistent and confusing, and could lead to exceptions being thrown at unexpected times.

Title

The Frame control threw an exception if there was a syntax error (XamlParseException), rather that firing the NavigationFailed event

Description

The Frame control threw an exception if there was a syntax error (XamlParseException) in a XAML file that was being loaded. The Frame control includes a “NavigationFailed” event, but this was only raised when the XAML file could not be accessed. It is a natural expectation for the NavigationFailed event to also be raised when the XAML files cannot be parsed, instead of the old behavior. Since navigation is asynchronous it is difficult for applications to work around this behavior, and it’s not clear to developers whether the Frame control is still usable since the exception has gone unhandled by the framework.


The previous behavior was inconsistent and confusing, and could lead to an unhandled exception.

Title

Removed a redundant layout when Page.ShowNavigationUI=”False”

Description

Setting ShowNavigationUI to false causes the navigation chrome to be hidden for a page. The old behavior caused the window to be shown before this property has been applied, so it flashed on the screen with the chrome visible and a white screen where the content should be rendered. It was

correctable by delaying the call to Window.Show until after the navigation is completed, removing a second call that invoked a layout.


The old behavior made applications re-layout unnecessarily, and the new behavior still performs a layout correctly when the page has finished navigating.

Title

Changes to how Controls change the value of their own properties so that templates, styles, trigger, values, etc are not affected after the value changes

Description

We have changed the way a control (or any DependencyObject) changes the value of its own properties, when it needs to do so as a side-effect of some other action. Compared to previous versions of WPF, you will see the same value after the control’s change, but perhaps a different ValueSource (if you use the debugging helper DependencyPropertyHelper.GetValueSource). If your app has declared other sources for the affected property – templates, styles, triggers, data-binding, etc. – these will now continue to work after the control’s change, whereas in the previous version they stopped working.

For example, when a user clicks on a RadioButton, the control needs to set IsClicked to false on all the other RadioButtons in its group. In the previous version, this discarded the data binding the app declared on the IsClicked property, while in this version, the data binding continues to work.

Apps that depend only on the values of properties should continue to work without change. They may see new property changes due to triggers, data binding, etc. that were formerly disabled by the control’s property change.


The previous behavior was confusing and difficult to debug.

Title

Change for input routing in XBAP to achieve parity with standalone WPF apps

Description

In the previous version, if a customer was hosting a control in an HwndHost (most common scenarios are Winforms or WebBrowser/Frame) inside a WPF Browser Application (.xbap), the hosted control could get the first chance to handle input and thus block the browser application from receiving certain input, now the browser application will receive the first chance at input. If the browser application does not set the routed input event to “Handled”, the HwndHost-ed control will be able to handle it as before. This is in line with the behavior already seen for standalone WPF applications today.


This change is consistent with how desktop WPF applications work and also improves the experience for customers using IMEs.

Title

Linked resources outside of the project hierarchy will now be compiled with the correct IDs

Description

There has been a bug in how WPF compiles resources when the project uses the “Link” feature of Visual

Studio or Expression Blend. When the linked resources are compiled they’ll get resource IDs that are inconsistent with the way they would have if they were actually in the project’s hierarchy. We’ve fixed this because it greatly limits how projects can organize their assets. This will not break applications that have already been compiled and are working, but if you’ve worked around this (by adjusting your resource loading paths to take these inconsistencies into account) and recompile your app against the new framework then your resources will not be found with the same IDs. To fix this you’ll have to undo your original workaround.


The previous behavior was confusing and made resource linking difficult.

Title

WPF UIA handles virtualized elements better now

Description

WPF now takes advantage of virtualization in UIA (when present, such as on Windows 7). This means some calls that used to return all items in a list will now only return the de-virtualized items.


This behavior is more consistent with what most UIA clients want and enables improved performance by respecting virtualization.

Title

Any project building WPF automation peers may need to add a new reference to an assembly when built against .NET Framework 4

Description

In .NET Framework 4, we added three new provider interfaces to UIAutomationProvider called

ISynchronizedInputProvider, ItemContainerProvider and VirtualizedItemProvider. These implement new automation features. ISynchronizedInputProvider is implemented in UIElementAutomationPeer, a base type in PresentationCore.dll. ItemContainerProvider and VirtualizedItemProvider are implemented by

ItemsContainerAutomationPeer and ItemAutomationPeer, respectively. Because some of the automation peers now implement these additional interfaces, a WPF application using any of these peers must explicitly reference UIAutomationProvider.dll, or building the project will fail with an error.

The peers affected are listed in the table below.

Peer type

ButtonBaseAutomationPeer

ContentTextAutomationPeer

ContextMenuAutomationPeer

Additional Interfaces implemented in 4.0

ISynchronizedInputProvider



DocumentPageViewAutomationPeer

DocumentViewerAutomationPeer

DocumentViewerBaseAutomationPeer

FixedPageAutomationPeer

FlowDocumentPageViewerAutomationPeer

FrameAutomationPeer

FrameworkContentElementAutomationPeer

FrameworkElementAutomationPeer

GridViewHeaderRowPresenterAutomationPeer

GroupBoxAutomationPeer

GroupItemAutomationPeer

ImageAutomationPeer

InkCanvasAutomationPeer

InkPresenterAutomationPeer

ItemAutomationPeer

ItemsControlAutomationPeer

LabelAutomationPeer

MediaElementAutomationPeer

MenuAutomationPeer

SeparatorAutomationPeer

StatusBarAutomationPeer

StatusBarItemAutomationPeer

TextAutomationPeer

TextBlockAutomationPeer

TextElementAutomationPeer

ThumbAutomationPeer

ToolBarAutomationPeer

ToolTipAutomationPeer

UserControlAutomationPeer

Viewport3DAutomationPeer

WindowAutomationPeer















ISynchronizedInputProvider,

VirtualizedItemProvider

ISynchronizedInputProvider,

ItemContainerprovider

















Adding these new interfaces enable new features for UI automation in WPF.

Title

Changing the InputBinding class to enable Model-View-View Model scenarios

Description

The InputBinding class now derives from Freezable instead of DependencyProperty. Also, the Command,

CommandParameter and CommandTarget properties of the InputBinding class are now

DependencyProperty objects. Therefore, you can’t access instance level InputBindings from multiple threads (due to the restrictions of the DependencyObject class) and you can’t mutate class level input bindings after their registration (due to the restrictions of the Freezable class).


This change enables Model-View-View Model scenarios. On existing bits there is no way to specify input bindings on command instances which are created in a ViewModel. This is one of the major hurdles for development of seamless MVVM-centric applications. This feature bridges this gap by providing a mechanism to bind ViewModel-based command instances to View-based input gestures.

Title

Fixing MenuItemAutomationPeer to return non-MenuItem objects

Description

MenuItemAutomationPeer only returned MenuItem objects, not other UIElement-typed children in the

MenuItem. This prevented UI automation from working correctly when menus did not have menu item children in them. The GetChildrenCore method of the MenuItem class has been fixed to return non-

MenuItem objects.


This change enables UI automation of menus that contain children other than MenuItem objects.

Title

Fixing a bug when activating an element that had been re-parented

Description

If an element with logical focus was re-parented from one window to another, the original owner window remembered the element as its focused element. When, later, the original window was activated, it restored focus to the element which moved. As a result, the original owner window couldn’t be reactivated. This change will prevent focus restoration if the candidate is not a child of the window.


This fixes a bug which prevented a window from being activated when receiving focus.

Title

Merged dictionaries in theme-level resource dictionaries are now always frozen

Description

Merged dictionaries in theme level resource dictionaries were not always flagged as theme dictionaries, so Freezables objects in them were not always frozen. This change would fix it so that all values from

ResourceDictionaries and their MergedDictionaries at the theme level will be frozen if possible regardless of when they are created; where before only those values that were directly in the outer

(non-merged dictionary) theme level dictionary were guaranteed to be frozen. If you try to change a freezable object in the resource dictionary, you will now get an InvalidOperationException.


This change improves the robustness of theme-wide resource dictionaries by preventing them from being changed after creation.

Title

Template changes to enable clear type text in WPF Popups

Description

This involves changing the structure of the default templates for Popup based controls in WPF to include a Grid element that can render a solid background and hence enable ClearType text for such controls.

Here’s sample markup illustrating the change.

Before

< Popup >

...

< ScrollViewer >

< ItemsPresenter />

</ ScrollViewer >

...

</ Popup >

After

< Popup >

...

< ScrollViewer >

< Grid

Background = " {StaticResource someBrush} "

RenderOptions.ClearType

= " Enabled " >

< ItemsPresenter />

</ Grid >


This change allows enabling of ClearType text for popup controls.

Title

Some WPF windows interacted poorly with the Windows 7 windows manager

Description

The previous behavior of WPF windows as seen by the user:



Right-clicking the taskbar to Stack/Cascade/Tile windows will cause them to move, but a subsequent maximize or minimize will cause them to restore to the location before the move.



On Win7, dragging a window to the top of a monitor to maximize will cause it to restore at (0,0).



On Win7, docking a window will cause it to restore to the docked position at the restored size.

The previous behavior of WPF windows as seen by the application:



Any external force moving the window via the moral equivalent of SetWindowPos will not update WPF's properties for Top/Left/Width/Height.



Attempting to set a value for Top/Left/Width/Height through a style will not work if the user has interacted with the window in a way that has affected its position or size.



Attempting to set the values of Top/Left/Width/Height while in a non-restored state have no observable effect and can cause the window to move erratically compared to expectations.

After this change, WPF has the following behavior:



Win7 dock states and gestures states now work as expected based on user interactions.



External pushes such as Explorer Stack/Cascade/Tile now work and update the appropriate properties.



Win7 vertically-maximized windows appear as though they are normal windows so far as

Window properties are concerned.



Top/Left/Width/Height for maximized and minimized windows now reflect the restore location of the window, rather than sentinel values or bounds based on the monitor.



Values on Top/Left/Width/Height, such as bindings, set on the Window through styles will not work.


This allows WPF to work better with Windows 7.

Title

Attributes in XAML with more than one period no longer work in .NET Framework 4

Description

When loaded with XamlReader.Load(), XAML with more than one period will no longer parse.

Button Background Example:



<Button Background=”Red” /> has and always will work



<Button Button.Background=”Red” /> has and always will work



<Button Controls.Button.Background=”Red” /> worked in v3 since “System.Windows” + “.” +

“Controls.Button” finds a type.



<Button System.Windows.Controls.Button.Background=”Red” /> never worked, and never will.

AutomationId Example:





<Button AutomationProperties.AutomationId=”Foo” /> has and always will work

<Button Automation.AutomationProperties.AutomationId=”Foo” /> worked in v3 since

“System.Windows” + “.” + “Automation.AutomationProperties” finds a type.


The previous behavior was unintentional and inconsistent.

XML

Title

Changing NullRefenceExceptions to useful exceptions in XML-related classes

Description



XslCompiledTransform used to throw a NullReferenceException in some cases when loading a stylesheet.



XmlNode.set_Inner text used to throw a NullReferenceException is some cases.



XmlValidatingReader used to throw a NullReferenceException when some arguments to its constructor were null.

All of these have been changed to throw useful exceptions.


The NullReferenceExceptions made it very difficult to figure out what was happening under these conditions. Throwing useful exceptions makes it much easier for customers to debug their code.

Title

XmlWriter.Dispose no longer swallows all exceptions

Description

Xml.Writer.Dispose used to swallow all exceptions (including exceptions that should not be caught, such as OutOfMemoryException). It has been changed to throw exceptions that are symptoms of bigger bugs or other major problems in the process.


The old behavior of XmlWriter.Dispose could hide major problems and make it much harder to debug those problems. This changes the behavior to be more debuggable/diagnosable.

Title

Chameleon schemas are now cloned correctly when included by multiple schemas

Description

Chameleon schemas are schemas that don't have a target namespace, and when they are included in another XSD, they take on the target namespace of the importing schema. They are often used to include common types into a schema. If two schemas are in a XmlSchemaSet, and both schemas include the chameleon schema, the chameleon schema is not cloned correctly into both schemas. This then causes XML validation to change, either failure or passing when they shouldn't. This change fixes the incorrect cloning.


The incorrect behavior in previous versions could lead to documents passing validation when they should not, or not passing when they should. This could lead to data corruption.

Title

Fix XsdValidatingReader.MoveToNextAttribute() to work correctly after a call to MoveToAttribute(int i)

Description

The problem was in XsdValidatingReader.MoveToAttribute(int i). Once MoveToAttribute(int i) was called, MoveToNextAttribute() wouldn’t work anymore since the current attribute index was never updated with the value of i. In this version, MoveToNextAttribute() will now work correctly after a call to

MoveToAttribute(int i). This only affects XsdValidatingReader.


The previous behavior prevents polymorphism from working when using different subclasses of

XsdReader are used.

Title

XmlReader.ReadContentAs has been changed to no longer ignore an IXmlNamespaceResolver passed in

Description

This problem was in the XmlReader.ReadContentAs overload that accepts a IXmlNamespaceResolver.

The passed in namespace resolver was ignored, and instead the XmlReader was used for the namespace resolver. After this change, the passed in IXmlNamespaceResolver is no longer ignored.


The previous behavior blocked some common scenarios. Making this fix does not break the most widely used workarounds.

Title

The function-available() XSLT function didn’t work on script functions if the script function was never called

Description

The function-available() method is used to determine if a function with a particular name is available for use. In previous versions, if the function was not actually called in the XSLT, this method always returned false, even if the function was available. With this change, function-available() works correctly. This same bug was present and fixed in MSXML3 SP1.


This behavior affected common scenarios with no reasonable workaround.

Title

Dependency bugs in XmlSchemaSet have been fixed

Description

The XmlSchemaSet allows for XSD schemas to be compiled. These schemas can include each other schemas - for example, A.xsd can include B.xsd which can include C.xsd. Compiling any of these causes this graph of dependencies to be walked. The bugs fixed relate to when a schema in the set is modified, and a dependant schema is recompiled/reprocessed. In these cases, the graph of schemas is not correctly walked, leading to inconsistent compiled schemas.


The old behavior could lead to data passing schema validation when it shouldn’t, or not passing when it should, potentially leading to data corruption.

Title

XmlReader.Create returned a reader that causes incorrect discarding of significant whitespace

Description

XML validation recognizes a mixed content mode, where text can be intermixed with XML markup. In mixed mode, all whitespace is significant and should be reported. The XsdValidatingReader had a bug such that it will report significant whitespace as non-significant.


The old behavior could result in data loss when the data is loaded to an XmlDocument or

XDocument/XElement which is stripping non-significant white space by default.

Title

Wrapping XmlWriters did not respect NewLineHandling.None

Description

If a user created a wrapping XmlWriter (an XmlWriter that writes to another XmlWriter) and specified that the wrapping XmlWriter has NewLineHandling.None, when the user used the WriteChars method, and the content contained /r/n, the output would contain /r/n/r/n.

There are two common scenarios that were impacted by the bug.

The first was serialization, where a user has an existing XmlWriter created from an XmlSerializer, and then needed to then wrap that writer. If the consumer of the generated XML was not whitespace tolerant (for example, a third party web service), then problems could occur.

The other common scenario that was impacted is where the user wants to use an XmlWriter to insert content into an existing XmlDocument or XDocument. With this bug, the user could not correctly normalize newlines on content added to the document.

With this fix, NewLineHandling.None has the correct behavior for a wrapping writer.


The old behavior could cause data corruption.

Title

In the XmlWriter, Entity Refs were entitized twice in xml attributes

Description

If the user attempted to write an Entity into an xmlns attribute or into an xml:lang or xml:space attribute using the XmlWriter.WriteEntityRef, the entity was entitized twice in the output, thus corrupting the data.

XmlWriter w = XmlWriter.Create(Console.Out); w.WriteDocType("root", null, null, "<!ENTITY e \"en-us\">"); w.WriteStartElement("root"); w.WriteStartAttribute("xml", "lang", null); w.WriteEntityRef("e"); w.WriteEndAttribute(); w.WriteEndElement(); w.Close();

Output:

<!DOCTYPE root [<!ENTITY e "en-us">]><root xml:lang="&e;" \>

Expected:

<!DOCTYPE root [<!ENTITY e "en-us">]><root xml:lang="&e;" \>

After this change, the entity is not entitized twice.



Title

The XmlReader-returned XNode.CreateReader function returns the correct BaseURI

Description

If the user created an XmlReader from a LINQ to XML class by using the CreateReader function, the reader did not return the correct BaseURI until the Read function was called at least once. As a result, code depending on the value of the BaseURI prior to the first Read method call would change after the

Read function was called, either directly from user code or from another call, like passing the XmlReader to another method.


The old behavior was incompatible with the XamlReader.Load function, meaning that it was blocking the use of LINQ to XML for creating Xaml.

Title

When using XSLT with LINQ To XML, the XSLT id function returns the correct value

Description

If the user created a XmlReader from a LINQ to XML class by using the CreateReader function, and this

XmlReader was passed to an XSLT, any instances of the id function in the XSLT would previously return null. This is not an allowed return value for the id function, but any code that did depend on the value of id being null would need to be changed.



Title

DocumentXPathNavigator correctly reports local name of attribute "x:xmlns"

Description

DocumentXPathNavigator would incorrectly return an empty string for the local name of the x:xmlns attribute. The local name is now returned correctly, enabling XSLTs and code that generates other XSLTs or documents that return the use of x:xmlns.


The old behavior could cause data corruption and prevent using XSLT to generate XSLTs in certain circumstances.

Title

XsltReader in combination with XmlReader on a sub-tree no longer causes creation of duplicate namespace declarations within one XML element

Description

When reading an XSLT with an XsltReader, if an XmlReader was layed on the XsltReader, the resulting

Xml element would contain duplicate namespace declarations, which is invalid XML, and could cause problems with strict XML processors. This has been fixed.


The old behavior could cause data corruption and prevent the creation of valid XML from the

XmlReader.

Data

Title

Changing non-useful exceptions to useful exceptions in ADO .NET Data Services-related classes

Description



The ADO.NET Data Services client supports a timeout property to timeout async calls to a data service. If a call times out, when the associated End* method is called a NullReferenceException is thrown instead the appropriate exception time signaling the timeout occurred.



In IDataServiceConfiguration, set MaxBatchCount and ChangeSet count to 0. Issue a $batch request - a 400 (BadRequest) status code should be returned via a

DataServiceRequestException. Instead a NullReferenceException is thrown leaving the client no indication of what went happened (success, failure, endpoint not callable, etc).



The way an ADO.NET Data Service author controls the error message sent back to a client is via throwing a DataServiceException from the plugin points in the processing pipeline (known as

"interceptors"). The sole purpose of this exception type is to control the error payload. At present when this exception is thrown, the data does not make it back to the client (it is swallowed).

All of these cases have been changed to allow meaningful exceptions to be thrown, or to propagate exceptions correctly.


The NullReferenceExceptions made it very difficult to figure out what was happening under these conditions. Throwing useful exceptions makes it much easier for customers to debug their code.

Title

ADO .NET Data Services incorrectly deletes a reference between objects.

Description

If the client library is tracking an object which is associated with 1 or more additional objects (i.e., a

Customer object contains a collection of Order objects) then trying to Delete an Order object fails as the library also mistakenly tries to delete the references between the objects. Since the caller has only

specified the entity should be in the deleted state, this issue leads to corrupting the current state in the local state manager. This corrupted state leads to erroneous DELETE requests sent to the data service on the next call to the SaveChanges( ) method.


The old behavior can result in data corruption.

Title

In SqlCommand.Prepare, a NullReferenceException was thrown if no SqlConnection was set

Description

In previous versions SqlCommand.Prepare would throw a NullReferenceException if no SqlConnection had been set. In this version, an InvalidOperationException with diagnostic information is now thrown instead.


The NullReferenceException made it difficult to diagnose what was happening in this scenario.

Title

Entity Framework function overload resolution logic resolved ambiguous functions incorrectly

Description

The function overload resolution algorithm used by the Entity SQL and LINQ to Entities frontends of the

Entity Framework fails to detect certain cases of ambiguity and as a result may resolve to an ambiguous overload.

Example:

Overloads:

String Foo(Int16, Int64) // overload 1

String Foo(Int64, Int32) // overload 2

Query:

“select Foo(x.Int16Value1, x.Int16Value2) from Customers as x”

In this case previous algorithm would determine that overload 1 is better than overload 2 and resolve to it. However, overload 1 is not uniformly better than overload 2, hence the case is ambiguous and ambiguity error should have been thrown. The change is to add the check of the winning overload for ambiguity against all other overloads. The new check will make sure that the winning overload is uniformly better than any other overload.


The previous logic could result in confusing behavior when resolving functions with overloads. The new behavior much more closely matches languages like Visual Basic .NET and C#.

Title

In LINQ to Entities, a GroupBy with null key over an empty collection had inconsistent behavior

Description

In the previous version, GroupBy with a null key over an empty collection would return a different number of rows depending on whether an additional select to perform aggregation over the group elements was specified. In particular, no rows were returned if there was no additional select on top of the GroupBy to perform aggregation, and 1 row (containing null) if there was an additional select.

Example:

ObjectQuery<TestFailure> testFailures = … //an empty collection var query1 = testFailures.GroupBy(c => (int?)null) //returns 0 rows var query2 = testFailures.GroupBy(c => (int?)null).Select(g => g.Max(tf => tf.Comment));

//returns 1 row

With the change, GroupBy queries will return no row regardless of the presence of the aggregation.


Previous behavior made it difficult to check for zero results and was confusing.

Title

In LINQ to SQL, fix the case where ListChanged doesn’t fire when EntitySet is unloaded

Description

In LINQ to SQL, we fixed a bug in the code that fires the ListChanged event in EntitySet<T>. Previously,

ListChanged was fired in Add and Remove operations only if the EntitySet was loaded. This is not the expected behavior that users normally expect with this type of event, and is not how we document this specific event on EntitySet. In this version, we always fire the event in the same scenarios it is already fired, but also do so even if the EntitySet is not already loaded.


The current behavior is inconsistent and make it difficult for customers to write business logic that depends on this event, given that the event did not always fire when expected.

Title

In the Entity Framework, ObjectContext.Detach could lead to unexpected exceptions being thrown when SaveChanges is called

Description

The intent of the ObjectContext.Detach() method is to detach an entity and all relationships that do not participate in a 0..1 or 1 cardinality relationship with the entity to be detached. In the previous version of the Entity Framework, Detach did not detach relationship entries that were in the deleted state in the case where the detached entity’s ObjectStateEntry is degrade to a key entry. This could lead to a corrupt

ObjectStateManager that could lead to an exception during SaveChanges. This change is to correct the behavior of Detach to also detach these deleted relationship entries.


This change improves the consistency of the Detach method and prevents unexpected exceptions from being thrown during subsequent SaveChanges calls. The previous behavior was incorrect to leave the relationship in the deleted state. This change also creates parity between the Detach method and the expected behavior of the ChangeObjectState(…, EntityState.Detached) method.

Title

Changing a NullReferenceException at runtime to a useful error at design time when mapping queries

Description

In the previous version, we threw a NullReferenceException at runtime during the materialization of a query for a negative case in user specified query view mapping. The scenario could only occur if there were multiple entity sets per type and one entity set was bound to an end of an AssociationSet in CSDL.

But in mapping, the other EntitySet for the same type was used to create the ref used in constructing the AssociationType, leading to a NullReferenceException.

The fix is to add a visitor that visits the view expression and validates that there are no mismatches between the EntitySets used in the RefExpressions in MSL and the EntitySet used in the

AssociationSetEnd of the customer. For invalid mappings, this will return a mapping error at design time instead of a NullReferenceException at runtime.


The previous behavior caused a runtime error for a situation that should have been caught at design/development time.

Title

Mapping validation did not catch a data loss scenario where two AssociationSets are mapped to the same columns

Description

Our mapping validation did not flag the following scenario as an error in the previous version. The scenario is as follows: Two 1:* association sets in the conceptual side between same two EntitySets are mapped to the same columns in the database. The update view picks one of the AssociationSet’s mappings when producing the FK column and ignores the other mapping. The fix is to change the validation code to compare the AssociationEndMembers instead of the Key members of the EntityTypes for the Ends. The fix would result in a mapping error at design time.


The previous behavior could result in data loss and was also very difficult to diagnose or debug.

Title

Structural annotations are now recognized in the Entity Framework

Description

In CSDL v 1.0 / v1.1 it is possible to include duplicate annotations:

<Property Name="Firstname" Type="String">

<security:ACE principal="UserX" permission="15|0"/>

<security:ACE principal="UserY" permission="0|15"/>

</Property>

These annotations are completely ignored by the Metadata APIs in the previous version.

In this version, this is no longer possible because the annotation is now made available in the

MetadataItem.MetadataProperties collection as an XElement keyed on the namespace qualified element name. Therefore, in this version, colliding names in schemas are not allowed, as this would result in colliding keys.


This allows better typing for structural annotations, and getting this behavior requires opting-in to the new schema in this version.

Title

The IRelatedEnd interface has been changed to enable better POCO support

Description

We have added new methods the existing IRelatedEnd interface to improve its usability in Plain Old CLR

Object (POCO) scenarios. The new methods take Objects instead of IEntityWithRelationships.


Adding support for POCO entities is a common customer request. Customers are not expected to have implemented IRelatedEnd.

Title

Entity Services change for resolving multipart identifiers in eSQL

Description

In the previous version, when the eSQL parser attempted to resolve a multipart identifier (e.g. c.Name) it first tried to scope entry with the name “c.Name” rather resolving to “c”.

Example: The following query select c.Name from Customers as c, c.Orders as [c.Name]

Would project Order instead of customer name.

This was caused by the bug in the multipart identifier resolution logic that at first tries to resolve multipart identifier by building a whole string "c.Name" and then searching available scope entries with the same name. The "c.Orders as [c.Name]" in the FROM created an entry that would match the test, so

"c.Name" bound to "[c.Name]" which was a bug. Expected behavior is to match to "c" first and then resolve property chain ".Name" which would give customer name expression.

With this fixed behavior, in the following query c.Name identifier would be resolved to Customer’s

Name: select c.Name from Customers as c, c.Orders as [c.Name]


The previous behavior was confusing and could lead to unexpected and difficult to debug program behavior.

Title

The escape character ‘\’ was being ignored by the JSON reader

Description

When JSON payloads are sent to an ADO .NET Data Service, the payloads are processed by a JSON reader and character escaping is performed. In the previous version of the JSON reader, the single character ‘\’ is being ignored. The JSON reader should error when it encounters the single ‘\’ character.

Example:

For JSON, the character sequence ‘\a’ is currently processed as ‘a’. The correct behavior is for the reader to throw an exception and the server to respond to the client with “400 – Bad Request”. After this fix, the

JSON reader does respond with a “400 – Bad Request” when this character is encountered.


The previous behavior was not standards compliant and could lead to data corruption.

Title

Fixing incorrect escaping of URIs in the ADO .NET Data Services client

Description

The ADO .NET Data Services client did not escape data values in a URI before sending it to the server.

This caused the server to error because the URI parser on the server would try to escape the values.

For a data value ‘lon+don’, the client should escape the ‘+’ character. Because it was not correctly escaping the character, the client sends the following request which fails on the server: http://.../customers?filter=name eq ‘lon+don’

It should have sent (after escaping the ‘+’ character): http://.../customers?filter name eq ‘lon%2Bdon’

After this change, the client escapes characters correctly.


The old behavior had no workaround and prevented customers from sending data that needed to be escaped.

Title

ADO .NET Data Services incorrectly accepts an empty eTag header for a PUT operation that is updating a property value which requires an eTag header

Description

ADO.NET Data Services support optimistic concurrency to enable detection of update conflicts by leveraging HTTP/1.1 features including persistent caches, various if-* precondition headers and the eTag response header. An eTag (entity tag) is an HTTP response header returned by an HTTP/1.1 compliant web server used to determine change in content at a given URL. The value of the header is an opaque string representing the state of the resource.

In HTTP an eTag value can be supplied in a response that contains a value used to denote the version (or state) of the resource being sent. When a request to modify that resource is later sent to the service, the request can contain an “If-Match” request header containing an ETag value that indicates the clients version of the resource that the modification is being applied to. If the ETag value is not specified, then the service should respond with 400 – “Bad Request”.

The following shows a request with an If-Match header and the corresponding eTag header in the response. This is an example of the previous incorrect behavior.

Request (note the missing if-match header):

PUT nw.svc/Categories(11)

Host: http://myservice

Accept: application/json

Content-Type: application/json

Content-Length: 33

{"CategoryName": "Updated Cat"}

Response:

HTTP/1.1 204 No Content

DataServiceVersion: 1.0;

ETag: W/"'Updated%20Cat'"

Content-Length: 0

…

After the fix, the service honors the eTag value on a PUT operation to a property value and rejects the operation when a required eTag value is not specified.


The previous behavior could cause data corruption, as concurrency semantics were not being enforced by the service.

Title

ADO .NET Data Services server sometimes closed an underlying stream incorrectly

Description

The ADO .NET Data Services server sometimes closed the underlying stream after reading a request payload or writing a response stream. This is a problem when the underlying stream is owned by the host and is relying on the stream still being open for post-processing.

The Service did not always close the stream. The following table shows the scenarios and when the service closed the stream and when it doesn’t. The server was consistent in always closing the stream when reading but only sometimes closes it when writing. It should never close it.

Closes

Stream?

Reading

Request

Writing

JSON Formatted

Stream

Always

Always

Atom Formatted

Stream

Always

Never

XML Formatted

Stream

Always

Never

Response

After this fix, the server never closes the underlying stream.

Stream Containing a

Batch

Always

Never


The previous behavior was inconsistent across scenarios and prevented hosts from processing the stream themselves.

Title

ADO .NET Data Services server ignored the clients requested format for a response when returning an error

Description

When an ADO .NET Data Services client makes a request to the ADO .NET Data Services service, the request’s HTTP headers include an “Accept” header that indicates the response format that the client wants the server to respond with (this format can be JSON, ATOM, or XML).

When the a query parameter name of a query string of a request received by the server has an error the server responded with an XML formatted response, regardless of the format specified in the Accept header of the request.

Example:

A request is issued for the URI: "../Services/ImagesDataService.svc/Images?$ttop=20". Note the spelling error in the query parameter name “top”.

The header of the request are:

_ headers {...} Object

Accept "application/json" String

DataServiceVersion "1.0;AspNetAjax" String

MaxDataServiceVersion "1.0;" String

The server will respond with (In XML format):

<?xml version="1.0" encoding="utf-8" standalone="yes"?>

<error xmlns="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata">

<code></code>

<message xml:lang="en-US">Message: The query parameter '$ttop' begins with a systemreserved '$' character but is not recognized.</message>

</error>

After this fix, the server will return the error to the client in the format it requested.


The previous behavior always required users to handle errors in XML, rather than their preferred format.

Title

Skip(0) without OrderBy should throw on SQL 2000

Description

In some cases with LINQ to SQL (particularly against SQL Server 2000), Skip cannot be used without first explicitly ordering the results. Previously, Skip(0) was optimized out of queries and so in those cases, the user could get away without ordering even though it would normally have been required.

In this version, the query optimization changed to no longer optimize out the Skip(0). The end result is that now the query correctly includes Skip as the user requested, and thus in scenarios where ordering is required, if the user did not specify an order, an exception occurs where previously it did not.

Note that in the scenarios where users are affected by this change, as soon as the user executed a query with Skip(x) where x is greater than 0, the same exception would have occurred previously, as it does now. The typical pattern of using Skip would be to use Skip(0) for the first page of data, then to call it again with a value greater than 0, so the majority of users who could be affected by this will already be using OrderBy in their queries anyway, and thus will not see a change in behavior due to this.


The previous behavior was inconsistent and this change was necessary for improvements in query optimization.

Title

MergeOption.PreserveChanges behaved incorrectly in some scenarios

Description

In the previous version, the behavior of querying with PreserveChanges MergeOption is inconsistent between dynamic SQL and stored procedure based updates. Additionally, the behavior for dynamic SQL causes a merge of entity values on the client which can be construed as data corruption. In this version, the default behavior of PreserveChanges queries to be the same as LINQ to SQL’s KeepCurrentValues refresh mode and Entity Framework’s ClientWins refresh mode, which consist of preserving the whole entity if it contains changes.


The previous behavior could lead to data corruption.

Title

Changes in identifier resolution rules in Entity-SQL

Description

In .NET Framework 3.5 SP1, the identifier resolution rules in Entity-SQL (eSQL) were not well defined. As we added more features to eSQL in .NET Framework 4, such as Model Defined Functions, that it became important for eSQL to define very specific scoping rules for identifier resolution. This change would make identifier resolution rules consistent for all classifications of identifiers (types, functions, etc). Also, in .NET Framework 3.5 SP1, eSQL did not support resolving multipart identifiers, which was confusing because it was very different from the identifier rules defined in most other languages. In .NET

Framework 4, eSQL will start supporting multipart identifiers.

In summary, the changes mostly affect the following two .NET Framework 3.5 SP1 scenarios.

Case 1: using f=A.B; treat(null as f.C.D)

.NET Framework 3.5 SP1 behavior: eSQL tries to resolve “f.C.D” as “f.C.D”, fails and reports an error message stating that “f.C.D” is not defined.

.NET Framework 4.0 behavior: eSQL tries to resolve “f.C.D” as “A.B.C.D”. If resolution fails, the “A.B.C.D is not defined” error reported.

Case 2: using A.B; treat(null as C.D)

.NET Framework 3.5 SP1 behavior: eSQL resolves as C.D, then as A.B.C.D

.NET Framework 4.0 behavior: eSQL tries to resolve “C.D” as “C.D”, fails and reports an error message stating that “C.D” is not defined.

Overall, the rules changes are summarized as follows:

1) Local definitions shadow global definitions: a.

Resolution unambiguously prefers local definitions to global definitions. b.

Resolution is successful if it binds to a local definition even if it can also bind to a global definition.

2) Namespace alias expansion: a.

Performed only for multi-part identifiers. b.

Produces a fully qualified name.

3) Multi-part names are not treated as partially qualified; hence they are not resolved within imported namespaces.


This change makes identifier resolution consistent in eSQL and reduces customer confusion, especially in light of new eSQL features in .NET Framework 4.

Title

Generated SQL in LINQ and Entity-SQL queries now treat string parameters as non-Unicode values by default

Description

By default, LINQ and Entity-SQL object queries treat string parameters as Unicode values. This is consistent with the CLR String type. When a string parameter is compared to a non-Unicode (e.g. varchar) column in SQL Server, the column is converted to nvarchar, due to data type precedence rules.

If we fail to leverage an existing index as a result of this conversion, there may be serious performance degradation.

In .NET Framework 4, the proposed fix is to convert string constants and parameters to non-Unicode format, if the comparison is with a non-Unicode column. We check all usages of the parameter in the query to check for feasibility, before performing the conversion. Also we do the conversion only where the format was not specified explicitly by the user.

Example query – var configs = from c in ctx.Employees where c.Name == "Peter" select c.Id;

The generated SQL was –

SELECT

[Extent1].[Id] AS [Id]

FROM [DataWorks].[ Employees] AS [Extent1]

WHERE N‘P ete r’ = [Extent1].[Name]

Now the generated SQL is –

SELECT

[Extent1].[Id] AS [Id]

FROM [DataWorks].[ Employees] AS [Extent1]

WHERE ‘P ete r’ = [Extent1].[Name]

Thus the constant is treated as non-unicode constant which causes the index on the column “Name” to be picked up by the server, resulting in substantial performance gain.

The result returned due to this change might be different in some cases. You can get the old behavior by modifying the query to - var configs = from c in ctx.Employees where c.Name == EntityFunctions.AsUnicode( "Pétér") select c.Id;


This change greatly improve performance in default scenarios.

Title

Fixing a bug that prevented batch binary content from working with ADO .NET Data Services

Description

A data service request or response can have multiple requests or responses embedded inside of it

(referred to as a “batch”). The individual request/responses are separated inside of the batch using a delimiter made of up the “\r\n” characters followed by “-- <batch identifier>”.

When one of the requests or responses contains binary content, the data service (or client) incorrectly read the “\r\n” characters as part of the binary content rather than as part of the delimiter. This behavior has been fixed. We no longer include the “\r\n” characters in the content.


This enables batched binary content to work correctly.

Title

Fixing a timing error for the OnStartProcessingRequest event in ADO .NET Data Services

Description

ADO.NET Data Services exposes an OnStartProcessingRequest event that should fire before a request to the Data Services is processed. The user can hook into that event and implement custom logic that executes before the request is processed. When the request is to a ServiceOperation, however, the event occured AFTER the request is processed rather than before. This behavior has been fixed so the event correctly firest before the request is processed.


This enables the OnStartRequestProcessing event to work correctly for ServiceOperation services.

Title

PropertyChanged events are now fired more often in some cases for DataSet rows

Description

We will now correctly raise the PropertyChanged event when a row is in a Modified state and

RejectChanges is called. This will cause more PropertyChanged events to be fired. These events were not being fired under these conditions in previous versions.


This change is being made to make it easier to write UI controls that expose the contents of the DataSet.

Title

Fixing the IndexOf method for the DataRowView being edited

Description

DataView's IList.IndexOf method always incorrectly returned -1 for DataRowView being edited. This behavior has been fixed so the correct value is returned.


This fix makes it possible to correctly determine the index of the row while the row is being edited.

Title

Change interceptors are now fired for a DELETE request to a link in ADO .NET Data Services

Description

ADO.NET Data Services supports defining change interceptors for entity sets. A change interceptor is a method that executes every time a request is received by the server to modify an entity in the entity set and executes before the incoming request is executed. The change interceptor gives access to the entity that is being changed and the operation that is being performed on it (Add, Change, Delete).

The issue is for requests to delete a link between two entities, change interceptors were not firing. For all other operations, the interceptor was executed correctly. (Links are relationships between entities such as the relationship from customers to orders). This behavior has been fixed so that change interceptors are fired correctly for delete requests.


This change allows request interceptors to work correctly in all cases.

Title

Fixing DELETE operations with concurrency tokens for ADO .NET Data Services

Description

ADO.NET Data Services does not support defining concurrency tokens on links between entities. When an If-Match or If-None-Match header (a.k.a. if-* headers) is supplied on an operation to a link, the

operation should fail and the service should return an error status code. For GET, PUT, POST, and

MERGE operations with an if-* header the service correctly returns an error response and does not execute the operation. For DELETE requests with an if-* header the server returns a success status and executes the operation. The fix is to modify the service to return an error and not execute the request for a delete request to a link when an if-* header in the request.


This makes the behavior consistent across all operations when concurrency tokens are involved.

Title

Fixing the AppendOnly merge option across responses for ADO .NET Data Services

Description

The ADO.NET Data Services client library has the concept of Merge policies that specify the behavior the client should use when an entity is received from the service that is already being managed by the client context. The expected behavior of the AppendOnly merge option is that once an entity has been materialized on the client it should never be modified due to processing any subsequent response from a data service. That said, this policy should NOT be applied within the processing of a single response

(i.e., it only applies across responses).

The behavior in previous versions is that the AppendOnly option is being applied within the same request. The problem with this is best shown using an example:

Example:

The example below shows an entity of type “Employee” that has an entity reference, named “Manager”, that refers to another entity of type “Employee”. Assume that the database backing the data service has the following Employee table:

2

3

EmployeeID Name

1 John

Joe

Mary

ManagerID

2

3

NULL

The response to an HTTP request to the URI “/Employees?$expand=Manager “ would look like:

<Employee>

<ID>1</ID>

<Name>John</Name>

<Manager>

<Employee>

<ID>2<ID>

<Name>Joe</Name>

</Employee>

</Manager>

</Employee>

<Employee>

<ID>2</ID>

<Name>Joe</Name>

<Manager>

<Employee>

<ID>3<ID>

<Name>Mary</Name>

</Employee>

</Manager>

</Employee>

<Employee>

<ID>3</ID>

<Name>Mary</Name>

</Manager>

</Employee>

During creation of Employee(1) on the client, Employee(2) is also created (and the “Name” property is set). This is done because Employee(2) is contained within the Employee(1) entry (as shown by the XML above). The issue is that with the AppendOnly merge options, after creating Employee(1), the client library moves to the next section of the feed, encounters Employee(2) which was already materialized during materialization of Employee(1), applies the AppendOnly merge option and skips Employee(2); the

AppendOnly merge option means that the client library should not edit an entity that already exists. The result of this is that the manager for Employee(2) is never set. The client should not be applying the merge option within the same response. The resulting state is:

Actual Resulting Client State Expected Resulting Client State

Employee(1)

Name = “John”

Manager = 2

Employee(2)

Name=”Joe”

Manager=null

Employee(3)

Name=”Mary”

Manager=null

Employee(1)

Name = “John”

Manager = 2

Employee(2)

Name=”Joe”

Manager=3

Employee(3)

Name=”Mary”

Manager=null


We made this change so that the AppendOnly merge option works as expected.

Title

Exception changes in implicit unbind scenarios for transactions

Description

If an application tries to execute a statement on a connection after a Transaction has been completed

(aborted or rolled back), an InvalidOperationException will now be thrown. Before this change no exception was thrown and you could execute additional commands even if a transaction is aborted.

Before this change, for “implicit unbind” scenarios, customers would have received either

System.Transactions.TransactionException or a subtype, and System.Data.SqlClient.SqlException, but now will hit an InvalidOperationException. This is the same type of exception is thrown in this same code path when using explicit unbind.


This change makes it clear when an operation fails due to a transaction already being completed (or aborted/rolled back).

ASP .NET

Title

ASP .NET output caching has been fixed

Description

ASP.NET 1.0 had a bug where output cached pages which specified <@OutputCache

Location="ServerAndClient" > accidentally emitted a Vary:* HTTP header in the response. This had the effect of telling client browsers to never cache the page locally. In ASP.NET 1.1, customers could use a new method (System.Web.HttpCachePolicy.SetOmitVaryStar) to suppress the Vary:* header. In this version, we’ve fixed the root problem by eliminating the Vary:* header from responses that specify

<@OutputCache Location="ServerAndClient" >.


This addresses customer feedback and reduces confusion by making <@OutputCache

Location="ServerAndClient" > work as expected.

Title

ASP .NET root web configuration file settings added in .NET Framework 3.5 and 3.5 SP1 have been moved to the machine configuration file

Description

The changes in configuration files include:

Machine.config:

The 4 machine.config will be updated to include configuration sections from 3.5:



The<sectionGroup /> definition for system.web.extensions (and child sections) will now be included.

Root web.config – system.web configuration sections:



The <compilation><assemblies /> section will include registrations for System.Core,

System.Web.Extensions, System.Data.DataSetExtensions and System.Xml.Linq.



The <pages><controls /> section will now include tagPrefix registrations for

System.Web.UI and System.Web.UI.WebControls that point to System.Web.Extensions.



The <httpHandlers /> section will include the ScriptResource.axd handler registration. o However the root web.config will not include any re-mapping of .asmx nor will it include the _AppService.axd mapping. Since these registrations change the behavior of .asmx and open up certain application services on a machine they should remain as Visual Studio per-project options that are added to individual application web.config files.



The <httpModules /> section will include the ScriptModule registration.



The <assemblyBinding /> redirects that support Atlas will not be included in web.config since Atlas was an OOB non-framework product. These redirects (assuming they even still make sense in a 4 application) will instead need to be maintained on a perapplication basis.

IIS applicationHost.config:



The <modules> section will now include the ScriptModule registration. I believe we can pre-condition the module registration to 4 only so it will have no effect on other pre-4 applications running on IIS7.



The <handlers /> section will now include the ScriptResource.axd handler registration.

As with the module, we should be able to pre-condition the handler registration to 4 only. o As with the 4 root web.config, the .asmx re-mappings and _AppService.axd mapping will not be included in applicationHost.config. Those mappings still need to occur at the application level.

When web projects are migrated to .NET Framework 4 in Visual Studio 2010, the web configuration files will be migrated as well. Also, the ASP .NET team plans to release a standalone migration tool on

Codeplex.


These changes allow the administration of these settings in a central place (the machine configuration file) rather than having to include them in each web configuration file. This change also simplifies and reduces the clutter in the default web configuration files.

Title

By default, ASP .NET controls in .NET Framework 4 will generate xHTML 1.1 compliant HTML

Description

As of .NET Framework 3.5 SP1, many of the controls in ASP.NET generate markup that is not xHTML 1.1 compliant and not accessible. The major problem is that some controls generate markup that the developer did not ask for and has no ability to disable. In many cases, this unnecessary markup was originally put in the product to make pages look better under legacy browsers which are no longer

relevant. Moving forward, the default experience for new websites should be to support the current browsers and standards.

This new rendering is enabled via an option in web.config:

<system.web>

< pages controlRenderingCompatibilityVersion = " 3.5|4.0

" />

</system.web>

For the .NET Framework 4, this option will default to being set to 4.0 to enable the new rendering. This is so new websites will automatically get the proper markup for current browsers and standards.

Websites migrated using Visual Studio 2010 will have the 3.5 setting enabled for compatibility.


This change enables xHTML 1.1 compliance for new websites.

Title

ASP.NET request validation triggers earlier in the request lifecycle

Description

In .NET Framework 4, ASP.NET request validation by default is turned on for all requests by enabling it very early in the lifecycle of an HTTP request. As a result request validation will run for non-.aspx page requests, including things like web service calls and custom handlers. Request validation will also be active when custom Http modules are running in the request processing pipeline.

Non-.aspx HTTP requests may start throwing request validation errors because the request validation feature is now active for all types of requests. Additionally, custom code running in the request pipeline

(e.g. custom Http modules) may also start throwing request validation errors.

Customers can revert to the old behavior of only having .aspx pages triggering request validation with the following setting in a web configuration file: <httpRuntime requestValidationMode="2.0" />.


This change enables more robust validation of requests for .NET Framework 4.

Title

The Browser Definition Files that drive the HttpBrowserCapabilities and MobileCapabilities classes have been updated to represent information on more recent browsers

Description

The Browser Definition Files that drive the HttpBrowserCapabilities and MobileCapabilities classes included with ASP.NET 3.5 contained extremely outdated information about browsers and devices. They did not contain information on recently introduced desktop browsers such as Chrome. Furthermore, the files contained information on dozens of outdated and no longer used mobile devices.

The original set of browser definition files contained 463 definitions in 23 files. The updated browser definition files contain 31 browser definitions in 8 files.


This change brings the browser definition files up-to-date for current browsers.

WCF Services

Title

Behavior merging across config files is now supported

Description

In .NET 3.5, WCF services relied on a configuration inheritance model to allow the users to define bindings that could be used in any WCF configuration file in the machine. In .NET 4, we are expanding that configuration inheritance model to allow the users to define behaviors that will be applied to all the services in the machine.

Due to the behaviors nature (behaviors are collections, bindings are not), we will merge all the behaviors defined in the behaviors collections that are under the same name. Tthe scenario we are addressing here is to add additional behaviors to those defined higher in hierarchy for a particular service.

You may encounter behavior changes if there are behaviors with the same name at different levels of the hierarchy.


This change enables inheritance of behaviors through the configuration file hierarchy.

Title

ServiceHostingEnvironment can’t be defined at the service level in .NET Framework 4

Description

In 3.5 it was possible to specify the ServiceHostingEnvironment section at the service, application, and machine levels. However, being able to specify the ServiceHostingEnvironment section at the service level is technically incorrect and results in inconsistent behavior; when multiple

ServiceHostingEnvironment sections are specified in different services, the application settings which are applied are determined by which of those services are activated first. This fix removes the ability to specify the ServiceHostingEnvironment section at the service level by adding the attribute allowDefinition="MachineToApplication" to the section definition.


This change was made to avoid behavior this was difficult to understand and diagnose.

General

Title

Binaries removed from .NET Framework 4

Description

The following binaries have been removed from .NET Framework 4:

 cscompmgd.dll – this has been superseded by the CodeDOM classes.



VSA – this has been superseded by VSTA, which ships separately.



Cardspace 1.0 – this has been superseded by Cardspace 2.0, which will ship separately.



Managed controls in the browser and no-touch deployment applications – these have been superseded by ClickOnce, XBAPs, and Silverlight applications.



LDR64.exe – this is no longer required by the .NET Framework redist.



The assembly cache viewer (shell plugin) – this is no longer supported. You should use the gacutil.exe application in the SDK instead.


These technologies all have replacements that offer more features.

Known Migration Issues in .NET Framework 4 Beta 2

Known Migration Issues in .NET Framework 4 Beta 2

CLR

WPF

XML

Data

ASP .NET

WCF Services

General

Related documents

Products

Support

Known Migration Issues in .NET Framework 4 Beta 2

Known Migration Issues in .NET Framework 4 Beta 2

CLR

WPF

XML

Data

ASP .NET

WCF Services

General

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib