I'd like to port my WPF/.NET6 app to MAUI so I can target MacOS. I know MAUI is still a work in progress until next spring, but are there any good materials specifically on porting WPF to MAUI available yet?
FYI, in the research I've done so far, these are the biggest differences/issues I've found.
1. Control properties are not directly accessible and must be set with handlers with an IF branch for each targeted platform.
2. I'll have to learn the Xamarin flavor of XAML (I assume it's similar to WPF XAML).
3. I'll have to learn how to deploy MAUI apps. I've been using ClickOnce up to this point.
4. I'll need to buy a Mac and use Visual Studio for Mac to compile for the Mac OS target.
Thanks, Gerry. The available in-depth information on MAUI is spotty, but from what I understand one possible path is to start refactoring the WPF app into Xamarin now, and then there will be update tools (part of VS?) that should make porting from Xamarin to MAUI more straightforward.
My hope was that someone has already created a tutorial or video that took a specific look at what it would be like to go from WPF directly to MAUI. I'm sure there are some devil-in-the-details issues that's just not being discussed in the plethora of "Hello World" .NET6/MAUI presentations right now. I found one YouTube video here, but the audio is hard to follow. It's the right idea, but I was hoping for more of these.
As for needing a Mac, I think it can compile the project, but there's no emulator for testing in VS right now. This is all new to me. I have a decade of learning to catch up on.
I tried with and without the ClassInterface and Guid attributes.
In the .csproj file I added these:
<ProjectSdk="Microsoft.NET.Sdk"><PropertyGroup><TargetFramework>net5.0</TargetFramework><!-- Indicate the assembly is providing a COM server --><EnableComHosting>true</EnableComHosting><EnableRegFreeCom>true</EnableRegFreeCom></PropertyGroup><PropertyGroupCondition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'"><PlatformTarget>x86</PlatformTarget></PropertyGroup><ItemGroup><PackageReferenceInclude="Hl7.Fhir.R4"Version="3.6.0"/></ItemGroup></Project>
I compiled for x86 and I got these files (and some more):
The problem is that I don't manage to register this component. tlbexp xxx.InterOp.dll gives me this error:
TlbExp : error TX0000 : Type library exporter encountered an error while processing 'hdmpcloud.ehealth.FhirTools.InterOp.Convertor, hdmpcloud.ehealth.FhirTools.InterOp'. Error: Type library exporter cannot load type 'hdmpcloud.ehealth.FhirTools.InterOp.Convertor' (error: Could not load file or assembly 'System.Runtime, Version=18.104.22.168, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. (Exception from HRESULT: 0x80070002)).
regasm /tlb xxx.InterOp.comhost.dll gives me
RegAsm : error RA0000 : Failed to load 'C:_projects\HDMP\hdmpcloud.ehealth.FhirTools\InterOp\hdmpcloud.ehealth.FhirTools.InterOp\bin\Debug\net5.0\hdmpcloud.ehealth.FhirTools.InterOp.comhost.dll' because it is not a valid .NET assembly
I want to call this component from a Delphi program (unmanaged code).
Unfortunately it doesn't help. It seems that regasm doesn't recognize .NET 5 assemblies. Regsvr32 does, and it registers the component / interface / library, but no TLB is generated. That makes it virtually useless.
From Exposing .NET Core components to COM | Microsoft Docs :
Unlike in .NET Framework, there is no support in .NET Core or .NET 5+ for generating a COM Type Library (TLB) from a .NET assembly. The guidance is to either manually write an IDL file or a C/C++ header for the native declarations of the COM interfaces.
So now I'm investigating how to create / compile / use the correct IDL file. Should anyone have some good pointers for that, let me know
I was under the assumption that creating a COM component would still be as easy under .NET 5 as under the previous versions. We don't need real time at all.
This would be part of a conversion program, that will run on the client PCs (> 3000 clients, with all sorts of PCs and OS's). I wanted to avoid having to serialize objects on the Delphi side, and to deserialize them on the .NET side. I think that we will resort to creating a file (or a couple of files) in a folder, and when that is done running the conversion program on the client PC. That way we only have to install .NET 5 and the conversion program, which is even easier than using a queue.
Thank you for thinking with me for solutions!
I am going to do 1 more try, posting the same question on SO. Please don't be insulted If I find a solution I will post it here.
According to the replies on SO this is a dead end indeed.
We now are going to create classes in C# and in Delphi with all the same properties. We'll then serialize the Delphi classes to JSON, and deserialize them in C#.
For this I'm writing a code generator that will use a DSL to describe the classes. It's a work-around, but at least we'll get the work done.
This is for a conversion, so the Delphi side will serialize the objects in a folder, and the .NET part will deserialize it and handle it further.
It is a One Shot operation, so no need for fancy stuff there.
Hi All, I hope now this is the correct forum for suggestions. This Type bottoms need to be bigger and more precise so people did not get flagged for asking a suggestion that i found unnecessary for been flagged, If someone here knows any type of free code camp please share the resource I immensely trying to enhanced my knowledge and I know someone of you there knows some free learning resources.