Thanks for your feed back, I can reproduce this problem, and it looks Visual Studio strange behavior, and please feel free post this in Microsoft.Toolkit.Win32 github issue box. Currently, there is a workaround that initials WindowsXamlHost
in the code behind, then call below in the InitializeComponent
method.
For WinForms
private void CreateUWPControlsFirst()
{
Windows.UI.Xaml.Hosting.WindowsXamlManager.InitializeForCurrentThread();
Windows.UI.Xaml.Controls.Button myButton = new Windows.UI.Xaml.Controls.Button();
myButton.Name = "button1";
myButton.Width = 75;
myButton.Height = 40;
myButton.TabIndex = 0;
myButton.Content = "button1";
myButton.Click += MyButton_Click;
Microsoft.Toolkit.Forms.UI.XamlHost.WindowsXamlHost myHostControl =
new Microsoft.Toolkit.Forms.UI.XamlHost.WindowsXamlHost();
myHostControl.Name = "myWindowsXamlHostControl";
myHostControl.Child = myButton;
myHostControl.Height = 500;
myHostControl.Width = 600;
this.Controls.Add(myHostControl);
}
Please note: if you encounter Catastrophic failure" exception
please add app.manifest
file and write below content, then switch WinForm app's default manifest to app.manifest.(right click your project -> application -> Manifest) For the detail please refer Matteo Pagani blog.
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!-- Windows 10 -->
<maxversiontested Id="10.0.18358.0"/>
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />
</application>
</compatibility>
</assembly>