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

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

Purposely shipping an empty WindowsBase.dll in the core package is beyond dll hell, its malicious. WTF are they thinking…? :slight_smile:

1 Like

Today I had internet offline for a few hours ( how to live with that :wink: ). I wanted to compile the project that we are testing but I got error :

Exception processing package reference Microsoft.WindowsDesktop.App.Ref:[3.0.0] : The operation has timed out

although the package is referenced implicit and exists on a local drive. Is that correct behaviour of Water?