Breaking changes for migration from .NET Framework to .NET Core
If you're migrating an app from .NET Framework to .NET Core versions 1.0 through 3.1, the breaking changes listed in this article might affect you. Breaking changes are grouped by category, and within those categories, by the version of .NET Core in which they were introduced.
Note
This article is not a complete list of breaking changes between .NET Framework and .NET Core. The most important breaking changes are added here as we become aware of them.
- Change in default value of UseShellExecute
- IDispatchImplAttribute API is removed
- UnauthorizedAccessException thrown by FileSystemInfo.Attributes
- Handling corrupted-process-state exceptions is not supported
- UriBuilder properties no longer prepend leading characters
- Process.StartInfo throws InvalidOperationException for processes you didn't start
IDispatchImplAttribute API is removed
ProcessStartInfo.UseShellExecute has a default value of false
on .NET Core. On .NET Framework, its default value is true
.
Process.Start lets you launch an application directly, for example, with code such as Process.Start("mspaint.exe")
that launches Paint. It also lets you indirectly launch an associated application if ProcessStartInfo.UseShellExecute is set to true
. On .NET Framework, the default value for ProcessStartInfo.UseShellExecute is true
, meaning that code such as Process.Start("mytextfile.txt")
would launch Notepad, if you've associated .txt files with that editor. To prevent indirectly launching an app on .NET Framework, you must explicitly set ProcessStartInfo.UseShellExecute to false
. On .NET Core, the default value for ProcessStartInfo.UseShellExecute is false
. This means that, by default, associated applications are not launched when you call Process.Start
.
The following properties on System.Diagnostics.ProcessStartInfo are only functional when ProcessStartInfo.UseShellExecute is true
:
- ProcessStartInfo.CreateNoWindow
- ProcessStartInfo.ErrorDialog
- ProcessStartInfo.Verb
- ProcessStartInfo.WindowStyle.
This change was introduced in .NET Core for performance reasons. Typically, Process.Start is used to launch an application directly. Launching an app directly does not need to involve the Windows shell and incur the associated performance cost. To make this default case faster, .NET Core changes the default value of ProcessStartInfo.UseShellExecute to false
. You can opt in to the slower path if you need it.
2.1
Note
In earlier versions of .NET Core, UseShellExecute
was not implemented for Windows.
If your app relies on the old behavior, call Process.Start(ProcessStartInfo) with UseShellExecute set to true
on the ProcessStartInfo object.
Core .NET libraries
In .NET Core, an UnauthorizedAccessException is thrown when the caller attempts to set a file attribute value but doesn't have write permission.
In .NET Framework, an ArgumentException is thrown when the caller attempts to set a file attribute value in FileSystemInfo.Attributes but doesn't have write permission. In .NET Core, an UnauthorizedAccessException is thrown instead. (In .NET Core, an ArgumentException is still thrown if the caller attempts to set an invalid file attribute.)
1.0
Modify any catch
statements to catch an UnauthorizedAccessException instead of, or in addition to, an ArgumentException, as necessary.
Core .NET libraries
Handling corrupted-process-state exceptions in .NET Core is not supported.
Previously, corrupted-process-state exceptions could be caught and handled by managed code exception handlers, for example, by using a try-catch statement in C#.
Starting in .NET Core 1.0, corrupted-process-state exceptions cannot be handled by managed code. The common language runtime doesn't deliver corrupted-process-state exceptions to managed code.
1.0
Avoid the need to handle corrupted-process-state exceptions by addressing the situations that lead to them instead. If it's absolutely necessary to handle corrupted-process-state exceptions, write the exception handler in C or C++ code.
Core .NET libraries
- System.Runtime.ExceptionServices.HandleProcessCorruptedStateExceptionsAttribute
- legacyCorruptedStateExceptionsPolicy element
UriBuilder.Fragment no longer prepends a leading #
character and UriBuilder.Query no longer prepends a leading ?
character when one is already present.
In .NET Framework, the UriBuilder.Fragment and UriBuilder.Query properties always prepend a #
or ?
character, respectively, to the value being stored. This behavior can result in multiple #
or ?
characters in the stored value if the string already contains one of these leading characters. For example, the value of UriBuilder.Fragment might become ##main
.
Starting in .NET Core 1.0, these properties no longer prepend the #
or ?
characters to the stored value if one is already present at the beginning of the string.
1.0
You no longer need to explicitly remove any of these leading characters when setting the property values. This is especially useful when you're appending values, because you no longer have to remove the leading #
or ?
each time you append.
For example, the following code snippet shows the behavior difference between .NET Framework and .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);
- In .NET Framework, the output is
????one=1&two=2&three=3&four=4
. - In .NET Core, the output is
?one=1&two=2&three=3&four=4
.
Core .NET libraries
Reading the Process.StartInfo property for processes that your code didn't start throws an InvalidOperationException.
In .NET Framework, accessing the Process.StartInfo property for processes that your code didn't start returns a dummy ProcessStartInfo object. The dummy object contains default values for all of its properties except EnvironmentVariables.
Starting in .NET Core 1.0, if you read the Process.StartInfo property for a process that you didn't start (that is, by calling Process.Start), an InvalidOperationException is thrown.
1.0
Do not access the Process.StartInfo property for processes that your code didn't start. For example, don't read this property for processes returned by Process.GetProcesses.
Core .NET libraries
In .NET Core, the Boolean silent
parameter of the SignedCms.ComputeSignature(CmsSigner, Boolean) method is respected. A PIN prompt is not shown if this parameter is set to true
.
In .NET Framework, the silent
parameter of the SignedCms.ComputeSignature(CmsSigner, Boolean) method is ignored, and a PIN prompt is always shown if required by the provider. In .NET Core, the silent
parameter is respected, and if set to true
, a PIN prompt is never shown, even if it's required by the provider.
Support for CMS/PKCS #7 messages was introduced into .NET Core in version 2.1.
2.1
To ensure a PIN prompt appears if required, desktop applications should call SignedCms.ComputeSignature(CmsSigner, Boolean) and set the Boolean parameter to false
. The resulting behavior is the same as on .NET Framework regardless of whether the silent context is disabled there.
Cryptography
Starting in .NET Core 3.0, in the default case, MSBuild generates a different manifest file name for resource files.
3.0
Prior to .NET Core 3.0, if no LogicalName
, ManifestResourceName
, or DependentUpon
metadata was specified for an EmbeddedResource
item in the project file, MSBuild generated a manifest file name in the pattern <RootNamespace>.<ResourceFilePathFromProjectRoot>.resources
. If RootNamespace
is not defined in the project file, it defaults to the project name. For example, the generated manifest name for a resource file named Form1.resx in the root project directory was MyProject.Form1.resources.
Starting in .NET Core 3.0, if a resource file is colocated with a source file of the same name (for example, Form1.resx and Form1.cs), MSBuild uses type information from the source file to generate the manifest file name in the pattern <Namespace>.<ClassName>.resources
. The namespace and class name are extracted from the first type in the colocated source file. For example, the generated manifest name for a resource file named Form1.resx that's colocated with a source file named Form1.cs is MyNamespace.Form1.resources. The key thing to note is that the first part of the file name is different to prior versions of .NET Core (MyNamespace instead of MyProject).
Note
If you have LogicalName
, ManifestResourceName
, or DependentUpon
metadata specified on an EmbeddedResource
item in the project file, then this change does not affect that resource file.
This breaking change was introduced with the addition of the EmbeddedResourceUseDependentUponConvention
property to .NET Core projects. By default, resource files aren't explicitly listed in a .NET Core project file, so they have no DependentUpon
metadata to specify how to name the generated .resources file. When EmbeddedResourceUseDependentUponConvention
is set to true
, which is the default, MSBuild looks for a colocated source file and extracts a namespace and class name from that file. If you set EmbeddedResourceUseDependentUponConvention
to false
, MSBuild generates the manifest name according to the previous behavior, which combines RootNamespace
and the relative file path.
In most cases, no action is required on the part of the developer, and your app should continue to work. However, if this change breaks your app, you can either:
Change your code to expect the new manifest name.
Opt out of the new naming convention by setting
EmbeddedResourceUseDependentUponConvention
tofalse
in your project file.XML<PropertyGroup> <EmbeddedResourceUseDependentUponConvention>false</EmbeddedResourceUseDependentUponConvention> </PropertyGroup>
MSBuild
N/A
Starting in .NET Core 2.0, calling WebClient.CancelAsync() doesn't cancel the request immediately if the response has started to fetch.
Previously, calling WebClient.CancelAsync() canceled the request immediately. Starting in .NET Core 2.0, calling WebClient.CancelAsync() cancels the request immediately only if the response hasn't started fetching. If the response has started to fetch, the request is cancelled only after a complete response is read.
This change was implemented because the WebClient API is deprecated in favor of HttpClient.
2.0
Use the System.Net.Http.HttpClient class instead of System.Net.WebClient, which is deprecated.
Networking
Windows Forms support was added to .NET Core in version 3.0. If you're migrating a Windows Forms app from .NET Framework to .NET Core, the breaking changes listed here might affect your app.
- Removed controls
- CellFormatting event not raised if tooltip is shown
- Control.DefaultFont changed to Segoe UI 9 pt
- Modernization of the FolderBrowserDialog
- SerializableAttribute removed from some Windows Forms types
- AllowUpdateChildControlIndexForTabControls compatibility switch not supported
- DomainUpDown.UseLegacyScrolling compatibility switch not supported
- DoNotLoadLatestRichEditControl compatibility switch not supported
- DoNotSupportSelectAllShortcutInMultilineTextBox compatibility switch not supported
- DontSupportReentrantFilterMessage compatibility switch not supported
- EnableVisualStyleValidation compatibility switch not supported
- UseLegacyContextMenuStripSourceControlValue compatibility switch not supported
- UseLegacyImages compatibility switch not supported
- About and SplashScreen templates are broken for Visual Basic
- Types in Microsoft.VisualBasic.ApplicationServices namespace not available
- Types in Microsoft.VisualBasic.Devices namespace not available
- Types in Microsoft.VisualBasic.MyServices namespace not available
Starting in .NET Core 3.1, some Windows Forms controls are no longer available.
Starting with .NET Core 3.1, various Windows Forms controls are no longer available. Replacement controls that have better design and support were introduced in .NET Framework 2.0. The deprecated controls were previously removed from designer toolboxes but were still available to be used.
The following types are no longer available:
- ContextMenu
- DataGrid
- DataGrid.HitTestType
- DataGrid.HitTestInfo
- DataGridBoolColumn
- DataGridCell
- DataGridColumnStyle
- DataGridColumnStyle.DataGridColumnHeaderAccessibleObject
- DataGridColumnStyle.CompModSwitches
- DataGridLineStyle
- DataGridParentRowsLabelStyle
- DataGridPreferredColumnWidthTypeConverter
- DataGridTableStyle
- DataGridTextBox
- DataGridTextBoxColumn
- GridColumnStylesCollection
- GridTablesFactory
- GridTableStylesCollection
- IDataGridEditingService
- IMenuEditorService
- MainMenu
- Menu
- Menu.MenuItemCollection
- MenuItem
- ToolBar
- ToolBarAppearance
- ToolBarButton
- ToolBar.ToolBarButtonCollection
- ToolBarButtonClickEventArgs
- ToolBarButtonStyle
- ToolBarTextAlign
3.1
Each removed control has a recommended replacement control. Refer to the following table:
Removed control (API) | Recommended replacement | Associated APIs that are removed |
---|---|---|
ContextMenu | ContextMenuStrip | |
DataGrid | DataGridView | DataGridCell, DataGridRow, DataGridTableCollection, DataGridColumnCollection, DataGridTableStyle, DataGridColumnStyle, DataGridLineStyle, DataGridParentRowsLabel, DataGridParentRowsLabelStyle, DataGridBoolColumn, DataGridTextBox, GridColumnStylesCollection, GridTableStylesCollection, HitTestType |
MainMenu | MenuStrip | |
Menu | ToolStripDropDown, ToolStripDropDownMenu | MenuItemCollection |
MenuItem | ToolStripMenuItem | |
ToolBar | ToolStrip | ToolBarAppearance |
ToolBarButton | ToolStripButton | ToolBarButtonClickEventArgs, ToolBarButtonClickEventHandler, ToolBarButtonStyle, ToolBarTextAlign |
Windows Forms
- System.Windows.Forms.ContextMenu
- System.Windows.Forms.GridColumnStylesCollection
- System.Windows.Forms.GridTablesFactory
- System.Windows.Forms.GridTableStylesCollection
- System.Windows.Forms.IDataGridEditingService
- System.Windows.Forms.MainMenu
- System.Windows.Forms.Menu
- System.Windows.Forms.Menu.MenuItemCollection
- System.Windows.Forms.MenuItem
- System.Windows.Forms.ToolBar
- System.Windows.Forms.ToolBar.ToolBarButtonCollection
- System.Windows.Forms.ToolBarAppearance
- System.Windows.Forms.ToolBarButton
- System.Windows.Forms.ToolBarButtonClickEventArgs
- System.Windows.Forms.ToolBarButtonStyle
- System.Windows.Forms.ToolBarTextAlign
- System.Windows.Forms.DataGrid
- System.Windows.Forms.DataGrid.HitTestType
- System.Windows.Forms.DataGridBoolColumn
- System.Windows.Forms.DataGridCell
- System.Windows.Forms.DataGridColumnStyle
- System.Windows.Forms.DataGridLineStyle
- System.Windows.Forms.DataGridParentRowsLabelStyle
- System.Windows.Forms.DataGridPreferredColumnWidthTypeConverter
- System.Windows.Forms.DataGridTableStyle
- System.Windows.Forms.DataGridTextBox
- System.Windows.Forms.DataGridTextBoxColumn
- System.Windows.Forms.Design.IMenuEditorService
A DataGridView now shows a cell's text and error tooltips when hovered by a mouse and when selected via the keyboard. If a tooltip is shown, the DataGridView.CellFormatting event is not raised.
Prior to .NET Core 3.1, a DataGridView that had the ShowCellToolTips property set to true
showed a tooltip for a cell's text and errors when the cell was hovered by a mouse. Tooltips were not shown when a cell was selected via the keyboard (for example, by using the Tab key, shortcut keys, or arrow navigation). If the user edited a cell, and then, while the DataGridView was still in edit mode, hovered over a cell that did not have the ToolTipText property set, a CellFormatting event was raised to format the cell's text for display in the cell.
To meet accessibility standards, starting in .NET Core 3.1, a DataGridView that has the ShowCellToolTips property set to true
shows tooltips for a cell's text and errors not only when the cell is hovered, but also when it's selected via the keyboard. As a consequence of this change, the CellFormatting event is not raised when cells that don't have the ToolTipText property set are hovered while the DataGridView is in edit mode. The event is not raised because the content of the hovered cell is shown as a tooltip instead of being displayed in the cell.
3.1
Refactor any code that depends on the CellFormatting event while the DataGridView is in edit mode.
Windows Forms
None
In .NET Framework, the Control.DefaultFont property was set to Microsoft Sans Serif 8.25 pt
. The following image shows a window that uses the default font.
Starting in .NET Core 3.0, the default font is set to Segoe UI 9 pt
(the same font as SystemFonts.MessageBoxFont). As a result of this change, forms and controls are sized about 27% larger to account for the larger size of the new default font. For example:
This change was made to align with Windows user experience (UX) guidelines.
3.0
Because of the change in the size of forms and controls, ensure that your application renders correctly.
To retain the original font for a single form, set its default font to Microsoft Sans Serif 8.25 pt
. For example:
public MyForm()
{
InitializeComponent();
Font = new Font(new FontFamily("Microsoft Sans Serif"), 8.25f);
}
Or, you can change the default font for an entire application in either of the following ways:
By setting the
ApplicationDefaultFont
MSBuild property to "Microsoft Sans Serif, 8.25pt". This is the preferred technique because it allows Visual Studio to use the new settings in the designer.XML<PropertyGroup> <ApplicationDefaultFont>Microsoft Sans Serif, 8.25pt</ApplicationDefaultFont> </PropertyGroup>
By calling Application.SetDefaultFont(Font).
C#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()); } }
- Windows Forms
None.
The FolderBrowserDialog control has changed in Windows Forms applications for .NET Core.
In the .NET Framework, Windows forms uses the following dialog for the FolderBrowserDialog control:
In .NET Core 3.0, Windows Forms uses a newer COM-based control that was introduced in Windows Vista:
3.0
The dialog will be upgraded automatically.
If you desire to retain the original dialog, set the FolderBrowserDialog.AutoUpgradeEnabled property to false
before showing the dialog, as illustrated by the following code fragment:
var dialog = new FolderBrowserDialog();
dialog.AutoUpgradeEnabled = false;
dialog.ShowDialog();
Windows Forms
The SerializableAttribute has been removed from some Windows Forms classes that have no known binary serialization scenarios.
The following types are decorated with the SerializableAttribute in .NET Framework, but the attribute has been removed in .NET Core:
System.InvariantComparer
- System.ComponentModel.Design.ExceptionCollection
- System.ComponentModel.Design.Serialization.CodeDomSerializerException
System.ComponentModel.Design.Serialization.CodeDomComponentSerializationService.CodeDomSerializationStore
- System.Drawing.Design.ToolboxItem
System.Resources.ResXNullRef
System.Resources.ResXDataNode
System.Resources.ResXFileRef
- System.Windows.Forms.Cursor
System.Windows.Forms.NativeMethods.MSOCRINFOSTRUCT
System.Windows.Forms.NativeMethods.MSG
Historically, this serialization mechanism has had serious maintenance and security concerns. Maintaining SerializableAttribute
on types means those types must be tested for version-to-version serialization changes and potentially framework-to-framework serialization changes. This makes it harder to evolve those types and can be costly to maintain. These types have no known binary serialization scenarios, which minimizes the impact of removing the attribute.
For more information, see Binary serialization.
3.0
Update any code that may depend on these types being marked as serializable.
Windows Forms
- None
The Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls
compatibility switch is supported in Windows Forms on .NET Framework 4.6 and later versions but is not supported on .NET Core or .NET 5.0 and later.
In .NET Framework 4.6 and later versions, selecting a tab reorders its control collection. The Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls
compatibility switch allows an application to skip this reordering when this behavior is undesirable.
In .NET Core and .NET 5.0 and later, the Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls
switch is not supported.
3.0
Remove the switch. The switch is not supported, and no alternative functionality is available.
Windows Forms
- None
The Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling
compatibility switch, which was introduced in .NET Framework 4.7.1, is not supported in Windows Forms on .NET Core or .NET 5.0 and later.
Starting with .NET Framework 4.7.1, the Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling
compatibility switch allowed developers to opt-out of independent DomainUpDown.DownButton() and DomainUpDown.UpButton() actions. The switch restored the legacy behavior, in which the DomainUpDown.UpButton() is ignored if context text is present, and the developer is required to use DomainUpDown.DownButton() action on the control before the DomainUpDown.UpButton() action. For more information, see <AppContextSwitchOverrides> element.
In .NET Core and .NET 5.0 and later, the Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling
switch is not supported.
3.0
Remove the switch. The switch is not supported, and no alternative functionality is available.
Windows Forms
The Switch.System.Windows.Forms.UseLegacyImages
compatibility switch, which was introduced in .NET Framework 4.7.1, is not supported in Windows Forms on .NET Core or .NET 5.0 and later.
In .NET Framework 4.6.2 and previous versions, the RichTextBox control instantiates the Win32 RichEdit control v3.0, and for applications that target .NET Framework 4.7.1, the RichTextBox control instantiates RichEdit v4.1 (in msftedit.dll). The Switch.System.Windows.Forms.DoNotLoadLatestRichEditControl
compatibility switch was introduced to allow applications that target .NET Framework 4.7.1 and later versions to opt out of the new RichEdit v4.1 control and use the old RichEdit v3 control instead.
In .NET Core and .NET 5.0 and later versions, the Switch.System.Windows.Forms.DoNotLoadLatestRichEditControl
switch is not supported. Only new versions of the RichTextBox control are supported.
3.0
Remove the switch. The switch is not supported, and no alternative functionality is available.
Windows Forms
The Switch.System.Windows.Forms.DoNotSupportSelectAllShortcutInMultilineTextBox
compatibility switch, which was introduced in .NET Framework 4.6.1, is not supported in Windows Forms on .NET Core and .NET 5.0 and later.
Starting with .NET Framework 4.6.1, selecting the Ctrl + A shortcut key in a TextBox control selected all text. In .NET Framework 4.6 and previous versions, selecting the Ctrl + A shortcut key failed to select all text if the Textbox.ShortcutsEnabled and TextBox.Multiline properties were both set to true
. The Switch.System.Windows.Forms.DoNotSupportSelectAllShortcutInMultilineTextBox
compatibility switch was introduced in .NET Framework 4.6.1 to retain the original behavior. For more information see TextBox.ProcessCmdKey.
In .NET Core and .NET 5.0 and later versions, the Switch.System.Windows.Forms.DoNotSupportSelectAllShortcutInMultilineTextBox
switch is not supported.
3.0
Remove the switch. The switch is not supported, and no alternative functionality is available.
Windows Forms
- None
The Switch.System.Windows.Forms.DontSupportReentrantFilterMessage
compatibility switch, which was introduced in .NET Framework 4.6.1, is not supported in Windows Forms on .NET Core and .NET 5.0 and later.
Starting with the .NET Framework 4.6.1, the Switch.System.Windows.Forms.DontSupportReentrantFilterMessage
compatibility switch addresses possible IndexOutOfRangeException exceptions when the Application.FilterMessage message is called with a custom IMessageFilter.PreFilterMessage implementation. For more information, see Mitigation: Custom IMessageFilter.PreFilterMessage Implementations.
In .NET Core and .NET 5.0 and later, the Switch.System.Windows.Forms.DontSupportReentrantFilterMessage
switch is not supported.
3.0
Remove the switch. The switch is not supported, and no alternative functionality is available.
Windows Forms
The Switch.System.Windows.Forms.EnableVisualStyleValidation
compatibility switch is not supported in Windows Forms on .NET Core or .NET 5.0 and later.
In .NET Framework, the Switch.System.Windows.Forms.EnableVisualStyleValidation
compatibility switch allowed an application to opt out of validation of visual styles supplied in a numeric form.
In .NET Core and .NET 5.0 and later, the Switch.System.Windows.Forms.EnableVisualStyleValidation
switch is not supported.
3.0
Remove the switch. The switch is not supported, and no alternative functionality is available.
Windows Forms
- None
The Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue
compatibility switch, which was introduced in .NET Framework 4.7.2, is not supported in Windows Forms on .NET Core or .NET 5.0 and later.
Starting with .NET Framework 4.7.2, the Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue
compatibility switch allows the developer to opt out of the new behavior of the ContextMenuStrip.SourceControl property, which now returns a reference to the source control. The previous behavior of the property was to return null
. For more information, see <AppContextSwitchOverrides> element.
In .NET Core and .NET 5.0 and later, the Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue
switch is not supported.
3.0
Remove the switch. The switch is not supported, and no alternative functionality is available.
Windows Forms
The Switch.System.Windows.Forms.UseLegacyImages
compatibility switch, which was introduced in .NET Framework 4.8, is not supported in Windows Forms on .NET Core or .NET 5.0 and later.
Starting with .NET Framework 4.8, the Switch.System.Windows.Forms.UseLegacyImages
compatibility switch addressed possible image scaling issues in ClickOnce scenarios in high DPI environments. When set to true
, the switch allows the user to restore legacy image scaling on high DPI displays whose scale is set to greater than 100%. For more information, see .NET Framework 4.8 Release Notes on GitHub.
In .NET Core and .NET 5.0 and later, the Switch.System.Windows.Forms.UseLegacyImages
switch is not supported.
3.0
Remove the switch. The switch is not supported, and no alternative functionality is available.
Windows Forms
- None
The About.vb
and SplashScreen.vb
files generated by Visual Studio contain references to types in the My
namespace that aren't available .NET Core 3.0 and 3.1.
3.0
.NET Core 3.0 and 3.1 don't contain full Visual Basic My
support. The About and SplashScreen form templates in Visual Studio for Visual Basic Windows Forms apps reference properties in the My.Application.Info
type that aren't available.
Visual Basic My
support was improved in .NET 5, upgrade your project to .NET 5 or later.
-or-
Fix the compiler errors in the About and SplashScreen types in your app. Use the System.Reflection.Assembly
class to get the information provided by the My.Application.Info
type. A straight port of both forms is available here.
Tip
This is sample code and unoptimized. The list of attributes should be cached to reduce form load time.
About
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
Visual Basic Windows Forms
None
The types in the Microsoft.VisualBasic.ApplicationServices namespace are not available.
.NET Core 3.0
The types in the Microsoft.VisualBasic.ApplicationServices namespace were available in .NET Framework. They're not available in .NET Core 3.0 - 3.1.
The types were removed to avoid unnecessary assembly dependencies or breaking changes in subsequent releases.
This namespace was added in .NET 5, upgrade your project to .NET 5 or later.
-or-
If your code depends on the use of Microsoft.VisualBasic.ApplicationServices types and their members, you may be able to use a corresponding type or member in the .NET class library. For example, some System.Environment and System.Security.Principal.WindowsIdentity members provide equivalent functionality to the properties of the Microsoft.VisualBasic.ApplicationServices.User class.
Visual Basic
The types in the Microsoft.VisualBasic.Devices namespace are not available.
.NET Core 3.0
The types in the Microsoft.VisualBasic.Devices namespace were available in .NET Framework. They're not available in .NET Core 3.0 - 3.1.
The types were removed to avoid unnecessary assembly dependencies or breaking changes in subsequent releases.
This namespace was added in .NET 5, upgrade your project to .NET 5 or later.
-or-
If your code depends on the use of Microsoft.VisualBasic.Devices types and their members, you may be able to use a corresponding type or member in the .NET class library. For example, equivalent functionality to the Microsoft.VisualBasic.Devices.Clock class is provided by the System.DateTime and System.Environment types, and equivalent functionality to the Microsoft.VisualBasic.Devices.Ports class is provided by types in the System.IO.Ports namespace.
Visual Basic
The types in the Microsoft.VisualBasic.MyServices namespace are not available.
.NET Core 3.0
The types in the Microsoft.VisualBasic.MyServices namespace were available in .NET Framework. They're not available in .NET Core 3.0 - 3.1.
The types were removed to avoid unnecessary assembly dependencies or breaking changes in subsequent releases.
This namespace was added in .NET 5, upgrade your project to .NET 5 or later.
-or-
If your code depends on the use of Microsoft.VisualBasic.MyServices types and their members, there are corresponding types and members in the .NET class library. The following is a mapping of Microsoft.VisualBasic.MyServices types to their equivalent .NET class library types:
Microsoft.VisualBasic.MyServices type | .NET class library type |
---|---|
ClipboardProxy | System.Windows.Clipboard for WPF applications, System.Windows.Forms.Clipboard for Windows Forms applications |
FileSystemProxy | Types in the System.IO namespace |
RegistryProxy | Registry-related types in the Microsoft.Win32 namespace |
SpecialDirectoriesProxy | Environment.GetFolderPath |
Visual Basic
.NET feedback
.NET is an open source project. Select a link to provide feedback: