npiegdon / bed-inspector

A small tool to evaluate 3D printer bed flatness
MIT License
56 stars 5 forks source link

Enhancement: Port / Convert, possible separate branch / build for .net core builds #5

Closed ipatch closed 3 years ago

ipatch commented 4 years ago

When I first discovered this app from sifting through videos on youtube, I noticed the app was written in .net, and not knowing much about .net I soon found out that .net core apps can run on a variety of platforms, where .net framework apps are limited to Windows only. I being a person who has a Raspberry Pi with Octoprint setup on it, it's quite convenient to be able to run an app on a box that's connected to printer, and for my particular use case X11 forwarding, VNC, or whatever method to work with GUI apps on a box that I have access to would make for a great convenience as opposed to spinning up a virtual machine to run a utility.

I did a little research on what it would take to port the .net framework code / logic to .net core code / logic to be able to eventually run on macos or GNU+Linux and it seems the bulk of the work would be converting the the GUI widgets from the Windows Form Designer to something that is compatible with mac and linux, so utilizing a framework such as http://avaloniaui.net/ could do a bulk of the work, not saying it'd be easy as clicking some check boxes and running build, but I don't think it'd be too much work. I checked several different GUI / universal frameworks for building .net core apps on macos and linux and the avaloniaui framework seems the most fleshed out from what i could tell.

And I'm not saying the core build of the app needs to be a .net core app, but there could be a different branch within this project that supplies a .net core build of this app for people who would like to run this utility on mac or linux.

cheers 🍩

npiegdon commented 4 years ago

Just a few months ago, Microsoft announced a version of Windows Forms for .NET Core. That would probably be the fastest/easiest migration path.

The "Controls included in Preview 1" section on that page seems to list everything the app uses, so it should be a direct conversion.

ipatch commented 4 years ago

had some time to look at what it would take to develop a cross platform version of this utility, and read up on that article you linked.

also it's a bit dated of a graphic but using mono + gtk seems like it would be possible to develop and run the utility on all three major platforms.

Update

It looks like targeting dotnet core 3.x while using Win Forms will not work with macOS or Linux unfortunately, because as soon as you bring in the WinForms dependency in a project the binary was not able to run on macOS.

I tried several different publishing options using the preview version of visual studio on windows 10, and was able to produce a binary that was framework dependent but not self contained, and when i attempted to run the binary on macOS i got the below runtime error learn more

It was not possible to find any compatible framework version
The framework 'Microsoft.WindowsDesktop.App', version '3.1.0' was not found.
  - No frameworks were found.

You can resolve the problem by installing the specified framework and/or SDK.

The specified framework can be found at:
  - https://aka.ms/dotnet-core-applaunch?framework=Microsoft.WindowsDesktop.App&framework_version=3.1.0&arch=x64&rid=osx.10.13-x64

and am currently unable to produce a self contained bin for macOS, which I assume the above runtime error is related to why visual studio can not produce a self contained bin for macOS

npiegdon commented 4 years ago

It looks like the .NET Core version of Windows Forms has made it into the live release of Visual Studio 16.6 in the meantime since the article I linked before.

The note in this new link mentions that you still need to enable a setting to get it to show up, but now that it's available in the general release without needing to install anything else, it should be a lot easier to test out. (That said, I haven't had a chance to try it yet.)

ipatch commented 4 years ago

cool for the fact that they merged into to the release channel, but the Windows Forms and WPF components are still only compatible with Windows only OSes, those specific libraries have been "ported" to work with dotnet core, but they will not work on a GNU+Linux or macOS operating system(s).

You don't even need a separate OS to test the functionality, try and build a self contained binary for either macOS or GNU+Linux with Visual Studio on Windows, and the publish operation will not complete (when trying to build a binary as a self contained GUI application that uses the windows form(s) libs but is a dotnet core based project). If you choose to not build a self contained library and use the "imported" libraries as runtime dependencies you will notice that on macOS there is no Windows Forms library for macOS. All of this is based on my empirical testing, so if anything I'm stating is incorrect please correct me or call me out on my statements, last thing I want to do is spread false information.

I posted this link in my prior post which pretty much talks about the runtime dependency issue that I have mentioned.

switching gears 🕹

I still haven't gotten the "auto probe" feature working last time i checked which was several months ago, so first on the pecking order for me is to try and get that working, where i can click the button in the app, and have it generate all the required heat map circles (without having to manually click on various points on the build plate). Once I get that figured out, I'll do some more research on porting the app from .net framework to .netcore, and then once the app is entirely .netcore based, but still using the windows only GUI components ie. win forms, then it's time to decouple the gui aspect of the app from the windows only libs, and try to use a more universal compatible lib.

I'm not sure what your schedule looks like, but I've allotted some time today to work with my printer 🎉, so hopefully i'll make some progress with the "auto probe" feature of the app.

npiegdon commented 3 years ago

Reading this (five days shy of) a year later, I finally see what you mean about .NET Core (now just ".NET 5") not giving automatic WinForms compatibility in macOS and Linux. That's unfortunate.

Switching to Core did mean dropping the System.Numerics dependency (it's built in to the base framework now), which was nice.

And the new naming convention (dropping the "Core" part) seems to indicate it's probably the right answer moving forward.