Remove all .NET Fx dependencies

[crutkas]

For ARM64 support, we needed to remove .NET Framework dependencies. This is caught NU1701 which is suppressed in a few projects currently.

• Catalog all .NET Fx dependencies across all projects
• Mages for calc, in Calculator plugin for PT Run,
• tlbimp-Microsoft.Search.Interop for wrapper for indexer plugin for PT Run
• PowerToysInterop

[enricogior]

@crutkas

Catalog all .NET Fx dependencies across all projects

do you know if there is a way to do it through a query or do we need to manually check each dependency?

[crutkas]

Looks like these are done in the project level.

NU1701 -> Mages for Calculation
NU1701 -> tlbimp-Microsoft.Search.Interop for wrapper for indexer

[davidegiacometti]

xFunc could be a valid alternative to mages even if it won't be fully compatible with Mages syntax.

[crutkas]

Mages is OSS, we could just do the port.

[crutkas]

Is xFunc localized for different country formats?

[davidegiacometti]

Of course, porting Mages could be a solution too.
I don't think xFunc supports different formats.

[snickler]

I did a quick super duper stab at porting the Mages.Core project to .netstandard 2.0 for the heck of it and referencing it as a local NuGet package.

IT WORKS!

The other portions of the Mages library will require a lot more work to provide support (other pieces are dependent on packages targeting netfx)

[crutkas]

Do we need the other parts?

[snickler]

Nope. The Mages.Core project is the only necessary one for this.

[crutkas]

@enricogrior any objections just bringing that into our code base for now? They haven’t touched their repo in a while. This will make it easy to port / fixes.

[enricogior]

@crutkas @snickler
OK let's do it.

[snickler]

@enricogior @crutkas - What's the best way for us to go about that?

[crutkas]

Move the that project into our base in the same project, update notice.md.

[snickler]

Perfect. I'll work on that later on today.

[davidegiacometti]

Updated the first post.
Marked Mages as done since the installed version is now on .NET Standard 2.0.
Added PowerToysInterop that is on .NET 4.7.2
https://docs.microsoft.com/en-us/dotnet/core/porting/cpp-cli#port-a-ccli-project

[crutkas]

tlbimp-Microsoft.Search.Interop I think will be the painful one

[snickler]

@crutkas - I believe we can get past the tlbimp-Microsoft.Search.Interop issue and I'd like to take on the task. We're able to use the Microsoft.Windows.CsWin32package to generate the same code that is used by the tlbimp package.

Question: Are we still targeting .NET Core 3.1 first and then moving upwards?

[crutkas]

@snickler we need .net 5 (excellent chance we'll do .net 6) and up but to do that we need to shift our installer pipeline due to the agent to a different system internally.

If possible, a .net standard lib would solve the targeting problem i believe since that will work in .net 5/6. Worst case, we can just manually update the 3.1 lib to .net 5/6 when we do the larger migration.

TLDR: Please take the task with this background info

[crutkas]

@snickler is doing tlbimp-Microsoft.Search.Interop

[snickler]

Looking at PowerToysInterop, this one may be the most painful. C++/CLI on .NET Core has a minimum target of .NET Core 3.1 (.netstandard 2.1). UWP only implements up to .netstandard 2.0, which means it will take some rewriting.

[crutkas]

Remember we will have to upgrade settings no matter what so to WinUI 3.1 so this will resolve itself in near future

[snickler]

Oh yeah, that makes sense. No big worries on that then.

[crutkas]

is PowerToysInterop a thing anymore? I feel like this task is done

[crutkas]

lemme rephrase, yes it is a thing but it is C++, not a .NET Fx dependency which is what this tracks

[snickler]

lemme rephrase, yes it is a thing but it is C++, not a .NET Fx dependency which is what this tracks

I'd say you are correct. This was more for 3rd party .NET Fx dependencies.