Omdirigering av ändringar för migrering till .NET Framework 4.5.x

I den här artikeln visas de problem med appkompatibilitet som introducerades i .NET Framework 4.5, 4.5.1 och 4.5.2.

.NET Framework 4.5

ASP.NET

MachineKey.Encode- och MachineKey.Decode-metoder är nu föråldrade

Detaljer

Dessa metoder är nu föråldrade. Kompilering av kod som anropar dessa metoder ger en kompilatorvarning.

Förslag

De rekommenderade alternativen är Protect(Byte[], String[]) och Unprotect(Byte[], String[]). Du kan också ignorera byggvarningarna, eller så kan de undvikas med hjälp av en äldre kompilator. API:erna stöds fortfarande.

Namn	Värde
Omfång	Underårig
Utgåva	4,5
Typ	Omriktning

Berörda API:er

• MachineKey.Encode(Byte[], MachineKeyProtection)
• MachineKey.Decode(String, MachineKeyProtection)

Avståndet i multi-line ASP.NET TextBox har ändrats när du använder AntiXSSEncoder

Detaljer

I .NET Framework 4.0 infogades extra rader mellan rader i en textruta med flera rader vid postback, om du använder System.Web.Security.AntiXss.AntiXssEncoder. I .NET Framework 4.5 ingår inte dessa extra radbrytningar, utan endast om webbappen riktar in sig på .NET Framework 4.5

Förslag

Tänk på att 4.0-webbappar som omdirigeras till .NET Framework 4.5 kan ha flerradstextrutor förbättrade så att de inte längre infogar extra radbrytningar. Om detta inte är önskvärt kan appen ha det gamla beteendet när den körs på .NET Framework 4.5 genom att rikta in sig på .NET Framework 4.0.

Namn	Värde
Omfång	Underårig
Utgåva	4,5
Typ	Omriktning

WebUtility.HtmlEncode och WebUtility.HtmlDecode återger BMP korrekt

Detaljer

För applikationer som riktar in sig på .NET Framework 4.5, rundas tecken som ligger utanför BMP (Basic Multilingual Plane) korrekt när de skickas till HtmlDecode(String)-metoderna.

Förslag

Den här ändringen bör inte ha någon effekt på aktuella program, men för att återställa det ursprungliga beteendet anger du targetFramework attributet för elementet <httpRuntime> till en annan sträng än "4.5". Du kan också ange attributen unicodeEncodingConformance och unicodeDecodingConformance för konfigurationselementet <webUtility> för att styra det här beteendet oberoende av målversionen av .NET Framework.

Namn	Värde
Omfång	Edge-teknik
Utgåva	4,5
Typ	Omriktning

Berörda API:er

• WebUtility.HtmlEncode(String)
• WebUtility.HtmlEncode(String, TextWriter)

ClickOnce

Appar som publicerats med ClickOnce och som använder ett SHA-256-kodsigneringscertifikat kan misslyckas i Windows 2003

Detaljer

Den körbara filen är signerad med SHA256. Tidigare signerades det med SHA1 oavsett om kodsigneringscertifikatet var SHA-1 eller SHA-256. Detta gäller för:

• Alla program som skapats med Visual Studio 2012 eller senare.
• Program som skapats med Visual Studio 2010 eller tidigare på system med .NET Framework 4.5 finns. Om .NET Framework 4.5 eller senare finns är ClickOnce-manifestet också signerat med SHA-256 för SHA-256-certifikat oavsett vilken .NET Framework-version som det kompilerades mot.

Förslag

Ändringen i signeringen av det körbara ClickOnce-programmet påverkar endast Windows Server 2003-system; de kräver att KB 938397 installeras. Ändringen i signeringen av manifestet med SHA-256 även när en app riktar in sig på .NET Framework 4.0 eller tidigare versioner introducerar ett körningsberoende för .NET Framework 4.5 eller en senare version.

Namn	Värde
Omfång	Edge-teknik
Utgåva	4,5
Typ	Omriktning

Kärna

Foreach-iteratorvariabeln är nu begränsad till iterationen, så hanteringen av slutande semantik skiljer sig (i C#5)

Detaljer

Från och med C# 5 (Visual Studio 2012) foreach begränsas iteratorvariablerna inom iterationen. Detta kan orsaka fel om koden tidigare var beroende av att variablerna inte ingick i slutningen av foreach. Symptomet för den här ändringen är att en iteratorvariabel som skickas till ett ombud behandlas som det värde som den har när ombudet skapas, i stället för det värde som den har när ombudet anropas.

Förslag

Helst bör koden uppdateras för att förvänta sig det nya kompilatorbeteendet. Om de gamla semantiken krävs kan iteratorvariabeln ersättas med en separat variabel som uttryckligen placeras utanför loopens omfång.

Namn	Värde
Omfång	Huvudsaklig
Utgåva	4,5
Typ	Omriktning

Egenskapen IAsyncResult.CompletedSynchronously måste vara korrekt för att den resulterande aktiviteten ska slutföras

Detaljer

När du anropar TaskFactory.FromAsync måste implementeringen av CompletedSynchronously egenskapen vara korrekt för att den resulterande uppgiften ska slutföras. Det innebär att egenskapen måste returnera true om, och endast om, implementeringen slutfördes synkront. Tidigare kontrollerades inte egenskapen.

Förslag

Om System.IAsyncResult-implementeringarna korrekt returnerar sant för System.IAsyncResult.CompletedSynchronously-egenskapen endast när en uppgift synkront slutförts, kommer ingen brytning att observeras. Användare bör granska System.IAsyncResult implementeringar som de äger (om några) för att säkerställa att de korrekt utvärderar om en uppgift har slutförts synkront eller inte.

Namn	Värde
Omfång	Edge-teknik
Utgåva	4,5
Typ	Omriktning

Berörda API:er

• TaskFactory.FromAsync(IAsyncResult, Action<IAsyncResult>)
• TaskFactory.FromAsync(IAsyncResult, Action<IAsyncResult>, TaskCreationOptions)
• TaskFactory.FromAsync(IAsyncResult, Action<IAsyncResult>, TaskCreationOptions, TaskScheduler)
• TaskFactory.FromAsync<TResult>(IAsyncResult, Func<IAsyncResult,TResult>)
• TaskFactory.FromAsync(Func<AsyncCallback,Object,IAsyncResult>, Action<IAsyncResult>, Object)
• TaskFactory.FromAsync(Func<AsyncCallback,Object,IAsyncResult>, Action<IAsyncResult>, Object, TaskCreationOptions)
• TaskFactory.FromAsync<TArg1>(Func<TArg1,AsyncCallback,Object,IAsyncResult>, Action<IAsyncResult>, TArg1, Object)
• TaskFactory.FromAsync<TArg1>(Func<TArg1,AsyncCallback,Object,IAsyncResult>, Action<IAsyncResult>, TArg1, Object, TaskCreationOptions)
• TaskFactory.FromAsync<TResult>(Func<AsyncCallback,Object,IAsyncResult>, Func<IAsyncResult,TResult>, Object)
• TaskFactory.FromAsync<TResult>(Func<AsyncCallback,Object,IAsyncResult>, Func<IAsyncResult,TResult>, Object, TaskCreationOptions)
• TaskFactory.FromAsync<TResult>(IAsyncResult, Func<IAsyncResult,TResult>, TaskCreationOptions)
• TaskFactory.FromAsync<TResult>(IAsyncResult, Func<IAsyncResult,TResult>, TaskCreationOptions, TaskScheduler)
• TaskFactory.FromAsync<TArg1,TArg2>(Func<TArg1,TArg2,AsyncCallback,Object,IAsyncResult>, Action<IAsyncResult>, TArg1, TArg2, Object)
• TaskFactory.FromAsync<TArg1,TArg2>(Func<TArg1,TArg2,AsyncCallback,Object,IAsyncResult>, Action<IAsyncResult>, TArg1, TArg2, Object, TaskCreationOptions)
• TaskFactory.FromAsync<TArg1,TResult>(Func<TArg1,AsyncCallback,Object,IAsyncResult>, Func<IAsyncResult,TResult>, TArg1, Object)
• TaskFactory.FromAsync<TArg1,TResult>(Func<TArg1,AsyncCallback,Object,IAsyncResult>, Func<IAsyncResult,TResult>, TArg1, Object, TaskCreationOptions)
• TaskFactory.FromAsync<TArg1,TArg2,TResult>(Func<TArg1,TArg2,AsyncCallback,Object,IAsyncResult>, Func<IAsyncResult,TResult>, TArg1, TArg2, Object)
• TaskFactory.FromAsync<TArg1,TArg2,TArg3>(Func<TArg1,TArg2,TArg3,AsyncCallback,Object,IAsyncResult>, Action<IAsyncResult>, TArg1, TArg2, TArg3, Object)
• TaskFactory.FromAsync<TArg1,TArg2,TArg3>(Func<TArg1,TArg2,TArg3,AsyncCallback,Object,IAsyncResult>, Action<IAsyncResult>, TArg1, TArg2, TArg3, Object, TaskCreationOptions)
• TaskFactory.FromAsync<TArg1,TArg2,TResult>(Func<TArg1,TArg2,AsyncCallback,Object,IAsyncResult>, Func<IAsyncResult,TResult>, TArg1, TArg2, Object, TaskCreationOptions)
• TaskFactory.FromAsync<TArg1,TArg2,TArg3,TResult>(Func<TArg1,TArg2,TArg3,AsyncCallback,Object,IAsyncResult>, Func<IAsyncResult,TResult>, TArg1, TArg2, TArg3, Object)
• TaskFactory.FromAsync<TArg1,TArg2,TArg3,TResult>(Func<TArg1,TArg2,TArg3,AsyncCallback,Object,IAsyncResult>, Func<IAsyncResult,TResult>, TArg1, TArg2, TArg3, Object, TaskCreationOptions)

Lista<T>. ForEach kan utlösa undantag när listobjekt ändras

Detaljer

Från och med .NET Framework 4.5 utlöser en ForEach(Action<T>) uppräknare ett System.InvalidOperationException undantag om ett element i den anropande samlingen ändras. Tidigare skulle detta inte utlösa ett undantag men kan leda till tävlingsförhållanden.

Förslag

Helst bör koden korrigeras för att inte ändra listor när de räknar upp sina element eftersom det aldrig är en säker åtgärd. Om du vill återgå till det tidigare beteendet kan en app dock rikta in sig på .NET Framework 4.0.

Namn	Värde
Omfång	Edge-teknik
Utgåva	4,5
Typ	Omriktning

Berörda API:er

• List<T>.ForEach(Action<T>)

System.Uri-parsning följer RFC 3987

Detaljer

URI-parsning har ändrats på flera sätt i .NET Framework 4.5. Observera dock att dessa ändringar endast påverkar kod som är riktad mot .NET Framework 4.5. Om ett binärt objekt är avsett för .NET Framework 4.0 observeras det gamla beteendet. Ändringar i URI-parsning i .NET Framework 4.5 är:

• URI-parsning utför normalisering och teckenkontroll enligt de senaste IRI-reglerna i RFC 3987.
• Unicode-normaliseringsformulär C utförs endast på värddelen av URI:n.
• Ogiltiga mailto:-URI:er kommer nu att orsaka ett undantag.
• Avslutande punkter i ett sökvägssegment bevaras nu.
• file:// URI:ar undviker tecknet ? inte.
• Unicode-kontrolltecken U+0080 via U+009F stöds inte.
• Kommatecken , eller %2c tas inte bort automatiskt.

Förslag

Om den gamla .NET Framework 4.0-URI-parsningssemantiken är nödvändig (de är ofta inte det) kan de användas genom att rikta in sig på .NET Framework 4.0. Detta kan åstadkommas med hjälp av en System.Runtime.Versioning.TargetFrameworkAttribute i sammansättningen, eller via Visual Studios projektsystemsgränssnitt på sidan projektegenskaper.

Namn	Värde
Omfång	Huvudsaklig
Utgåva	4,5
Typ	Omriktning

Berörda API:er

• Uri(String)
• Uri(String, Boolean)
• Uri(String, UriKind)
• Uri(Uri, String)
• Uri.TryCreate(String, UriKind, Uri)
• Uri.TryCreate(Uri, String, Uri)
• Uri.TryCreate(Uri, Uri, Uri)

System.Uri.IsWellFormedUriString-metoden returnerar false för relativa URI:er med kolontecken i det första segmentet

Detaljer

Från och med .NET Framework 4.5 kommer IsWellFormedUriString(String, UriKind) att behandla relativa URI:er med en : i det första segmentet som inte korrekt formaterade. Det här är en ändring från System.Uri.IsWellFormedUriString(String, UriKind) beteendet i .NET Framework 4.0 som gjordes för att överensstämma med RFC3986.

Förslag

Den här ändringen (precis som många andra URI-ändringar) påverkar bara program som riktar sig till .NET Framework 4.5 (eller senare). Om du vill fortsätta använda det gamla beteendet riktar du appen mot .NET Framework 4.0. Alternativt kan du skanna URI:er innan du anropar System.Uri.IsWellFormedUriString(String, UriKind) och leta : efter tecken som du kanske vill ta bort i valideringssyfte, om det gamla beteendet är önskvärt.

Namn	Värde
Omfång	Underårig
Utgåva	4,5
Typ	Omriktning

Berörda API:er

• Uri.IsWellFormedUriString(String, UriKind)

Entity Framework (programvarumiljö för databas)

Entity Framework-versionen måste matcha .NET Framework-versionen

Detaljer

Entity Framework-versionen (EF) ska matchas med .NET Framework-versionen. Entity Framework 5 rekommenderas för .NET Framework 4.5. Det finns några kända problem med EF 4.x i ett .NET Framework 4.5-projekt runt System.ComponentModel.DataAnnotations. I .NET Framework 4.5 flyttades dessa till en annan sammansättning, så det finns problem med att avgöra vilka anteckningar som ska användas.

Förslag

Uppgradera till Entity Framework 5 för .NET Framework 4.5

Namn	Värde
Omfång	Huvudsaklig
Utgåva	4,5
Typ	Omriktning

Windows-formulär

EncoderParameter ctor är föråldrad

Detaljer

Konstruktorn EncoderParameter(Encoder, Int32, Int32, Int32, Int32) är föråldrad nu och introducerar byggvarningar om den används.

Förslag

EncoderParameter(Encoder, Int32, Int32, Int32, Int32)Även om konstruktorn fortsätter att fungera bör följande konstruktor användas i stället för att undvika den föråldrade byggvarningen vid omkompilering av kod med .NET Framework 4.5-verktyg: EncoderParameter(Encoder, Int32, EncoderParameterValueType, IntPtr).

Namn	Värde
Omfång	Underårig
Utgåva	4,5
Typ	Omriktning

Berörda API:er

• EncoderParameter(Encoder, Int32, Int32, Int32, Int32)

Windows Communication Foundation (WCF)

Skriva binära utdata med BodyWriter

Detaljer

Om du härleder från klassen System.ServiceModel.Channels.BodyWriter och använder implementeringen av OnWriteBodyContents(XmlDictionaryWriter writer) för att skriva binära utdata kan vissa ändringar behöva göras när du gör om till .NET Framework 4.5. Kontrollera skrivtillståndet, och om det är WriterState.Start, generera det omslutande XML-elementet Binary enligt följande kodfragment.

protected override void OnWriteBodyContents(XmlDictionaryWriter writer)
{
    bool wroteStartElement = false;
    if (writer.WriteState == WriteState.Start)
    {
        writer.WriteStartElement("Binary", string.Empty);
        wroteStartElement = true;
    }
    writer.WriteBase64(buffer, offset, count);
    if (wroteStartElement)
    {
        writer.WriteEndElement();
    }
}

Om du härleder från klassen System.ServiceModel.Channels.StreamBodyWriter och har åsidosatt metoden OnWriteBodyContents(XmlDictionaryWriter writer), kan vissa ändringar krävas. När du riktade in dig på .NET Framework 4.0 var det nödvändigt att uttryckligen skriva elementet Binary när du åsidosättade den här metoden. Detta behövs inte längre när du riktar in dig på .NET Framework 4.5, vilket gör att brödtexten inte skrivs.

Windows Presentation Foundation (WPF)

WPF TextBox.Text kan vara osynkroniserad med databindning

Detaljer

I vissa fall återspeglar egenskapen Text ett tidigare värde för det databundna egenskapsvärdet om egenskapen ändras under en skrivåtgärd för databindning.

Förslag

Detta bör inte ha någon negativ inverkan. Du kan dock återställa det tidigare beteendet genom att ange KeepTextBoxDisplaySynchronizedWithTextProperty egenskapen till false.

	Värde
Omfattning	Edge-teknik
Version:	4,5
Typ	Omriktning

Berörda API:er

• TextBox.Text

Windows Workflow Foundation (WF)

Nya (tvetydiga) Dispatcher.Invoke-överlagringar kan leda till olika beteenden

Detaljer

.NET Framework 4.5 lägger till nya överlagringar till Dispatcher.Invoke som innehåller en parameter av typen Action. När befintlig kod omkompileras kan kompilatorer lösa anrop till Dispatcher.Invoke-metoder som har en Delegate-parameter som anrop till Dispatcher.Invoke-metoder med en Action-parameter. Om ett anrop till en Dispatcher.Invoke-överlagring med en Delegate parameter matchas som ett anrop till en Dispatcher.Invoke-överlagring med en Action parameter, kan följande skillnader i beteende uppstå:

• Om ett undantag inträffar utlöses inte UnhandledExceptionFilter- eller UnhandledException-händelserna. Undantag hanteras i stället av System.Threading.Tasks.TaskScheduler.UnobservedTaskException händelsen.
• Anrop till vissa medlemmar, till exempel Result, blockerar tills åtgärden har slutförts.

Förslag

För att undvika tvetydigheter (och potentiella skillnader i undantagshantering eller blockeringsbeteenden) kan kod som anropar Dispatcher.Invoke skicka ett tomt objekt[] som en andra parameter till Anropa-anropet för att vara säker på att matcha .NET Framework 4.0-metodöverbelastningen.

Namn	Värde
Omfång	Underårig
Utgåva	4,5
Typ	Omriktning

Berörda API:er

• Dispatcher.Invoke(Delegate, Object[])
• Dispatcher.Invoke(Delegate, TimeSpan, Object[])
• Dispatcher.Invoke(Delegate, TimeSpan, DispatcherPriority, Object[])
• Dispatcher.Invoke(Delegate, DispatcherPriority, Object[])

Vissa WorkFlow-dra och släpp-API:er är föråldrade

Detaljer

Det här WorkFlow-dra och släpp-API:et är föråldrat och orsakar kompilatorvarningar om appen återskapas mot 4.5.

Förslag

Nya System.Activities.Presentation.DragDropHelper API:er som stöder åtgärder med flera objekt ska användas i stället. Alternativt kan byggvarningarna ignoreras eller så kan de undvikas med hjälp av en äldre kompilator. API:erna stöds fortfarande.

Namn	Värde
Omfång	Underårig
Utgåva	4,5
Typ	Omriktning

Berörda API:er

• DragDropHelper.DoDragMove(WorkflowViewElement, Point)
• DragDropHelper.GetCompositeView(DragEventArgs)
• DragDropHelper.GetDraggedModelItem(DragEventArgs)
• DragDropHelper.GetDroppedObject(DependencyObject, DragEventArgs, EditingContext)

WorkFlow 3.0-typer är föråldrade

Detaljer

Windows Workflow Foundation (WWF) 3.0 API:er (de från namnområdet System.Workflow) är nu föråldrade.

Förslag

Nya WWF 4.0-API:er (i System.Activities) bör användas i stället. Ett exempel på hur du använder de nya API:erna finns i Så här: Uppdatera definitionen av en arbetsflödesinstans som körs. Ytterligare vägledning finns på WF3-typer som markerats som föråldrade i .NET 4.5. Eftersom WWF 3.0-API:erna fortfarande stöds kan de också användas, och du kan undvika varningen om byggtid genom att ignorera den eller genom att använda en äldre kompilator.

Namn	Värde
Omfång	Huvudsaklig
Utgåva	4,5
Typ	Omriktning

WorkflowDesigner.Load tar inte bort symbolegenskapen

Detaljer

När du riktar in dig mot .NET Framework 4.5 i arbetsflödesdesignern och läser in ett omdistribuerat 3.5-arbetsflöde med Load()-metoden, kastas ett System.Xaml.XamlDuplicateMemberException när arbetsflödet sparas.

Förslag

Den här buggen visas bara när du riktar in dig på .NET Framework 4.5 i arbetsflödesdesignern, så att den kan bearbetas genom att ange WorkflowDesigner.Context.Services.GetService<DesignerConfigurationService>().TargetFrameworkName till 4.0 .NET Framework.

Du kan också undvika problemet genom att använda Load(String) metoden för att läsa in arbetsflödet i stället för Load().

Namn	Värde
Omfång	Huvudsaklig
Utgåva	4,5
Typ	Omriktning

Berörda API:er

• WorkflowDesigner.Load()

XML, XSLT

XML-schemaverifiering är striktare

Detaljer

I .NET Framework 4.5 är XML-schemavalidering striktare. Om du använder xsd:anyURI för att verifiera en URI, till exempel ett mailto-protokoll, misslyckas verifieringen om det finns blanksteg i URI:n. I tidigare versioner av .NET Framework lyckades verifieringen. Ändringen påverkar endast program som riktar sig till .NET Framework 4.5.

Förslag

Om det behövs en lös .NET Framework 4.0-validering kan valideringsprogrammet rikta in sig på version 4.0 av .NET Framework. När du omdirigerar till .NET Framework 4.5 bör dock kodgranskning göras för att se till att ogiltiga URI:er (med blanksteg) inte förväntas som attributvärden med datatypen anyURI.

Namn	Värde
Omfång	Underårig
Utgåva	4,5
Typ	Omriktning

.NET Framework 4.5.1

ADO.NET

DbParameter.Precision och DbParameter.Scale är nu offentliga virtuella medlemmar

Detaljer

Precision och Scale implementeras som offentliga virtuella egenskaper. De ersätter motsvarande explicita gränssnittsimplementeringar IDbDataParameter.Precision och IDbDataParameter.Scale.

Förslag

När du återskapar en ADO.NET databasleverantör kräver dessa skillnader att nyckelordet 'override' tillämpas på egenskaperna Precision och Skala. Detta behövs bara när komponenterna byggs om. befintliga binärfiler fortsätter att fungera.

Namn	Värde
Omfång	Underårig
Utgåva	4.5.1
Typ	Omriktning

Berörda API:er

• DbParameter.Precision
• DbParameter.Scale

Kärna

ObsoleteAttribute exporteras både som ObsoleteAttribute och DeprecatedAttribute i WinMD-scenarier

Detaljer

När du skapar ett Windows-metadatabibliotek (.winmd-fil) System.ObsoleteAttribute exporteras attributet som både System.ObsoleteAttribute och Windows.Foundation.DeprecatedAttribute.

Förslag

Omkompilering av befintlig källkod som använder System.ObsoleteAttribute attributet kan generera varningar vid användning av koden från C++/CX eller JavaScript.Vi rekommenderar inte att du tillämpar både System.ObsoleteAttribute och Windows.Foundation.DeprecatedAttribute på kod i hanterade sammansättningar. Det kan resultera i byggvarningar.

Namn	Värde
Omfång	Edge-teknik
Utgåva	4.5.1
Typ	Omriktning

Entity Framework (programvarumiljö för databas)

Att bygga en Entity Framework edmx med Visual Studio 2013 kan misslyckas med fel MSB4062 om du använder åtgärderna EntityDeploySplit eller EntityClean.

Detaljer

MSBuild 12.0-verktyg (ingår i Visual Studio 2013) ändrade MSBuild-filplatser, vilket gjorde att äldre Entity Framework-målfiler var ogiltiga. Resultatet är att EntityDeploySplit och EntityClean aktiviteter misslyckas eftersom de inte kan hitta Microsoft.Data.Entity.Build.Tasks.dll. Observera att den här pausen beror på en ändring av verktygsuppsättningen (MSBuild/VS), inte på grund av en .NET Framework-ändring. Det inträffar bara när du uppgraderar utvecklarverktyg, inte när du bara uppgraderar .NET Framework.

Förslag

Entity Framework-målfiler har åtgärdats för att fungera med den nya MSBuild-layouten med början i .NET Framework 4.6. Om du uppgraderar till den versionen av ramverket åtgärdas det här problemet. Du kan också använda den här lösningen för att korrigera målfilerna direkt.

Namn	Värde
Omfång	Huvudsaklig
Utgåva	4.5.1
Typ	Omriktning

MSBuild

Uppgiften ResolveAssemblyReference varnar nu för beroenden med fel arkitektur

Detaljer

Uppgiften genererar en varning, MSB3270, som anger att en referens eller något av dess beroenden inte matchar appens arkitektur. Detta inträffar till exempel om en app som kompilerats med AnyCPU alternativet innehåller en x86-referens. Ett sådant scenario kan leda till ett appfel vid körning (i det här fallet om appen distribueras som en x64-process).

Förslag

Det finns två effektområden:

• Omkompilering genererar varningar som inte visades när appen kompilerades under en tidigare version av MSBuild. Men eftersom varningen identifierar en möjlig källa till körningsfel bör den undersökas och åtgärdas.
• Om varningar behandlas som fel kan appen inte kompileras.

Namn	Värde
Omfång	Underårig
Utgåva	4.5.1
Typ	Omriktning

Windows Presentation Foundation (WPF)

Dubbelriktad databindning till en egenskap med en icke-offentlig setter stöds inte

Detaljer

Att försöka binda data till en egenskap utan en offentlig setter har aldrig varit ett scenario som stöds. Från och med .NET Framework 4.5.1 utlöser det här scenariot en System.InvalidOperationException. Observera att det här nya undantaget endast genereras för appar som specifikt riktar sig till .NET Framework 4.5.1. Om en app riktar in sig på .NET Framework 4.5 tillåts anropet. Om appen inte riktar in sig på en viss .NET Framework-version behandlas bindningen som enkelriktad.

Förslag

Appen bör uppdateras för att antingen använda envägsbindning eller göra egenskapens tilldelningsmetod tillgänglig offentligt. Om du riktar in dig på .NET Framework 4.5 kan appen också uppvisa det gamla beteendet.

Namn	Värde
Omfång	Underårig
Utgåva	4.5.1
Typ	Omriktning

Berörda API:er

• BindingMode.TwoWay

.NET Framework 4.5.2

Visual Basic .NET

VB.NET stöder inte längre partiell namnområdeskvalificering för System.Windows-API:er

Detaljer

Från och med .NET Framework 4.5.2 kan VB.NET projekt inte ange System.Windows-API:er med delvis kvalificerade namnområden. Det går till exempel inte att referera till Windows.Forms.DialogResult . I stället måste koden referera till det fullständigt kvalificerade namnet (DialogResult) eller importera det specifika namnområdet och referera helt enkelt till System.Windows.Forms.DialogResult.

Förslag

Koden bör uppdateras för att referera till System.Windows API:er med enkla namn (och import av relevant namnområde) eller med fullständigt kvalificerade namn.

Namn	Värde
Omfång	Underårig
Utgåva	4.5.2
Typ	Omriktning

Windows-formulär

DataObject.GetData hämtar nu data som UTF-8

Detaljer

För appar som riktar sig mot .NET Framework 4 eller som körs på .NET Framework 4.5.1 eller tidigare versioner DataObject.GetData hämtar HTML-formaterade data som en ASCII-sträng. Därför representeras icke-ASCII-tecken (tecken vars ASCII-koder är större än 0x7F) av två slumpmässiga tecken.

För appar som riktar in sig på .NET Framework 4.5 eller senare och körs på .NET Framework 4.5.2 DataObject.GetData hämtar HTML-formaterade data som UTF-8, vilket representerar tecken som är större än 0x7F korrekt.

Förslag

Om du implementerade en lösning för kodningsproblemet med HTML-formaterade strängar (till exempel genom att uttryckligen koda HTML-strängen som hämtats från Urklipp genom att skicka den till System.Text.UTF8Encoding.GetString(Byte[], Int32, Int32)) och du gör om din app från version 4 till 4.5, bör den lösningen tas bort. Om det gamla beteendet behövs av någon anledning kan appen rikta in sig på .NET Framework 4.0 för att få det beteendet.

Namn	Värde
Omfång	Edge-teknik
Utgåva	4.5.2
Typ	Omriktning

Berörda API:er

• DataObject.GetData(String)
• DataObject.GetData(Type)
• DataObject.GetData(String, Boolean)

Windows Workflow Foundation (WF)

WorkflowDesigner.Load tar inte bort symbolegenskapen

Detaljer

När du riktar in dig mot .NET Framework 4.5 i arbetsflödesdesignern och läser in ett omdistribuerat 3.5-arbetsflöde med Load()-metoden, kastas ett System.Xaml.XamlDuplicateMemberException när arbetsflödet sparas.

Förslag

Den här buggen visas bara när du riktar in dig på .NET Framework 4.5 i arbetsflödesdesignern, så att den kan bearbetas genom att ange WorkflowDesigner.Context.Services.GetService<DesignerConfigurationService>().TargetFrameworkName till 4.0 .NET Framework.

Du kan också undvika problemet genom att använda Load(String) metoden för att läsa in arbetsflödet i stället för Load().

Namn	Värde
Omfång	Huvudsaklig
Utgåva	4,5
Typ	Omriktning

Berörda API:er

• WorkflowDesigner.Load()