Remove all .NET Fx dependencies
crutkas opened this issue · 25 comments
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
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?
Looks like these are done in the project level.
NU1701 -> Mages for Calculation
NU1701 -> tlbimp-Microsoft.Search.Interop for wrapper for indexer
xFunc could be a valid alternative to mages even if it won't be fully compatible with Mages syntax.
Mages is OSS, we could just do the port.
Is xFunc localized for different country formats?
Of course, porting Mages could be a solution too.
I don't think xFunc supports different formats.
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)
Do we need the other parts?
Nope. The Mages.Core project is the only necessary one for this.
@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 - What's the best way for us to go about that?
Move the that project into our base in the same project, update notice.md.
Perfect. I'll work on that later on today.
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
tlbimp-Microsoft.Search.Interop I think will be the painful one
@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?
@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
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.
Remember we will have to upgrade settings no matter what so to WinUI 3.1 so this will resolve itself in near future
Oh yeah, that makes sense. No big worries on that then.
is PowerToysInterop a thing anymore? I feel like this task is done
lemme rephrase, yes it is a thing but it is C++, not a .NET Fx dependency which is what this tracks
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.