Import VS2019 projects with .NET Core 3.0 Winforms and WPF frameworks

Hi
I have just created two projects in VS2019 for .NET Core 3.0 Winforms and WPF. The goal is to use new Winforms and WPF frameworks (did anyone tried them?). Here is the designer : Windows Forms Designer.
I found a few issues that I don’t understand :

  1. Water imports the project .csproj file but doesn’t add files. I checked that, inside .csproj there is no reference to .cs files so VS automatically adds all .cs?
  2. There are some new options inside the .csproj that may not be imported and the solution panel looks different :
  • Project Sdk=“Microsoft.NET.Sdk.WindowsDesktop”
  • UseWindowsForms
  • UseWPF
    image
  1. Here are 3 projects repos.zip (798.4 KB)
    WindowsFormsApp1 and WpfCustomControlLibrary1 were created using VS 2019.
    ConsoleApplication9 was created in Water to check why some WPF types are unknown. I wanted to convert VS projects to Water to test new frameworks but have a problem with package microsoft.windowsdesktop.app.
    Here is what NuGet References shows :
    image
    When I use a first reference (lowercase) then the project compiles but doesn’t recognize the types (ModifierKeys, Rect). So I changed in Settings SDK and Runtime to WindowsDesktop.App like this :

    Now these types are recognized from System.Windows.Input but compiler reports error :
    "E: Package Microsoft.WindowsDesktop.App matching version [3.0.0] was not found in any repositories."

    How to solve these problems? It seems that the preview8 package is deprecated.
    VS is using files from C:\Program Files\dotnet\packs\Microsoft.WindowsDesktop.App.Ref\3.0.0\ref\netcoreapp3.0
    Is there a way to reference this directory?
  2. How are Settings \ SDK and Runtime related to nuget packages? How should I set them to use Winforms and WPF frameworks from .NET 3.0? How to modify ConsoleApplication9 to compile?

Thanks for any help and sorry for so many issues in one report.
Artur

Yeah, cspoj changed completely for Core, right now the import handles regular .NET projects only. That said, id still love to see the project you tried to import, as a test case.

Yeah, we dont us envy of these and we haven’t begin to investigate whatever black magic lies behind UseWPF and co. Regular .NET Core 3.0 is supported now, but not these flags yet. I’ll log an issue so we dont lose track of looking into that…

Thanx!

Is this with latest? iirc this was renamed to Microsoft.WindowsDesktop.AppRef our the like, and Ebuild was fixed to reflect that last week or the week before…

I don’t believe they are, at this stage.

By waiting until we added support for that, sorry :(.

Thanks, logged as bugs://83385 — WPF and WinForms

Thanks, logged as bugs://83386 — Improve csproj import

I didn’t use the latest Elements version so I will try the weekend release.

1 Like

FWIW, ConsoleApp9 resolved

Microsoft.NETCore.App.Ref:[3.0.0]
Microsoft.WindowsDesktop.App.Ref:*

fine for me; I di ghet 3 unknown identifiers, prolly related to UseWPF not being honored yet (ie expected).

Correction, the NETCoreRuntime setting affects what implicit packages are added by default:

                lPackageNames := case Setting["NETCoreRuntime"]:Value:ToLowerInvariant of
                  "microsoft.netcore.app": new List<String>("Microsoft.NETCore.App.Ref");
                  "microsoft.windowsdesktop.app": new List<String>("Microsoft.NETCore.App.Ref", "Microsoft.WindowsDesktop.App.Ref");
                  "microsoft.aspnetcore.app": new List<String>("Microsoft.NETCore.App.Ref", "Microsoft.ASPNETCore.App.Ref");
                end;

Aside from that, the name goes into the .json files, and its used when debugging to launch the right runtime version. That’s if AFAICT.

This is strange because Winforms and WPF are in the same WindowsDesktop.App package, but only some WPF types are unknown. I also noticed in Water that when you expand the package in References node, not all dll files are listed. Is this important? W.g. WindowsBase is missing.

Is WindowsBase in the package though?

hmm, it is. freaky. I’ll investigate.

Oh, bec cause its already added from Microsoft.NETCore.App.Ref:[3.0.0]. I don’t add the same ref twice…

I think the fix is to NOT reference Microsoft.NETCore.App.Ref, even though I was told we should. committing a fix for today, ut I can’t test it right now, since microsoft.windowsdesktop.app isn’t available on Mac. B ut with a few temp hacks to ignore that, it compilers for me…

Testing on windows, I get a few errors, logged as bugs://83396: .NET Core WPF app fails to buiild (No type converter, NRE). Might just be that the XAML needs to be adjusted from what .NET 4 used…

                  Reference: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscorlib.dll
E:                No type converter for {http://schemas.microsoft.com/winfx/2006/xaml/presentation}Window.Title [\\Mac\Home\Documents\RemObjects Software\Elements\Water\WPFApplication\Window1.xaml (5)]
E:                Internal error: \\Mac\Home\Documents\RemObjects Software\Elements\Water\WPFApplication\Window1.xaml:System.NullReferenceException: Object reference not set to an instance of an object.
   at RemObjects.Elements.Xaml.XamlToBamlConverter.GetTypeConverterFor(IGetAttributes typ)
   at RemObjects.Elements.Xaml.XamlToBamlConverter.GetTypeConverterFor(IMemberInfo typ)
   at RemObjects.Elements.Xaml.XamlToBamlConverter.WriteStringProperty(XmlNode origin, String value, XamlMember member, Boolean wasdefault)
   at RemObjects.Elements.Xaml.XamlToBamlConverter.WriteElement(XmlElement el, Boolean isbinding)
   at RemObjects.Elements.Xaml.XamlToBamlConverter.Convert(String fn, String Xaml, String Type, String namen)
   at RemObjects.Oxygene.Code.ElementsSyntaxModel.IntFillTypes()
E:                No type converter for {http://schemas.microsoft.com/winfx/2006/xaml/presentation}Application.StartupUri [\\Mac\Home\Documents\RemObjects Software\Elements\Water\WPFApplication\App.xaml (6)]
                  -> Phase Resolving Bodies started.
E:                   Unknown namespace "System.Xml" in uses list [\\Mac\Home\Documents\RemObjects Software\Elements\Water\WPFApplication\App.xaml.swift (3)]
E:                   Unknown identifier "InitializeComponent" [\\Mac\Home\Documents\RemObjects Software\Elements\Water\WPFApplication\Window1.xaml.swift (15)]
                  <- Phase Resolving Bodies finished, took 1.8750s.

This is my test project: WPFApplication.zip (58.7 KB)

I tested last release and finally managed to build full project with Winforms and WPF on .net core 3.0 :slight_smile: But I had to change Settings to microsoft.windowsdesktop.app as main sdk/runtime and add Microsoft.NETCore.App.Ref as a package reference (to recognise WinForms). Then both frameworks compiled. Is that logical for You? I will test it more and let you know.

Well, yes.

Ok are we mixing WPF and WinForms here? For WPF, which I tested with your last testcase, I had to drop Microsoft.NETCore.App.Ref from the references to make it build, because otherwise it got the wring WindowsBase.dll from that reference . I didn’'t test WinForms, and I;'m not sure if you’re supposed to be ab le to combine the two…

Yes, mixing. Original project in .net 4.5 has both frameworks. New port to .net core also should have both. As I wrote earlier, this compiles now but I must check in VS 2019 if it works in design time and runtime.

Ok, can you send m your fixed project for comparison?

ConsoleApplication9_wpf_winforms.zip (134.0 KB)
This should be minimal test case. In my big project I see (Implicit) at WindowsDesktop reference. In this small project there is implicit notation. Does it matter ?

EBuild will add one or more default packages, baed on the SDK type you selected, if they aren’t already referenced. if you have the reference in our project, it will show was normal; if you don’t, it will shows as “(Implicit)” to indicate that even though your project did not specifically (explicitly) specify it, it is still being referenced.

It should make no factual difference to what actually gets referenced, whether the package referent tis explicit or implicit.

Update: looks like both packages are needed, but the dlls from Desktop need to take precedence over the ones from plain Core. What morons design this stuff? In any case, fixed for vNext.

Thanks. Yes, a typical WIndows dll hell :frowning:

1 Like