Dela via

Oförenliga ändringar för migrering från .NET Framework till .NET Core

  • Artikel

Om du migrerar en app från .NET Framework till .NET Core versionerna 1.0 till 3.1 kan de brytpunktsförändringar som anges 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.

Anteckning

Den här artikeln är inte en fullständig lista över större förändringar mellan .NET Framework och .NET Core. De viktigaste ändringarna som bryter kompatibiliteten läggs till här när vi upptäcker dem.

De grundläggande .NET-biblioteken

.NET 8

IDispatchImplAttribute API tas bort

.NET Core 2.1

Ändra standardvärdet för UseShellExecute

ProcessStartInfo.UseShellExecute har standardvärdet false på .NET Core. På .NET Framework är standardvärdet true.

Ändra beskrivning

Process.Start kan du starta ett program direkt, till exempel med kod som Process.Start("mspaint.exe") som startar Paint. Du kan också indirekt starta ett associerat program om ProcessStartInfo.UseShellExecute är inställt på true. På .NET Framework är standardvärdet för ProcessStartInfo.UseShellExecutetrue, vilket innebär att kod som Process.Start("mytextfile.txt") startar Anteckningar om du har associerat .txt filer med redigeraren. 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 standardvärdet för ProcessStartInfo.UseShellExecutefalse. 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. Vanligtvis används Process.Start 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 för ProcessStartInfo.UseShellExecute till false. Du kan välja den långsammare sökvägen om du behöver den.

Version introducerad

2.1

Not

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

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

Kategori

.NET Core-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 kastas en UnauthorizedAccessException istället. (I .NET Core utlöses fortfarande en ArgumentException om anroparen försöker ange ett ogiltigt filattribut.)

Version infördes

1.0

Ändra eventuella catch-uttalanden för att fånga en UnauthorizedAccessException istället för, eller i tillägg till, en ArgumentException, efter behov.

Kategori

Core .NET-bibliotek

Berörda API:er

Hantering av korrupta tillståndsundantag stöds inte

Det är inte möjligt att hantera undantag för korrupt processstatus i .NET Core.

Ändra beskrivning

Tidigare kunde undantag för korrupt processtillstånd fångas upp och hanteras av undantagshanterare för hanterad kod, 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. Common Language Runtime levererar inte undantag för korrupta processstatus 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

.NET Core-bibliotek

Berörda API:er

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

UriBuilder.Fragment lägger inte längre till ett inledande # tecken och UriBuilder.Query lägger inte längre till ett inledande ? tecken när det redan finns.

Ändra beskrivning

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

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

Version införd

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 det resulterande värdet ????one=1&two=2&three=3&four=4.
  • I .NET Core så är resultatet ?one=1&two=2&three=3&four=4.

Kategori

Core .NET-biblioteken

Berörda API:er

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

Att läsa egenskapen Process.StartInfo för processer som din kod inte startade gör att en InvalidOperationExceptionutlöses.

Ändra beskrivning

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

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

Version släppt

1.0

Använd inte 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 parametern Booleskt silent för metoden SignedCms.ComputeSignature(CmsSigner, Boolean). 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 metoden SignedCms.ComputeSignature(CmsSigner, Boolean) 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 på truevisas 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 införd

3.0

Ändra beskrivning

Om inga LogicalName, ManifestResourceNameeller DependentUpon metadata angavs för ett EmbeddedResource objekt i projektfilen innan .NET Core 3.0 genererade MSBuild ett manifestfilnamn i mönstret <RootNamespace>.<ResourceFilePathFromProjectRoot>.resources. Om RootNamespace inte har definierats i projektfilen är projektnamnet som standard. Det genererade manifestnamnet för en resursfil med namnet Form1.resx i rotprojektkatalogen var till exempel 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 är samlokaliserat 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).

Not

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

Den här brytande ändringen introducerades genom att lägga till egenskapen EmbeddedResourceUseDependentUponConvention 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 du namnger den genererade .resources-filen. När EmbeddedResourceUseDependentUponConvention är inställt på true, som är standard, letar MSBuild efter en källfil placerad i samma katalog och extraherar ett namespace 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 till false i projektfilen.

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

Kategori

MSBuild

Berörda API:er

Ej tillämpligt

Nätverkande

.NET Core 2.0

WebClient.CancelAsync stoppar inte alltid omedelbart

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

Ändra beskrivning

Tidigare avbröt WebClient.CancelAsync() begäran omedelbart. Från och med .NET Core 2.0 avbryter anropet WebClient.CancelAsync() 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 WebClient-API:et är inaktuellt till förmån för HttpClient.

Version släpptes

2.0

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

Kategori

Nätverkande

Berörda API:er

Windows-formulär

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 kompatibilitetsbrytande ä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 lanserades

3.1

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

Borttagen styrning (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
Huvudmeny MenuStrip
Meny ToolStripDropDown, ToolStripDropDownMenu Menyobjektsamling
Menyobjekt ToolStripMenuItem
Verktygsfält ToolStrip Verktygsfältsutseende
Verktygsfältsknapp VerktygsradsKnapp ToolBarButtonClickEventArgs, ToolBarButtonClickEventHandler, ToolBarButtonStyle, ToolBarTextAlign

Kategori

Windows-formulär

Berörda API:er

Cellformateringshändelsen aktiveras inte om verktygstipset visas

En DataGridView visar nu en cels text- och feltips när markören svävar över och när den väljs via tangentbordet. Om en verktygstips visas, utlöses inte DataGridView.CellFormatting-händelsen.

Ändra beskrivning

Före .NET Core 3.1 visade en DataGridView som hade egenskapen ShowCellToolTips inställd på true ett verktygstips för en cells text och fel när muspekaren svävade över cellen. Verktygstips visades inte när en cell valdes med tangentbordet (till exempel genom att använda Tab-tangenten, genvägstangenter eller piltangenterna). Om användaren redigerade en cell och sedan, medan DataGridView fortfarande var i redigeringsläge, hovrade över en cell som inte hade egenskapen ToolTipText inställd, uppstod en CellFormatting händelse för att formatera cellens text för visning i cellen.

För att uppfylla tillgänglighetsstandarderna, från och med .NET Core 3.1, visar en DataGridView som har egenskapen ShowCellToolTips inställd på true 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 utlöses CellFormatting-händelsen inte när celler som inte har egenskapen ToolTipText inställd hovras medan DataGridView är i redigeringsläge. Händelsen aktiveras inte eftersom innehållet i den cell som pekas på visas som ett verktygstips i stället för att visas i cellen.

Version infördes

3.1

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

Kategori

Windows-formulär

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 riktlinjer 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 egenskapen ApplicationDefaultFont 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 anropa 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-formulär

Berörda API:er

Ingen.

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 Frameworket

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 egenskapen FolderBrowserDialog.AutoUpgradeEnabled till false innan du visar dialogrutan, vilket illustreras av följande kodfragment:

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

Kategori

Windows-formulär

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 scenarier med binär serialisering.

Ä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 på 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.

För mer information, se binär serialisering.

Version införd

3.0

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

Kategori

Windows-formulär

Berörda API:er

  • Ingen

AllowUpdateChildControlIndexForTabControls-kompatibilitetsväxeln stöds inte

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

Ändra beskrivning

I .NET Framework 4.6 och senare versioner ordnas kontrollsamlingen om när du väljer en flik. Med Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls kompatibilitetsväxel kan ett program hoppa över den här omordningen när det här beteendet är oönskat.

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-formulär

Berörda API:er

  • Ingen

DomainUpDown.UseLegacyScrolling-kompatibilitetsväxeln stöds inte

Den 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 Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling-kompatibilitetsväxlingen utvecklare att välja bort oberoende åtgärder för DomainUpDown.DownButton() och DomainUpDown.UpButton(). Växeln återställde det äldre beteendet, där DomainUpDown.UpButton() ignoreras om kontexttext finns, och utvecklaren måste använda DomainUpDown.DownButton() åtgärd på kontrollen innan åtgärden DomainUpDown.UpButton(). Mer information finns i <AppContextSwitchOverrides> element.

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

Version införd

3.0

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

Kategori

Windows-formulär

Berörda API:er

DoNotLoadLatestRichEditControl-kompatibilitetsväxeln stöds inte

Den 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 instansierar RichTextBox kontrollen Win32 RichEdit-kontrollen v3.0 och för program som riktar in sig på .NET Framework 4.7.1 instansierar RichTextBox kontrollen RichEdit v4.1 (i msftedit.dll). Den Switch.System.Windows.Forms.DoNotLoadLatestRichEditControl kompatibilitetsväxeln introducerades för att tillåta program som riktar sig mot .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 infördes

3.0

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

Kategori

Windows-formulär

Berörda API:er

DoNotSupportSelectAllShortcutInMultilineTextBox-kompatibilitetsväxeln stöds inte

Den 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 Ctrl + En genvägsnyckel i en TextBox kontroll markerade all text. I .NET Framework 4.6 och tidigare versioner kunde du inte välja Ctrl + En genvägsnyckel kunde inte markera all text om Textbox.ShortcutsEnabled och TextBox.Multiline egenskaper båda var inställda på true. Kompatibilitetsväxeln Switch.System.Windows.Forms.DoNotSupportSelectAllShortcutInMultilineTextBox introducerades i .NET Framework 4.6.1 för att behålla det ursprungliga beteendet. Mer information finns i TextBox.ProcessCmdKey.

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-formulär

Berörda API:er

  • Ingen

DontSupportReentrantFilterMessage-kompatibilitetsväxeln stöds inte

Den 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 Switch.System.Windows.Forms.DontSupportReentrantFilterMessage kompatibilitetsväxling 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.

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-formulär

Berörda API:er

EnableVisualStyleValidation-kompatibilitetsväxeln stöds inte

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

Ändra beskrivning

I .NET Framework tillät Switch.System.Windows.Forms.EnableVisualStyleValidation-kompatibilitetsväxeln en applikation att inte delta i valideringen av visuella format som tillhandahålls i numerisk form.

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-formulär

Berörda API:er

  • Ingen

Kompatibilitetsväxeln UseLegacyContextMenuStripSourceControlValue stöds inte

Den 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 gör Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue kompatibilitetsväxeln att utvecklaren kan välja bort det nya beteendet för egenskapen ContextMenuStrip.SourceControl, som nu returnerar en referens till källkontrollen. Det tidigare beteendet för egenskapen var att returnera null. Mer information finns i <AppContextSwitchOverrides> element.

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-formulär

Berörda API:er

UseLegacyImages kompatibilitetsväxel stöds inte

Kompatibilitetsväxeln Switch.System.Windows.Forms.UseLegacyImages, 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 åtgärdade Switch.System.Windows.Forms.UseLegacyImages kompatibilitetsväxeln möjliga problem med bildskalning i ClickOnce-scenarier i miljöer med hög DPI. När den är inställd på truetillåter växeln att användaren återställer äldre bildskalning på höga DPI-skärmar vars skala är inställd på större än 100%. Mer information finns i .NET Framework 4.8 Versionsinformation 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-formulär

Berörda API:er

  • Ingen

Både Om- och SplashScreen-mallar är brutna

De About.vb- och SplashScreen.vb filer som genereras av Visual Studio innehåller referenser till typer i My namnrymd 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. Referensegenskaperna i Om och SplashScreen formulärmallar i Visual Studio för Visual Basic Windows Forms-appar refererar till My.Application.Info-typen som inte är tillgänglig.

Stöd för Visual Basic My har förbättrats i .NET 5, uppgradera ditt projekt till .NET 5 eller senare.

-eller-

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

Tips

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 i Microsoft.VisualBasic.ApplicationServices namnområdet är inte tillgängliga.

Version införd

.NET Core 3.0

Ändra beskrivning

Typerna i Microsoft.VisualBasic.ApplicationServices 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, uppgradera ditt projekt 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. Vissa System.Environment och System.Security.Principal.WindowsIdentity medlemmar ger till exempel motsvarande funktioner till egenskaperna för klassen Microsoft.VisualBasic.ApplicationServices.User.

Kategori

Visual Basic

Berörda API:er

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

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

Version införd

.NET Core 3.0

Ändra beskrivning

Typerna i Microsoft.VisualBasic.Devices 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. Uppgradera ditt projekt 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. Motsvarande funktioner för klassen Microsoft.VisualBasic.Devices.Clock tillhandahålls till exempel av System.DateTime- och System.Environment-typerna, och motsvarande funktioner för klassen Microsoft.VisualBasic.Devices.Ports 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 i Microsoft.VisualBasic.MyServices namnområdet är inte tillgängliga.

Version introducerad

.NET Core 3.0

Ändra beskrivning

Typerna i Microsoft.VisualBasic.MyServices 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 assembliesberoenden eller bakåtkompatibilitetsändringar i efterföljande versioner.

Det här namnområdet lades till i .NET 5, så uppgradera ditt projekt 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 Microsoft.VisualBasic.MyServices typer till motsvarande .NET-klassbibliotekstyper:

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

Kategori

Visual Basic

Berörda API:er

Se även