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

Elements
#2

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 :(.

#3

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

#4

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

#5

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

1 Like
#6

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).

#7

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.

#8

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.

#9

Is WindowsBase in the package though?

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

#10

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

#11

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…

#12

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)

#13

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.

#14

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…

#15

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.

#16

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

#17

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 ?

#18

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.

#19

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.

#20

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

1 Like
#21

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

1 Like