A .NET-keretrendszer 4.5.x verzióra történő áttérés célzásának módosításai

Ez a cikk a .NET-keretrendszer 4.5-ös, 4.5.1-ös és 4.5.2-ben bevezetett alkalmazáskompatibilitási problémákat sorolja fel.

.NET-keretrendszer 4.5

ASP.NET

A MachineKey.Encode és a MachineKey.Decode metódusok elavultak

Részletek

Ezek a módszerek már elavultak. Azon kód fordítása, amely ezeket a metódusokat hívja meg, figyelmeztetéssel jár a fordító részéről.

Javaslat

Az ajánlott alternatívák a következők Protect(Byte[], String[]) : és Unprotect(Byte[], String[]). Alternatívaként a fordítási figyelmeztetések elnyomhatók, vagy elkerülhetők egy régebbi fordító használatával. Az API-k továbbra is támogatottak.

Név	Érték
Hatókör	Kisebb jelentőségű
verzió	4.5
Típus	Újracélzás

Érintett API-k

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

Többsoros ASP.NET Szövegdoboz térköze módosult az AntiXSSEncoder használatakor

Részletek

A .NET-keretrendszer 4.0-s verziójában a rendszer további sorokat szúrt be egy többsoros szövegdoboz sorai közé postback esetén, ha a System.Web.Security.AntiXss.AntiXssEncoder-t használja. A .NET-keretrendszer 4.5-ben ezek az extra sortörések nem szerepelnek, de csak akkor, ha a webalkalmazás a .NET-keretrendszer 4.5-öt célozza

Javaslat

Vegye figyelembe, hogy a 4.0-s webalkalmazásokat a .NET keretrendszer 4.5-re átirányították, ami javított többsoros szövegdobozokat eredményezhet, hogy többé ne szúrjanak be további sortöréseket. Ha ez nem kívánatos, az alkalmazás a régi viselkedést mutathatja a .NET-keretrendszer 4.5-ös verzióján futva, ha a .NET-keretrendszer 4.0-s verzióját célozza meg.

Név	Érték
Hatókör	Kisebb jelentőségű
verzió	4.5
Típus	Újracélzás

WebUtility.HtmlEncode és WebUtility.HtmlDecode helyesen oda-vissza konvertálja a BMP-t

Részletek

A .NET-keretrendszer 4.5-öt megcélzó alkalmazások esetében azok a karakterek, amelyek az alapvető többnyelvű síkon (BMP) kívül esnek, helyesen kerülnek visszaadásra, amikor a HtmlDecode(String) metódusoknak vannak átadva.

Javaslat

Ennek a módosításnak nincs hatása az aktuális alkalmazásokra, de az eredeti viselkedés visszaállításához állítsa az targetFramework<httpRuntime> elem attribútumát a "4.5" karakterlánctól eltérő sztringre. A unicodeEncodingConformance konfigurációs elem unicodeDecodingConformance és <webUtility> attribútumait is beállíthatja úgy, hogy ezt a viselkedést a .NET-keretrendszer célzott verziójától függetlenül szabályozza.

Név	Érték
Hatókör	Edge
verzió	4.5
Típus	Újracélzás

Érintett API-k

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

ClickOnce

Az SHA-256 kódaláíró tanúsítványt használó ClickOnce-nal közzétett alkalmazások sikertelenek lehetnek Windows 2003 rendszeren

Részletek

A végrehajtható fájl az SHA256-tal van aláírva. Korábban az SHA1-zel írták alá, függetlenül attól, hogy a kódaláíró tanúsítvány SHA-1 vagy SHA-256 volt-e. Ez a következőkre vonatkozik:

• A Visual Studio 2012 vagy újabb verziójával készült összes alkalmazás.
• A Visual Studio 2010-zel vagy korábbi verzióval készült alkalmazások a .NET-keretrendszer 4.5-ös verziójával rendelkező rendszereken. Ezenkívül, ha a .NET-keretrendszer 4.5-ös vagy újabb verziója elérhető, a ClickOnce-jegyzéket SHA-256-tal írják alá az SHA-256 tanúsítványok esetében, függetlenül attól, hogy mely .NET-keretrendszer verzióra fordították.

Javaslat

A ClickOnce végrehajtható aláírásának módosítása csak a Windows Server 2003 rendszereket érinti; megkövetelik, hogy a KB 938397 legyen telepítve. A jegyzék sha-256-tal való aláírásának módosítása akkor is, ha egy alkalmazás a .NET-keretrendszer 4.0-s vagy korábbi verzióit célozza, futtatókörnyezeti függőséget vezet be a .NET-keretrendszer 4.5-ös vagy újabb verzióján.

Név	Érték
Hatókör	Edge
verzió	4.5
Típus	Újracélzás

Központ

A Foreach iterator változó hatóköre mostantól az iteráción belül van, így a zárórögzítési szemantikák eltérőek (a C#5-ben)

Részletek

A C# 5 -től (Visual Studio 2012) foreach kezdődően az iterátorváltozók hatóköre az iteráción belül van. Ez töréseket okozhat, ha a kód korábban attól függött, hogy a változók nem szerepelnek-e a foreachlezárásban. Ennek a változásnak az a tünete, hogy a delegáltnak átadott iterátorváltozót a meghatalmazott létrehozásakor meglévő értékként kezeli a rendszer, nem pedig azt az értéket, amely a meghatalmazott meghívásakor szerepel.

Javaslat

Ideális esetben frissíteni kell a kódot, hogy az új fordítói viselkedésre számítson. Ha a régi szemantikára van szükség, az iterátor változó lecserélhető egy külön változóra, amely kifejezetten kívül esik a ciklus hatókörén.

Név	Érték
Hatókör	Őrnagy
verzió	4.5
Típus	Újracélzás

Az IAsyncResult.CompletedSynchronously tulajdonságnak helyesnek kell lennie ahhoz, hogy az eredményül kapott tevékenység befejeződjön

Részletek

A TaskFactory.FromAsync meghívásakor a CompletedSynchronously tulajdonság implementációjának helyesnek kell lennie ahhoz, hogy az eredményül kapott tevékenység befejeződjön. Vagyis a tulajdonságnak igaz értéket kell visszaadnia, ha és csak akkor, ha az implementáció szinkronban fejeződött be. Korábban a tulajdonság nem volt ellenőrizve.

Javaslat

Ha a System.IAsyncResult implementációk csak akkor térnek vissza helyesen a System.IAsyncResult.CompletedSynchronously tulajdonságra, ha egy feladat szinkron módon fejeződött be, akkor nem lesz észlelhető megszakítás. A felhasználóknak át kell tekinteniük System.IAsyncResult a saját implementációkat (ha vannak ilyenek), hogy helyesen értékeljék ki, hogy egy tevékenység szinkronban fejeződött-e be.

Név	Érték
Hatókör	Edge
verzió	4.5
Típus	Újracélzás

Érintett API-k

• 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 kivételt dobhat, ha módosítja a listaelemet.

Részletek

A .NET-keretrendszer 4.5-ös verziótól kezdődően az ForEach(Action<T>) enumerátorok kivételt System.InvalidOperationException képeznek, ha a hívásgyűjtemény egy eleme módosul. Korábban ez nem okozott kivételt, de versenyfeltételekhez vezethetett.

Javaslat

Ideális esetben a kódot úgy kell kijavítani, hogy ne módosítsa a listákat, miközben számba vegye az elemeket, mert ez soha nem biztonságos művelet. Az előző viselkedésre való visszatéréshez azonban előfordulhat, hogy egy alkalmazás a .NET Framework 4.0-t célozza meg.

Név	Érték
Hatókör	Edge
verzió	4.5
Típus	Újracélzás

Érintett API-k

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

A System.Uri-elemzés megfelel az RFC 3987-nek

Részletek

Az URI-elemzés több módon is megváltozott a .NET-keretrendszer 4.5-ben. Vegye figyelembe azonban, hogy ezek a módosítások csak a .NET-keretrendszer 4.5-ös kódját érintik. Ha egy bináris a .NET-keretrendszer 4.0-s verzióját célozza meg, a régi viselkedés figyelhető meg. A .NET-keretrendszer 4.5-ös URI-elemzésének változásai a következők:

• Az URI-elemzés normalizálást és karakterellenőrzést végez az RFC 3987 legújabb IRI-szabályainak megfelelően.
• A C Unicode normalizálási forma csak az URI gazdagéprészén lesz végrehajtva.
• Az érvénytelen mailto: URI-k mostantól kivételt okoznak.
• Az elérésiút-szegmens végén lévő végpontokat megőrzi a rendszer.
• file:// Az URI-k nem kerülik el a ? karaktert.
• A Unicode-vezérlőkarakterek U+0080U+009F nem támogatottak.
• Vesszőkarakterek , , vagy %2c nincsenek automatikusan kibontva.

Javaslat

Ha szükség van a régi .NET-keretrendszer 4.0-s URI-elemzési szemantikára (bár ez gyakran nem szükséges), azok használhatók a .NET-keretrendszer 4.0 megcélzásával. Ez úgy valósítható meg, hogy a System.Runtime.Versioning.TargetFrameworkAttribute-t használjuk a szerelvényen, vagy a Visual Studio projekt tulajdonságainak oldalán keresztül a projektrendszer felhasználói felületén.

Név	Érték
Hatókör	Őrnagy
verzió	4.5
Típus	Újracélzás

Érintett API-k

• 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)

A System.Uri.IsWellFormedUriString metódus hamis értéket ad vissza a relatív URI-khoz kettőspont karakterrel az első szegmensben

Részletek

A .NET-keretrendszer 4.5-től kezdve a IsWellFormedUriString(String, UriKind) az első szegmensben lévő relatív URI-kat nem megfelelően formázottként fogja kezelni. Ez a .NET-keretrendszer 4.0-s viselkedésének System.Uri.IsWellFormedUriString(String, UriKind) módosítása, amely a RFC3986 való megfelelés érdekében történt.

Javaslat

Ez a változás (sok más URI-módosításhoz hasonlóan) csak a .NET-keretrendszer 4.5-ös (vagy újabb) verzióját célzó alkalmazásokat érinti. A régi viselkedés megtartásához az alkalmazást a .NET-keretrendszer 4.0-s verziója ellen kell céloznia. Alternatív megoldásként ellenőrizze az URI-t, mielőtt meghívja System.Uri.IsWellFormedUriString(String, UriKind), és keresse meg azokat a : karaktereket, amelyeket érvényesítési célból el szeretne távolítani, ha a régi viselkedés kívánatos.

Név	Érték
Hatókör	Kisebb jelentőségű
verzió	4.5
Típus	Újracélzás

Érintett API-k

• Uri.IsWellFormedUriString(String, UriKind)

Entity Framework

Az Entity Framework verziójának meg kell egyeznie a .NET-keretrendszer verziójával

Részletek

Az Entity Framework (EF) verziónak meg kell egyeznie a .NET-keretrendszer verziójával. Az Entity Framework 5 a .NET-keretrendszer 4.5-ös verziója esetén ajánlott. A .NET-keretrendszer 4.5-ös projektjében az EF 4.x-tel kapcsolatban ismert problémák merülnek fel System.ComponentModel.DataAnnotations. A .NET-keretrendszer 4.5-ös verziója ezeket egy másik szerelvénybe helyezte át, ezért problémák merülnek fel a használni kívánt széljegyzetek meghatározásával kapcsolatban.

Javaslat

Frissítés az Entity Framework 5 for .NET Framework 4.5-re

Név	Érték
Hatókör	Őrnagy
verzió	4.5
Típus	Újracélzás

Windows Forms

Az EncoderParameter konstruktor elavult

Részletek

A EncoderParameter(Encoder, Int32, Int32, Int32, Int32) konstruktor már elavult, és a használata fordítási figyelmeztetéseket eredményez.

Javaslat

Bár a EncoderParameter(Encoder, Int32, Int32, Int32, Int32)konstruktor továbbra is működni fog, a .NET Framework 4.5-eszközökkel végzett kódismétlésekor a következő konstruktort kell használni, hogy elkerülje az elavult buildre vonatkozó figyelmeztetést: EncoderParameter(Encoder, Int32, EncoderParameterValueType, IntPtr)

Név	Érték
Hatókör	Kisebb jelentőségű
verzió	4.5
Típus	Újracélzás

Érintett API-k

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

Windows Communication Foundation (WCF)

Bináris kimenet írása a BodyWriter használatával

Részletek

Ha az System.ServiceModel.Channels.BodyWriter osztályból származik, és az OnWriteBodyContents(XmlDictionaryWriter writer) implementációt használja bináris kimenet írására, előfordulhat, hogy bizonyos módosításokra lesz szükség, amikor átvált a .NET-keretrendszer 4.5-ös verziójára. Ellenőrizze az írási állapotot, és ha van WriterState.Start, adja ki a Binary burkoló XML-elemet az alábbi kódrészletben látható módon.

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();
    }
}

Emellett, ha az osztályból System.ServiceModel.Channels.StreamBodyWriter származik, és felülírta a metódust OnWriteBodyContents(XmlDictionaryWriter writer), szükség lehet néhány módosításra. A .NET-keretrendszer 4.0-s célzásakor explicit módon meg kellett írni az elemet a Binary metódus felülírásakor. Erre már nincs szükség a .NET-keretrendszer 4.5-ös megcélzásakor, mivel ez azt eredményezi, hogy a tartalom nem kerül megírásra.

Windows Presentation Foundation (WPF)

A WPF TextBox.Text nem szinkronizálható adatkötéssel

Részletek

Bizonyos esetekben a tulajdonság az Text adatkötési tulajdonság értékének egy korábbi értékét tükrözi, ha a tulajdonság egy adatkötési írási művelet során módosul.

Javaslat

Ennek nincs negatív hatása. A tulajdonság beállításával azonban visszaállíthatja a korábbi viselkedést KeepTextBoxDisplaySynchronizedWithTextPropertyfalse.

	Érték
Hatókör	Edge
verzió	4.5
Típus	Újracélzás

Érintett API-k

• TextBox.Text

Windows Workflow Foundation (WF)

Az új (nem egyértelmű) Dispatcher.Invoke túlterhelések eltérő viselkedést eredményezhetnek

Részletek

A .NET-keretrendszer 4.5 új túlterheléseket ad hozzá a Dispatcher.Invoke-hez, amelyek egy Action típusú paramétert tartalmaznak. Ha a meglévő kód újrafordítása történik, a fordítók feloldhatják a Dispatcher.Invoke metódusok hívásait, amelyek paraméterrel rendelkeznek Delegate a Dispatcher hívásaiként.Metódusok meghívása paraméterrel Action . Ha egy Dispatcher.Invoke metódus hívása egy Delegate paraméterrel úgy oldódik fel, mint egy Dispatcher.Invoke metódus hívása egy Action paraméterrel, a következő viselkedésbeli különbségek fordulhatnak elő:

• Kivétel esetén a UnhandledExceptionFilter és UnhandledException események nincsenek aktiválva. Ehelyett az esemény kezeli a System.Threading.Tasks.TaskScheduler.UnobservedTaskException kivételeket.
• Néhány tag hívása, például Resulta művelet befejezéséig blokkolva van.

Javaslat

A kétértelműség (és a kivételkezelés vagy a blokkolási viselkedés lehetséges eltérései) elkerülése érdekében a Dispatcher.Invoke kód meghívásakor egy üres objektum[] továbbítható második paraméterként a híváshíváshoz, hogy biztosan feloldhassa a .NET-keretrendszer 4.0 metódus túlterhelését.

Név	Érték
Hatókör	Kisebb jelentőségű
verzió	4.5
Típus	Újracélzás

Érintett API-k

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

Egyes WorkFlow húzási API-k elavultak

Részletek

Ez a WorkFlow húzási API elavult, és fordítói figyelmeztetéseket fog okozni, ha az alkalmazást újraépítették a 4.5-ös verzióhoz.

Javaslat

Ehelyett olyan új System.Activities.Presentation.DragDropHelper API-kat kell használni, amelyek több objektummal támogatják a műveleteket. Alternatív megoldásként a fordítási figyelmeztetések mellőzhetők, vagy egy régebbi fordító használatával elkerülhetők. Az API-k továbbra is támogatottak.

Név	Érték
Hatókör	Kisebb jelentőségű
verzió	4.5
Típus	Újracélzás

Érintett API-k

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

A WorkFlow 3.0-típusok elavultak

Részletek

A Windows Workflow Foundation (WWF) 3.0 API-k (amelyek a System.Workflow névtérből származnak) elavultak.

Javaslat

Ehelyett új WWF 4.0 API-kat kell használni (a System.Activitiesben). Az új API-k használatára példa : Útmutató: Futó munkafolyamat-példány definíciójának frissítése. További útmutatást a .NET 4.5-ben elavultként megjelölt WF3-típusokban találhat. Alternatív megoldásként, mivel a WWF 3.0 API-k továbbra is támogatottak, használhatók, és elkerülheti a fordítási időpontú figyelmeztetést annak elnyomásával vagy egy régebbi fordítóprogram használatával.

Név	Érték
Hatókör	Őrnagy
verzió	4.5
Típus	Újracélzás

A WorkflowDesigner.Load nem távolítja el a szimbólumtulajdonságot

Részletek

Amikor a munkafolyamat-tervezőben a .NET-keretrendszer 4.5-ös verzióját célozzák meg, és a Load() metódussal egy újrahosztolt 3.5-ös munkafolyamatot töltenek be, mentéskor egy System.Xaml.XamlDuplicateMemberException kivétel keletkezik.

Javaslat

Ez a hiba csak akkor jelentkezik, ha a munkafolyamat-tervezőben a .NET-keretrendszer 4.5-ös verziója van megcélzva, így a 4.0 .NET-keretrendszerre való beállítással WorkflowDesigner.Context.Services.GetService<DesignerConfigurationService>().TargetFrameworkName megkerülhető.

A problémát elkerülheti, ha a munkafolyamat Load(String)betöltése helyett a Load() metódust használja.

Név	Érték
Hatókör	Őrnagy
verzió	4.5
Típus	Újracélzás

Érintett API-k

• WorkflowDesigner.Load()

XML, XSLT

Az XML-séma érvényesítése szigorúbb

Részletek

A .NET-keretrendszer 4.5-ben az XML-séma érvényesítése szigorúbb. Ha xsd:anyURI használatával érvényesít egy URI-t, például egy mailto protokollt, az ellenőrzés meghiúsul, ha szóközök vannak az URI-ban. A .NET-keretrendszer korábbi verzióiban az ellenőrzés sikeres volt. A módosítás csak azokat az alkalmazásokat érinti, amelyek a .NET-keretrendszer 4.5-ös verziót célozzák.

Javaslat

Ha lazább .NET-keretrendszer 4.0-s érvényesítésre van szükség, az érvényesítő alkalmazás a .NET-keretrendszer 4.0-s verzióját célozhatja meg. A .NET-keretrendszer 4.5-ös verzióra való átcélzásakor azonban el kell végezni a kód felülvizsgálatát. Ellenőrizni kell, hogy szóközöket tartalmazó érvénytelen URI-k nem számítanak attribútumértékként az anyURI-adattípussal.

Név	Érték
Hatókör	Kisebb jelentőségű
verzió	4.5
Típus	Újracélzás

.NET-keretrendszer 4.5.1

ADO.NET

A DbParameter.Precision és a DbParameter.Scale mostantól nyilvános virtuális tagok

Részletek

Precision és Scale nyilvános virtuális tulajdonságokként vannak implementálva. Lecserélik a megfelelő explicit felületi implementációkat, IDbDataParameter.Precision és IDbDataParameter.Scale.

Javaslat

Egy ADO.NET adatbázis-szolgáltató újraépítésekor ezek a különbségek megkövetelik, hogy a "felülbírálás" kulcsszót alkalmazza a pontossági és méretezési tulajdonságokra. Erre csak az összetevők újraépítésekor van szükség; a meglévő bináris fájlok továbbra is működni fognak.

Név	Érték
Hatókör	Kisebb jelentőségű
verzió	4.5.1
Típus	Újracélzás

Érintett API-k

• DbParameter.Precision
• DbParameter.Scale

Központ

A WinMD forgatókönyvekben az ObsoleteAttribute elavultAttribútumként és DeprecatedAttribútumként is exportálódik.

Részletek

Windows-metaadattár (.winmd fájl) létrehozásakor az System.ObsoleteAttribute attribútum mindkét attribútumként, System.ObsoleteAttribute és Windows.Foundation.DeprecatedAttribute-ként, lesz exportálva.

Javaslat

A System.ObsoleteAttribute attribútumot használó meglévő forráskód újrafordítása figyelmeztetéseket generálhat, amikor a kódot C++/CX vagy JavaScript használatával alkalmazzák. Nem javasoljuk, hogy mind System.ObsoleteAttribute, mind a Windows.Foundation.DeprecatedAttribute paramétert alkalmazza a felügyelt szerelvényekben lévő kódra, mert az fordítási figyelmeztetéseket eredményezhet.

Név	Érték
Hatókör	Edge
verzió	4.5.1
Típus	Újracélzás

Entity Framework

Az Entity Framework edmx Visual Studio 2013-nal való létrehozása meghiúsulhat MSB4062 hibával, ha az EntityDeploySplit vagy az EntityClean feladatokat használja

Részletek

Az MSBuild 12.0-eszközök (a Visual Studio 2013-ban) megváltoztatták az MSBuild fájlhelyeket, ami miatt a régebbi Entity Framework-célfájlok érvénytelenek. Az eredmény az, hogy a EntityDeploySplit és EntityClean feladatok sikertelenek, mert nem találják a Microsoft.Data.Entity.Build.Tasks.dll-t. Vegye figyelembe, hogy ez a törés egy eszközkészlet (MSBuild/VS) változása miatt van, nem a .NET-keretrendszer módosítása miatt. Ez csak a fejlesztői eszközök frissítésekor fordul elő, nem pedig csak a .NET-keretrendszer frissítésekor.

Javaslat

Az Entity Framework célfájljai a .NET-keretrendszer 4.6-os verziója óta az új MSBuild-elrendezéssel való együttműködéshez vannak javítva. A keretrendszer erre a verziójára való frissítés megoldja ezt a problémát. Alternatív megoldásként ez a megkerülő megoldás közvetlen módon használható a célfájlok javítására.

Név	Érték
Hatókör	Őrnagy
verzió	4.5.1
Típus	Újracélzás

MSBuild

A ResolveAssemblyReference feladat mostantól figyelmeztet a nem megfelelő architektúrával rendelkező függőségekre

Részletek

A feladat figyelmeztetést MSB3270 bocsát ki, amely azt jelzi, hogy egy hivatkozás vagy annak függőségei nem felelnek meg az alkalmazás architektúrájának. Ez például akkor fordul elő, ha egy AnyCPU opcióval fordított alkalmazás tartalmaz x86-os hivatkozást. Egy ilyen forgatókönyv futtatáskor alkalmazáshibát okozhat (ebben az esetben, ha az alkalmazás x64-folyamatként van üzembe helyezve).

Javaslat

Két hatásterület van:

• Az újrafordítás olyan figyelmeztetéseket generál, amelyek nem jelentek meg, amikor az alkalmazás az MSBuild egy korábbi verziójában készült. Mivel azonban a figyelmeztetés azonosítja a futásidejű hiba lehetséges forrását, meg kell vizsgálni és kezelni kell.
• Ha a figyelmeztetéseket hibaként kezelik, az alkalmazás fordítása sikertelen lesz.

Név	Érték
Hatókör	Kisebb jelentőségű
verzió	4.5.1
Típus	Újracélzás

Windows Presentation Foundation (WPF)

Nem támogatott a kétirányú adatkötés egy nem nyilvános setterrel rendelkező tulajdonsághoz

Részletek

A tulajdonsághoz való adatkötés nyilvános beállító nélkül történő megkísérlése soha nem volt támogatott forgatókönyv. A .NET-keretrendszer 4.5.1-től kezdve ez az eset egy System.InvalidOperationException kivételt dob. Vegye figyelembe, hogy ez az új kivétel csak a kifejezetten a .NET-keretrendszer 4.5.1-et megcélzott alkalmazásokra vonatkozik. Ha egy alkalmazás a .NET-keretrendszer 4.5-öt célozza meg, a hívás engedélyezett lesz. Ha az alkalmazás nem egy adott .NET-keretrendszer-verziót céloz meg, a kötés egyirányúként lesz kezelve.

Javaslat

Az alkalmazást frissíteni kell, hogy használjon egyirányú kötést, vagy tegye közzé nyilvánosan a tulajdonság beállítóját. Másik lehetőségként a .NET-keretrendszer 4.5-ös megcélzása azt eredményezi, hogy az alkalmazás a régi viselkedést mutatja.

Név	Érték
Hatókör	Kisebb jelentőségű
verzió	4.5.1
Típus	Újracélzás

Érintett API-k

• BindingMode.TwoWay

.NET-keretrendszer 4.5.2

Visual Basic .NET

VB.NET már nem támogatja a System.Windows API-k részleges névtér-minősítését

Részletek

A .NET-keretrendszer 4.5.2-es verziójától kezdődően a VB.NET projektekben nem lehet részlegesen megadott névterekkel hivatkozni a System.Windows API-kra. Például, ha Windows.Forms.DialogResult-ra hivatkozunk, az sikertelen lesz. Ehelyett a kódnak a teljes névre, vagyis DialogResult-re kell hivatkoznia, vagy importálnia kell az adott névteret, és egyszerűen hivatkoznia kell System.Windows.Forms.DialogResult-re.

Javaslat

A kódot frissíteni kell annak érdekében, hogy a System.Windows API-kra vagy egyszerű névvel (és a megfelelő névtér importálásával), vagy teljes névvel hivatkozzon.

Név	Érték
Hatókör	Kisebb jelentőségű
verzió	4.5.2
Típus	Újracélzás

Windows Forms

A DataObject.GetData mostantól UTF-8 formátumban kéri le az adatokat

Részletek

A .NET-keretrendszer 4-et megcélozó vagy a .NET-keretrendszer 4.5.1-ben vagy korábbi verzióiban DataObject.GetData futó alkalmazások esetében a HTML-formátumú adatokat ASCII-sztringként kéri le. Ennek eredményeképpen a nem ASCII karaktereket (azok a karakterek, amelyek ASCII-kódjai nagyobbak, mint 0x7F) két véletlenszerű karakter jelöli.

A .NET-keretrendszer 4.5-ös vagy újabb verzióját megcélzó és a .NET-keretrendszer 4.5.2-n futó alkalmazások esetében a DataObject.GetData az HTML-formátumú adatokat UTF-8 formátumban kéri le, amely helyesen ábrázolja a 0x7F-nél nagyobb karaktereket.

Javaslat

Ha implementált egy áthidaló megoldást a HTML-formátumú sztringek kódolási problémájára (például a vágólapról lekért HTML-sztring explicit kódolásával System.Text.UTF8Encoding.GetString(Byte[], Int32, Int32)), és a 4-es verzióról a 4.5-ös verzióra továbbítja az alkalmazást, a kerülő megoldást el kell távolítani. Ha valamilyen okból a régi viselkedésre van szükség, az alkalmazás a .NET-keretrendszer 4.0-s verziót célozhatja meg ennek a viselkedésnek a lekéréséhez.

Név	Érték
Hatókör	Edge
verzió	4.5.2
Típus	Újracélzás

Érintett API-k

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

Windows Workflow Foundation (WF)

A WorkflowDesigner.Load nem távolítja el a szimbólumtulajdonságot

Részletek

Amikor a munkafolyamat-tervezőben a .NET-keretrendszer 4.5-ös verzióját célozzák meg, és a Load() metódussal egy újrahosztolt 3.5-ös munkafolyamatot töltenek be, mentéskor egy System.Xaml.XamlDuplicateMemberException kivétel keletkezik.

Javaslat

Ez a hiba csak akkor jelentkezik, ha a munkafolyamat-tervezőben a .NET-keretrendszer 4.5-ös verziója van megcélzva, így a 4.0 .NET-keretrendszerre való beállítással WorkflowDesigner.Context.Services.GetService<DesignerConfigurationService>().TargetFrameworkName megkerülhető.

A problémát elkerülheti, ha a munkafolyamat Load(String)betöltése helyett a Load() metódust használja.

Név	Érték
Hatókör	Őrnagy
verzió	4.5
Típus	Újracélzás

Érintett API-k

• WorkflowDesigner.Load()