Dela via

Icke-bakåtkompatibla ändringar för migrering från .NET Framework till .NET Core

  • Artikel

Om du migrerar en app från .NET Framework till .NET Core version 1.0 till 3.1 kan de icke-bakåtkompatibla ändringarna i den här artikeln påverka dig. Icke-bakåtkompatibla ändringar grupperas efter kategori och inom dessa kategorier efter den version av .NET Core som de introducerades i.

Kommentar

Den här artikeln är inte en fullständig lista över icke-bakåtkompatibla ändringar mellan .NET Framework och .NET Core. De viktigaste icke-bakåtkompatibla ändringarna läggs till här när vi blir medvetna om dem.

Core .NET-bibliotek

.NET 8

API:et IDispatchImplAttribute tas bort

.NET Core 2.1

Ändra standardvärdet för UseShellExecute

ProcessStartInfo.UseShellExecute har ett standardvärde false på på .NET Core. På .NET Framework är truestandardvärdet .

Ändra beskrivning

Process.Start låter dig starta ett program direkt, till exempel med kod som den som Process.Start("mspaint.exe") startar Paint. Du kan också indirekt starta ett associerat program om ProcessStartInfo.UseShellExecute det är inställt på true. På .NET Framework är standardvärdet för ProcessStartInfo.UseShellExecute , vilket innebär att kod som Process.Start("mytextfile.txt") startar Anteckningar, om du har associerat .txt filer med redigeraren.true Om du vill förhindra att en app startas indirekt på .NET Framework måste du uttryckligen ange ProcessStartInfo.UseShellExecute till false. På .NET Core är falsestandardvärdet för ProcessStartInfo.UseShellExecute . Det innebär att associerade program som standard inte startas när du anropar Process.Start.

Följande egenskaper på System.Diagnostics.ProcessStartInfo fungerar bara när ProcessStartInfo.UseShellExecute är true:

Den här ändringen introducerades i .NET Core av prestandaskäl. Process.Start Används vanligtvis för att starta ett program direkt. Att starta en app direkt behöver inte omfatta Windows-gränssnittet och medföra den associerade prestandakostnaden. För att göra det här standardfallet snabbare ändrar .NET Core standardvärdet ProcessStartInfo.UseShellExecute till false. Du kan välja den långsammare sökvägen om du behöver den.

Version introducerad

2.1

Kommentar

I tidigare versioner av .NET Core UseShellExecute implementerades inte för Windows.

Om din app förlitar sig på det gamla beteendet anropar Process.Start(ProcessStartInfo) du med UseShellExecute inställt true på på ProcessStartInfo objektet.

Kategori

Core .NET-bibliotek

Berörda API:er

.NET Core 1.0

UnauthorizedAccessException genereras av FileSystemInfo.Attributes

I .NET Core utlöses en UnauthorizedAccessException när anroparen försöker ange ett filattributvärde men inte har skrivbehörighet.

Ändra beskrivning

I .NET Framework utlöses en ArgumentException när anroparen försöker ange ett filattributvärde i FileSystemInfo.Attributes men inte har skrivbehörighet. I .NET Core genereras en UnauthorizedAccessException i stället. (I .NET Core utlöses fortfarande en ArgumentException om anroparen försöker ange ett ogiltigt filattribut.)

Version introducerad

1.0

Ändra eventuella catch instruktioner för att fånga en UnauthorizedAccessException i stället för, eller utöver, en ArgumentException, efter behov.

Kategori

Core .NET-bibliotek

Berörda API:er

Hantering av skadade tillståndsfel stöds inte

Det går inte att hantera feltillståndsfel i .NET Core.

Ändra beskrivning

Tidigare kunde undantag för skadat processtillstånd fångas upp och hanteras av hanterade kod undantagshanterare, till exempel med hjälp av en try-catch-instruktion i C#.

Från och med .NET Core 1.0 kan undantag för skadat processtillstånd inte hanteras av hanterad kod. Den vanliga språkkörningen levererar inte undantag för skadat processtillstånd till hanterad kod.

Version introducerad

1.0

Undvik behovet av att hantera undantag för skadade processer genom att ta itu med de situationer som leder till dem i stället. Om det är absolut nödvändigt att hantera undantag för skadat processtillstånd skriver du undantagshanteraren i C- eller C++-kod.

Kategori

Core .NET-bibliotek

Berörda API:er

UriBuilder-egenskaper förbereder inte längre inledande tecken

UriBuilder.Fragment förbereder inte längre ett ledande # tecken och UriBuilder.Query förbereder inte längre ett inledande ? tecken när ett redan finns.

Ändra beskrivning

I .NET Framework UriBuilder.Fragment förbereder egenskaperna och UriBuilder.Query alltid ett # eller ? -tecken till det värde som lagras. Det här beteendet kan resultera i flera # tecken eller ? tecken i det lagrade värdet om strängen redan innehåller något av dessa inledande tecken. Till exempel kan värdet för UriBuilder.Fragment bli ##main.

Från och med .NET Core 1.0 förbereder # dessa egenskaper inte längre tecknen eller ? till det lagrade värdet om det redan finns i början av strängen.

Version introducerad

1.0

Du behöver inte längre uttryckligen ta bort något av dessa inledande tecken när du anger egenskapsvärdena. Detta är särskilt användbart när du lägger till värden, eftersom du inte längre behöver ta bort inledande # eller ? varje gång du lägger till.

Följande kodfragment visar till exempel beteendeskillnaden mellan .NET Framework och .NET Core.

var builder = new UriBuilder();
builder.Query = "one=1";
builder.Query += "&two=2";
builder.Query += "&three=3";
builder.Query += "&four=4";

Console.WriteLine(builder.Query);
  • I .NET Framework är ????one=1&two=2&three=3&four=4utdata .
  • I .NET Core är ?one=1&two=2&three=3&four=4utdata .

Kategori

Core .NET-bibliotek

Berörda API:er

Process.StartInfo genererar InvalidOperationException för processer som du inte startade

När du Process.StartInfo läser egenskapen för processer som koden inte började genererar en InvalidOperationException.

Ändra beskrivning

I .NET Framework returnerar åtkomst till Process.StartInfo egenskapen för processer som koden inte startade ett dummy-objekt ProcessStartInfo . Dummy-objektet innehåller standardvärden för alla dess egenskaper utom EnvironmentVariables.

Från och med .NET Core 1.0, om du läser Process.StartInfo egenskapen för en process som du inte startade (dvs. genom att anropa Process.Start), genereras en InvalidOperationException .

Version introducerad

1.0

Kom inte åt egenskapen Process.StartInfo för processer som koden inte startade. Läs till exempel inte den här egenskapen för processer som returneras av Process.GetProcesses.

Kategori

Core .NET-bibliotek

Berörda API:er

Kryptografi

.NET Core 2.1

Boolesk parameter för SignedCms.ComputeSignature respekteras

I .NET Core respekteras den booleska silent parametern för SignedCms.ComputeSignature(CmsSigner, Boolean) metoden. En PIN-fråga visas inte om den här parametern är inställd på true.

Ändra beskrivning

I .NET Framework ignoreras parametern silent för SignedCms.ComputeSignature(CmsSigner, Boolean) metoden och en PIN-fråga visas alltid om det krävs av providern. I .NET Core respekteras parametern silent , och om den är inställd truepå visas aldrig en PIN-fråga, även om den krävs av providern.

Stöd för CMS/PKCS #7-meddelanden introducerades i .NET Core i version 2.1.

Version introducerad

2.1

För att säkerställa att en PIN-fråga visas om det behövs bör skrivbordsprogram anropa SignedCms.ComputeSignature(CmsSigner, Boolean) och ange den booleska parametern till false. Det resulterande beteendet är detsamma som i .NET Framework oavsett om den tysta kontexten är inaktiverad där.

Kategori

Kryptografi

Berörda API:er

MSBuild

.NET Core 3.0

Namnändring för resursmanifestfil

Från och med .NET Core 3.0 genererar MSBuild i standardfallet ett annat manifestfilnamn för resursfiler.

Version introducerad

3,0

Ändra beskrivning

Innan .NET Core 3.0, om inga , eller metadata angavs för ett EmbeddedResource objekt i projektfilen, genererade MSBuild ett manifestfilnamn i mönstret <RootNamespace>.<ResourceFilePathFromProjectRoot>.resources.DependentUpon ManifestResourceNameLogicalName Om RootNamespace inte har definierats i projektfilen är det som standard namnet på projektet. Till exempel var det genererade manifestnamnet för en resursfil med namnet Form1.resx i rotprojektkatalogen MyProject.Form1.resources.

Från och med .NET Core 3.0, om en resursfil samplaceras med en källfil med samma namn (till exempel Form1.resx och Form1.cs), använder MSBuild typinformation från källfilen för att generera manifestfilens namn i mönstret <Namespace>.<ClassName>.resources. Namnområdet och klassnamnet extraheras från den första typen i den samlokaliserade källfilen. Det genererade manifestnamnet för en resursfil med namnet Form1.resx som samlokaliserats med en källfil med namnet Form1.cs är MyNamespace.Form1.resources. Det viktigaste att notera är att den första delen av filnamnet skiljer sig från tidigare versioner av .NET Core (MyNamespace i stället för MyProject).

Kommentar

Om du har LogicalNameangett , ManifestResourceNameeller DependentUpon metadata för ett EmbeddedResource objekt i projektfilen påverkar inte den här ändringen resursfilen.

Den här icke-bakåtkompatibla ändringen introducerades med tillägget av EmbeddedResourceUseDependentUponConvention egenskapen till .NET Core-projekt. Som standard visas inte resursfiler uttryckligen i en .NET Core-projektfil, så de har inga DependentUpon metadata för att ange hur den genererade .resources-filen ska namnges. När EmbeddedResourceUseDependentUponConvention är inställt på true, vilket är standardinställningen, letar MSBuild efter en samlokaliserad källfil och extraherar ett namnområde och klassnamn från filen. Om du anger EmbeddedResourceUseDependentUponConvention till falsegenererar MSBuild manifestnamnet enligt det tidigare beteendet, som kombinerar RootNamespace och den relativa filsökvägen.

I de flesta fall krävs ingen åtgärd från utvecklarens sida, och din app bör fortsätta att fungera. Men om den här ändringen bryter din app kan du antingen:

  • Ändra koden så att den förväntar sig det nya manifestnamnet.

  • Avregistrera dig från den nya namngivningskonventionen genom att ange EmbeddedResourceUseDependentUponConvention i false projektfilen.

    <PropertyGroup>
  <EmbeddedResourceUseDependentUponConvention>false</EmbeddedResourceUseDependentUponConvention>
</PropertyGroup>

Kategori

MSBuild

Berörda API:er

Ej tillämpligt

Nätverk

.NET Core 2.0

WebClient.CancelAsync avbryts inte alltid omedelbart

Från och med .NET Core 2.0 WebClient.CancelAsync() avbryts inte begäran omedelbart om svaret har börjat hämtas.

Ändra beskrivning

Tidigare avbröts WebClient.CancelAsync() begäran omedelbart. Från och med .NET Core 2.0 WebClient.CancelAsync() avbryts begäran omedelbart endast om svaret inte har börjat hämtas. Om svaret har börjat hämtas avbryts begäran först när ett fullständigt svar har lästs.

Den här ändringen implementerades eftersom API:et WebClient är inaktuellt till förmån HttpClientför .

Version introducerad

2.0

System.Net.Http.HttpClient Använd klassen i stället för System.Net.WebClient, som är inaktuell.

Kategori

Nätverk

Berörda API:er

Windows Forms

Stöd för Windows Forms har lagts till i .NET Core i version 3.0. Om du migrerar en Windows Forms-app från .NET Framework till .NET Core kan de icke-bakåtkompatibla ändringarna som anges här påverka din app.

.NET Core 3.1

Borttagna kontroller

Från och med .NET Core 3.1 är vissa Windows Forms-kontroller inte längre tillgängliga.

Ändra beskrivning

Från och med .NET Core 3.1 är olika Windows Forms-kontroller inte längre tillgängliga. Ersättningskontroller som har bättre design och stöd introducerades i .NET Framework 2.0. De inaktuella kontrollerna har tidigare tagits bort från designerverktygslådor men var fortfarande tillgängliga för användning.

Följande typer är inte längre tillgängliga:

Version introducerad

3.1

Varje borttagen kontroll har en rekommenderad ersättningskontroll. Se följandet tabell:

Borttagen kontroll (API) Rekommenderad ersättning Associerade API:er som tas bort
ContextMenu ContextMenuStrip
Datagrid Datagridview DataGridCell, DataGridRow, DataGridTableCollection, DataGridColumnCollection, DataGridTableStyle, DataGridColumnStyle, DataGridLineStyle, DataGridParentRowsLabel, DataGridParentRowsLabelStyle, DataGridBoolColumn, DataGridTextBox, GridColumnStylesCollection, GridTableStylesCollection, HitTestType
MainMenu MenuStrip
Meny ToolStripDropDown, ToolStripDropDownMenu MenuItemCollection
Menuitem ToolStripMenuItem
Verktygsfältet Toolstrip ToolBarAppearance
ToolBarButton ToolStripButton ToolBarButtonClickEventArgs, ToolBarButtonClickEventHandler, ToolBarButtonStyle, ToolBarTextAlign

Kategori

Windows Forms

Berörda API:er

CellFormateringshändelsen aktiveras inte om knappbeskrivningen visas

A DataGridView visar nu en cells text- och felknappbeskrivningar när den hovras av en mus och när den väljs via tangentbordet. Om en knappbeskrivning visas DataGridView.CellFormatting utlöses inte händelsen.

Ändra beskrivning

Före .NET Core 3.1 visade en DataGridView som hade ShowCellToolTips egenskapen inställd på true en knappbeskrivning för en cells text och fel när cellen hovrades av en mus. Knappbeskrivningar visades inte när en cell valdes via tangentbordet (till exempel med hjälp av tabbtangenten, genvägstangenterna eller pilnavigering). Om användaren redigerade en cell och sedan, medan den DataGridView fortfarande var i redigeringsläge, hovrade över en cell som inte hade ToolTipText egenskapen inställd, skapades en CellFormatting händelse för att formatera cellens text för visning i cellen.

För att uppfylla tillgänglighetsstandarder, med början i .NET Core 3.1, en DataGridView som har ShowCellToolTips egenskapen inställd på true visar knappbeskrivningar för en cells text och fel inte bara när cellen hovrar, utan även när den väljs via tangentbordet. Till följd av den här ändringen CellFormatting utlöses inte händelsen när celler som inte har egenskapsuppsättningen ToolTipText hovras medan den DataGridView är i redigeringsläge. Händelsen aktiveras inte eftersom innehållet i den hovrade cellen visas som en knappbeskrivning i stället för att visas i cellen.

Version introducerad

3.1

Omstrukturera all kod som är beroende av CellFormatting händelsen medan den DataGridView är i redigeringsläge.

Kategori

Windows Forms

Berörda API:er

Ingen

.NET Core 3.0

Standardkontrollteckensnittet har ändrats till Segoe UI 9 pt

Ändra beskrivning

I .NET Framework har egenskapen Control.DefaultFont angetts till Microsoft Sans Serif 8.25 pt. Följande bild visar ett fönster som använder standardteckensnittet.

Standardkontrollteckensnitt i .NET Framework

Från och med .NET Core 3.0 är standardteckensnittet inställt på Segoe UI 9 pt (samma teckensnitt som SystemFonts.MessageBoxFont). Som ett resultat av den här ändringen är formulär och kontroller ungefär 27 % större för att ta hänsyn till den större storleken på det nya standardteckensnittet. Till exempel:

Standardkontrollteckensnitt i .NET Core

Den här ändringen gjordes i enlighet med riktlinjerna för Windows-användarupplevelse (UX).

Version introducerad

3,0

På grund av ändringen i storleken på formulär och kontroller kontrollerar du att programmet renderas korrekt.

Om du vill behålla det ursprungliga teckensnittet för ett enskilt formulär anger du standardteckensnittet till Microsoft Sans Serif 8.25 pt. Till exempel:

public MyForm()
{
    InitializeComponent();
    Font = new Font(new FontFamily("Microsoft Sans Serif"), 8.25f);
}

Du kan också ändra standardteckensnittet för ett helt program på något av följande sätt:

  • Genom att ange ApplicationDefaultFont egenskapen MSBuild till "Microsoft Sans Serif, 8.25pt". Det här är den bästa tekniken eftersom det gör att Visual Studio kan använda de nya inställningarna i designern.

    <PropertyGroup>
  <ApplicationDefaultFont>Microsoft Sans Serif, 8.25pt</ApplicationDefaultFont>
</PropertyGroup>

  • Genom att ringa Application.SetDefaultFont(Font).

    class Program
{
    [STAThread]
    static void Main()
    {
        Application.EnableVisualStyles();
        Application.SetCompatibleTextRenderingDefault(false);
        Application.SetHighDpiMode(HighDpiMode.SystemAware);
        Application.SetDefaultFont(new Font(new FontFamily("Microsoft Sans Serif"), 8.25f));
        Application.Run(new Form1());
    }
}

Kategori

  • Windows Forms

Berörda API:er

Inga.

Modernisering av FolderBrowserDialog

Kontrollen FolderBrowserDialog har ändrats i Windows Forms-program för .NET Core.

Ändra beskrivning

I .NET Framework använder Windows-formulär följande dialogruta för FolderBrowserDialog kontrollen:

FolderBrowserDialogControl i .NET Framework

I .NET Core 3.0 använder Windows Forms en nyare COM-baserad kontroll som introducerades i Windows Vista:

FolderBrowserDialogControl i .NET Core

Version introducerad

3,0

Dialogrutan uppgraderas automatiskt.

Om du vill behålla den ursprungliga dialogrutan anger du FolderBrowserDialog.AutoUpgradeEnabled egenskapen till false innan du visar dialogrutan, vilket illustreras av följande kodfragment:

var dialog = new FolderBrowserDialog();
dialog.AutoUpgradeEnabled = false;
dialog.ShowDialog();

Kategori

Windows Forms

Berörda API:er

SerializableAttribute har tagits bort från vissa Typer av Windows-formulär

SerializableAttribute Har tagits bort från vissa Windows Forms-klasser som inte har några kända binära serialiseringsscenarier.

Ändra beskrivning

Följande typer är dekorerade med SerializableAttribute i .NET Framework, men attributet har tagits bort i .NET Core:

Tidigare har den här serialiseringsmekanismen haft allvarliga underhålls- och säkerhetsproblem. Att underhålla SerializableAttribute typer innebär att dessa typer måste testas för serialiseringsändringar från version till version och potentiellt serialiseringsändringar från ramverk till ramverk. Detta gör det svårare att utveckla dessa typer och kan vara kostsamt att underhålla. Dessa typer har inga kända scenarier för binär serialisering, vilket minimerar effekten av att ta bort attributet.

Mer information finns i Binär serialisering.

Version introducerad

3,0

Uppdatera all kod som kan vara beroende av att dessa typer markeras som serialiserbara.

Kategori

Windows Forms

Berörda API:er

  • Ingen

AllowUpdateChildControlIndexForTabControls-kompatibilitetsväxeln stöds inte

Kompatibilitetsväxeln Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls stöds i Windows Forms på .NET Framework 4.6 och senare versioner men stöds inte på .NET Core eller .NET 5.0 och senare.

Ändra beskrivning

Om du väljer en flik i .NET Framework 4.6 och senare versioner ordnas dess kontrollsamling om genom att välja en flik. Med Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls kompatibilitetsväxeln kan ett program hoppa över den här omordningen när det här beteendet inte är önskvärt.

I .NET Core och .NET 5.0 och senare stöds inte växeln Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls .

Version introducerad

3,0

Ta bort växeln. Växeln stöds inte och inga alternativa funktioner är tillgängliga.

Kategori

Windows Forms

Berörda API:er

  • Ingen

DomainUpDown.UseLegacyScrolling-kompatibilitetsväxeln stöds inte

Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling Kompatibilitetsväxeln, som introducerades i .NET Framework 4.7.1, stöds inte i Windows Forms på .NET Core eller .NET 5.0 och senare.

Ändra beskrivning

Från och med .NET Framework 4.7.1 tillät kompatibilitetsväxlingen Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling utvecklare att välja bort oberoende DomainUpDown.DownButton() åtgärder och DomainUpDown.UpButton() åtgärder. Växeln återställde det äldre beteendet, där DomainUpDown.UpButton() ignoreras om kontexttext finns, och utvecklaren måste använda DomainUpDown.DownButton() åtgärden på kontrollen före åtgärden DomainUpDown.UpButton() . Mer information finns i <Elementet AppContextSwitchOverrides>.

I .NET Core och .NET 5.0 och senare stöds inte växeln Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling .

Version introducerad

3,0

Ta bort växeln. Växeln stöds inte och inga alternativa funktioner är tillgängliga.

Kategori

Windows Forms

Berörda API:er

DoNotLoadLatestRichEditControl-kompatibilitetsväxeln stöds inte

Switch.System.Windows.Forms.UseLegacyImages Kompatibilitetsväxeln, som introducerades i .NET Framework 4.7.1, stöds inte i Windows Forms på .NET Core eller .NET 5.0 och senare.

Ändra beskrivning

I .NET Framework 4.6.2 och tidigare versioner RichTextBox instansierar kontrollen Win32 RichEdit-kontrollen v3.0 och för program som riktar sig mot .NET Framework 4.7.1 RichTextBox instansierar kontrollen RichEdit v4.1 (i msftedit.dll). Switch.System.Windows.Forms.DoNotLoadLatestRichEditControl Kompatibilitetsväxeln introducerades för att tillåta program som riktar in sig på .NET Framework 4.7.1 och senare versioner att välja bort den nya RichEdit v4.1-kontrollen och använda den gamla RichEdit v3-kontrollen i stället.

I .NET Core- och .NET 5.0- och senare versioner stöds inte växeln Switch.System.Windows.Forms.DoNotLoadLatestRichEditControl . Endast nya versioner av RichTextBox kontrollen stöds.

Version introducerad

3,0

Ta bort växeln. Växeln stöds inte och inga alternativa funktioner är tillgängliga.

Kategori

Windows Forms

Berörda API:er

DoNotSupportSelectAllShortcutInMultilineTextBox-kompatibilitetsväxeln stöds inte

Switch.System.Windows.Forms.DoNotSupportSelectAllShortcutInMultilineTextBox Kompatibilitetsväxeln, som introducerades i .NET Framework 4.6.1, stöds inte i Windows Forms på .NET Core och .NET 5.0 och senare.

Ändra beskrivning

Från och med .NET Framework 4.6.1 väljer du tangenten Ctrl + A-genväg i en TextBox kontroll markerad all text. I .NET Framework 4.6 och tidigare versioner kunde du inte markera + all text om egenskaperna Textbox.ShortcutsEnabled och TextBox.Multiline båda var inställda på .true Switch.System.Windows.Forms.DoNotSupportSelectAllShortcutInMultilineTextBox Kompatibilitetsväxeln introducerades i .NET Framework 4.6.1 för att behålla det ursprungliga beteendet. Se TextBox.ProcessCmdKey för mer information.

I .NET Core- och .NET 5.0- och senare versioner stöds inte växeln Switch.System.Windows.Forms.DoNotSupportSelectAllShortcutInMultilineTextBox .

Version introducerad

3,0

Ta bort växeln. Växeln stöds inte och inga alternativa funktioner är tillgängliga.

Kategori

Windows Forms

Berörda API:er

  • Ingen

DontSupportReentrantFilterMessage-kompatibilitetsväxeln stöds inte

Switch.System.Windows.Forms.DontSupportReentrantFilterMessage Kompatibilitetsväxeln, som introducerades i .NET Framework 4.6.1, stöds inte i Windows Forms på .NET Core och .NET 5.0 och senare.

Ändra beskrivning

Från och med .NET Framework 4.6.1 löser kompatibilitetsväxlingen Switch.System.Windows.Forms.DontSupportReentrantFilterMessage möjliga IndexOutOfRangeException undantag när Application.FilterMessage meddelandet anropas med en anpassad IMessageFilter.PreFilterMessage implementering. Mer information finns i Mitigation: Custom IMessageFilter.PreFilterMessage Implementations (Åtgärd: Anpassade IMessageFilter.PreFilterMessage-implementeringar).

I .NET Core och .NET 5.0 och senare stöds inte växeln Switch.System.Windows.Forms.DontSupportReentrantFilterMessage .

Version introducerad

3,0

Ta bort växeln. Växeln stöds inte och inga alternativa funktioner är tillgängliga.

Kategori

Windows Forms

Berörda API:er

EnableVisualStyleValidation-kompatibilitetsväxeln stöds inte

Switch.System.Windows.Forms.EnableVisualStyleValidation Kompatibilitetsväxeln stöds inte i Windows Forms på .NET Core eller .NET 5.0 och senare.

Ändra beskrivning

I .NET Framework tillät kompatibilitetsväxeln Switch.System.Windows.Forms.EnableVisualStyleValidation ett program att välja bort validering av visuella format som tillhandahålls i ett numeriskt formulär.

I .NET Core och .NET 5.0 och senare stöds inte växeln Switch.System.Windows.Forms.EnableVisualStyleValidation .

Version introducerad

3,0

Ta bort växeln. Växeln stöds inte och inga alternativa funktioner är tillgängliga.

Kategori

Windows Forms

Berörda API:er

  • Ingen

Kompatibilitetsväxeln UseLegacyContextMenuStripSourceControlValue stöds inte

Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue Kompatibilitetsväxeln, som introducerades i .NET Framework 4.7.2, stöds inte i Windows Forms på .NET Core eller .NET 5.0 och senare.

Ändra beskrivning

Från och med .NET Framework 4.7.2 Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue gör kompatibilitetsväxlingen att utvecklaren kan välja bort det nya beteendet för ContextMenuStrip.SourceControl egenskapen, som nu returnerar en referens till källkontrollen. Det tidigare beteendet för egenskapen var att returnera null. Mer information finns i <Elementet AppContextSwitchOverrides>.

I .NET Core och .NET 5.0 och senare stöds inte växeln Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue .

Version introducerad

3,0

Ta bort växeln. Växeln stöds inte och inga alternativa funktioner är tillgängliga.

Kategori

Windows Forms

Berörda API:er

UseLegacyImages kompatibilitetsväxel stöds inte

Switch.System.Windows.Forms.UseLegacyImages Kompatibilitetsväxeln, som introducerades i .NET Framework 4.8, stöds inte i Windows Forms på .NET Core eller .NET 5.0 och senare.

Ändra beskrivning

Från och med .NET Framework 4.8 Switch.System.Windows.Forms.UseLegacyImages åtgärdade kompatibilitetsväxeln möjliga problem med bildskalning i ClickOnce-scenarier i miljöer med hög DPI. När inställningen är inställd truepå gör växeln att användaren kan återställa äldre bildskalning på höga DPI-skärmar vars skala är inställd på större än 100 %. Mer information finns i Viktig information om .NET Framework 4.8 på GitHub.

I .NET Core och .NET 5.0 och senare stöds inte växeln Switch.System.Windows.Forms.UseLegacyImages .

Version introducerad

3,0

Ta bort växeln. Växeln stöds inte och inga alternativa funktioner är tillgängliga.

Kategori

Windows Forms

Berörda API:er

  • Ingen

Om och SplashScreen-mallar är brutna

Filerna About.vb och SplashScreen.vb som genereras av Visual Studio innehåller referenser till typer i My namnområdet som inte är tillgängliga .NET Core 3.0 och 3.1.

Version introducerad

3,0

Ändra beskrivning

.NET Core 3.0 och 3.1 innehåller inte fullständigt Stöd för Visual Basic My . Formulärmallarna Om och SplashScreen i Visual Studio för Visual Basic Windows Forms-appar refererar till egenskaper i den My.Application.Info typ som inte är tillgängliga.

Visual Basic-stödet My har förbättrats i .NET 5, uppgradera projektet till .NET 5 eller senare.

-eller-

Åtgärda kompilatorfelen i typerna Om och SplashScreen i din app. System.Reflection.Assembly Använd klassen för att hämta den information som tillhandahålls av My.Application.Info typen . En rak port för båda formulären finns här.

Dricks

Det här är exempelkod och ej optimerad. Listan över attribut ska cachelagras för att minska tiden för formulärinläsning.

Om

Imports System.Reflection

Public NotInheritable Class About

    Private Sub about_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        ' Set the title of the form.
        Dim applicationTitle As String = Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyTitleAttribute)()?.Title

        If String.IsNullOrEmpty(applicationTitle) Then
            applicationTitle = System.IO.Path.GetFileNameWithoutExtension(Assembly.GetExecutingAssembly().GetName().Name)
        End If

        Me.Text = String.Format("About {0}", applicationTitle)
        ' Initialize all of the text displayed on the About Box.
        ' TODO: Customize the application's assembly information in the "Application" pane of the project
        '    properties dialog (under the "Project" menu).
        Me.LabelProductName.Text = If(Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyProductAttribute)()?.Product, "")
        Me.LabelVersion.Text = String.Format("Version {0}", Assembly.GetExecutingAssembly().GetName().Version)
        Me.LabelCopyright.Text = If(Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyCopyrightAttribute)()?.Copyright, "")
        Me.LabelCompanyName.Text = If(Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyCompanyAttribute)()?.Company, "")
        Me.TextBoxDescription.Text = If(Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyDescriptionAttribute)()?.Description, "")
    End Sub

    Private Sub OKButton_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles OKButton.Click
        Me.Close()
    End Sub

End Class

Splashscreen

Imports System.Reflection

Public NotInheritable Class SplashScreen

    Private Sub SplashScreen1_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
        'Set up the dialog text at runtime according to the application's assembly information.  

        'TODO: Customize the application's assembly information in the "Application" pane of the project
        '  properties dialog (under the "Project" menu).

        'Application title
        Dim appTitle As String = Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyTitleAttribute)()?.Title

        If String.IsNullOrEmpty(appTitle) Then
            appTitle = System.IO.Path.GetFileNameWithoutExtension(Assembly.GetExecutingAssembly().GetName().Name)
        End If

        ApplicationTitle.Text = appTitle

        Dim versionValue = Assembly.GetExecutingAssembly().GetName().Version

        'Format the version information using the text set into the Version control at design time as the
        '  formatting string.  This allows for effective localization if desired.
        '  Build and revision information could be included by using the following code and changing the
        '  Version control's designtime text to "Version {0}.{1:00}.{2}.{3}" or something similar.  See
        '  String.Format() in Help for more information.
        '
        '    Version.Text = System.String.Format(Version.Text, versionValue.Major, versionValue.Minor, versionValue.Build, versionValue.Revision)

        Version.Text = System.String.Format(Version.Text, versionValue.Major, versionValue.Minor)

        'Copyright info
        Copyright.Text = If(Assembly.GetExecutingAssembly().GetCustomAttribute(Of AssemblyCopyrightAttribute)()?.Copyright, "")
    End Sub

End Class

Kategori

Visual Basic Windows Forms

Berörda API:er

Ingen

Typer i namnområdet Microsoft.VisualBasic.ApplicationServices är inte tillgängliga

Typerna Microsoft.VisualBasic.ApplicationServices i namnområdet är inte tillgängliga.

Version introducerad

.NET Core 3.0

Ändra beskrivning

Typerna Microsoft.VisualBasic.ApplicationServices i namnområdet var tillgängliga i .NET Framework. De är inte tillgängliga i .NET Core 3.0 – 3.1.

Typerna togs bort för att undvika onödiga sammansättningsberoenden eller icke-bakåtkompatibla ändringar i efterföljande versioner.

Det här namnområdet lades till i .NET 5 och uppgraderar projektet till .NET 5 eller senare.

-eller-

Om koden är beroende av användningen av Microsoft.VisualBasic.ApplicationServices typer och deras medlemmar kan du kanske använda en motsvarande typ eller medlem i .NET-klassbiblioteket. Till exempel ger vissa System.Environment medlemmar och System.Security.Principal.WindowsIdentity medlemmar motsvarande funktioner till klassens Microsoft.VisualBasic.ApplicationServices.User egenskaper.

Kategori

Visual Basic

Berörda API:er

Typer i Microsoft.VisualBasic.Devices-namnområdet är inte tillgängligt

Typerna Microsoft.VisualBasic.Devices i namnområdet är inte tillgängliga.

Version introducerad

.NET Core 3.0

Ändra beskrivning

Typerna Microsoft.VisualBasic.Devices i namnområdet var tillgängliga i .NET Framework. De är inte tillgängliga i .NET Core 3.0 – 3.1.

Typerna togs bort för att undvika onödiga sammansättningsberoenden eller icke-bakåtkompatibla ändringar i efterföljande versioner.

Det här namnområdet lades till i .NET 5 och uppgraderar projektet till .NET 5 eller senare.

-eller-

Om koden är beroende av användningen av Microsoft.VisualBasic.Devices typer och deras medlemmar kan du kanske använda en motsvarande typ eller medlem i .NET-klassbiblioteket. Till exempel tillhandahålls motsvarande funktioner i Microsoft.VisualBasic.Devices.Clock klassen av typerna System.DateTime och System.Environment , och motsvarande funktioner för Microsoft.VisualBasic.Devices.Ports klassen tillhandahålls av typer i System.IO.Ports namnområdet.

Kategori

Visual Basic

Berörda API:er

Typer i namnområdet Microsoft.VisualBasic.MyServices är inte tillgängliga

Typerna Microsoft.VisualBasic.MyServices i namnområdet är inte tillgängliga.

Version introducerad

.NET Core 3.0

Ändra beskrivning

Typerna Microsoft.VisualBasic.MyServices i namnområdet var tillgängliga i .NET Framework. De är inte tillgängliga i .NET Core 3.0 – 3.1.

Typerna togs bort för att undvika onödiga sammansättningsberoenden eller icke-bakåtkompatibla ändringar i efterföljande versioner.

Det här namnområdet lades till i .NET 5 och uppgraderar projektet till .NET 5 eller senare.

-eller-

Om koden är beroende av användningen av Microsoft.VisualBasic.MyServices-typer och deras medlemmar finns det motsvarande typer och medlemmar i .NET-klassbiblioteket. Följande är en mappning av typerna Microsoft.VisualBasic.MyServices till motsvarande .NET-klassbibliotekstyper:

Microsoft.VisualBasic.MyServices-typ .NET-klassbibliotekstyp
ClipboardProxy System.Windows.Clipboard för WPF-program för System.Windows.Forms.Clipboard Windows Forms-program
FileSystemProxy Typer i System.IO namnområdet
RegistryProxy Registerrelaterade typer i Microsoft.Win32 namnområdet
SpecialDirectoriesProxy Environment.GetFolderPath

Kategori

Visual Basic

Berörda API:er

Se även