.NET Core 3.0 support (at least for geometric kernel)

We don't want to be left behind and would like to move to Core 3.0 as soon as possible.

So we have a need to run Eyeshot geometry translations in a library compatible with Core 3.0. Core 3.0 has lost all compatibility with .NET framework. We have no pressing need to do our translations on anything else that Windows (i.e. Azure WebApp in our case). Of course, if you would do the right thing and separate the non UI/Windows parts to a generic geometry/translation lib running under Core 3.0 we and others could run that under Linux as well.

17

Comments

40 comments
  • Official comment

    We are proud to announce the availability of net6-windows assemblies starting with the Eyeshot version 2022.2 version 🎉

    More details can be found here.

  • My thoughts on this topic:

    • separation of UI and generic geometry/translation is a good idea anyway. I interpret this as a strict separation between the UI control (currently named Model or Environment and currently in two types => WPF and WinForms) and the generic logic.
    • The generic part should be just a binary (or multiple) that is used when using the WPF controls or the WinForms control.
    • The generic part should be usable stand-alone => without any WPF nor WinForms dependencies
    • The licensing/unlock mechanism should work without the need to instantiate a WPF or WinForms control first and call Unlock() (which currently is the case)
    • The readers and writers should work with the generic part => no need for the UI control EVEN when generating a bitmap.
    • One additional UI control: Blazor => rendering to WebGL to use the Eyeshot control within the Browser including mouse interaction => this for Blazor type of scenarios.
    • All async commands being in line with the TPL syntax => names ending with Async and awaitable => e.g. await x.DoWorkAsync()

    Great product you have!

    Have a great weekend,

    Willem Dijkgraaf

     

    9
  • What is the status of support for .NET Core 3.1?

    0
  • Hi Magnus,

    We will start this project soon.

    1
  • I agree with Willem 100%. In every point he makes.

    1
  • Any news regarding this (the issue was originally reported by me)?

    0
  • It's in Eyeshot 2021 Roadmap. Actually, we are preparing the DEV code line to allow these siamese twins (UI and geometric kernel) separation. Will we succeed? More news later this year.

    1
  • Thanks for the update. Hopefully the twins will be separated this year. And I assume that you will also jump on the opportunity to package the geometric stuff into a potential new product (conversion for example). It's worth it.

    0
  • A question for .NET Core experts. What licensing tools are available? If we need to create a .NET geometry kernel separated from UI, we need a .NET Core licensing tool for it. 

    0
  • 0
  • I'm interested in .net core and Blazor too, do you already have an idea of the development and release times?

    I would also be available to participate as a beta tester.

    2
  • The project is now in progress. We are trying to split UI and geometry kernel for all Eyeshot entities. We will keep collision detection, proprietary file format, and import/export out for the moment.

    2
  • I know i have reached out to you guys about .Net Core and it's finally making it "possible" way to your tool if it's doable and this is a big plus for future proofing.

    That being said having following the Microsoft Dev Insider quite a lot i have seen more and more mention of their next replacement that will be fully cross platform (IOS, Linux, Android and Windows). the project is called MAUI

    https://github.com/dotnet/maui

    The whole language use the XAML like WPF plus you can have CSS in the XAML. It will be in beta release next month although it seems that only Android and IOS are implemented right now. They do want to fully replace Xamarin, .Net Core with MAUI for .NET 6.0 due in last quarter 2021. So we should have .Net 5.0 before the end of this year with the beta.

    I do believe being XAML and very WPF alike it might be an easier implementation than .Net Core is.

    0
  • Ok, time has passed since my original request....I guess you should now aim for .NET 5.

    1
  • We are still busy separating UI from geometry kernel but yes, once finished, we will address .NET 5 if possible.

    1
  • Lars, .NET 5 should be extremely similar to .NET Core 3.1 so you shouldn't have much if any to convert when come time to do the change.

    0
  • Yep, targeting .Net 5.0 once .Net Core 3.1 is done, should be easy. Keeping fingers crossed for separation.

    1
  • Thumbs up for all the effort and great results!!!

    0
  • Looking forward to this along with VS 2022 (which will be 64-bit!), .NET 6, MAUI, but mos of all WinUI3 :)

    We don't care so much about cross platform support, but will you consider porting the WPF control to WinUI3?

    Thank you very much for your efforts!

    0
  • We now have official end of life date on both .NET 5 (Feb 2022) and .NET Core 3.1 (Dec 2022) So in a little more than a year both will de dropped. .NET 6 should be the long term target. MAUI updated in march a couple good news, including support for the new Apple M1 chip.

    1
  • Any update on this?

    0
  • Hi Jeremy,

    Yes, the first stage (Eyeshot 2022) is completed. It includes:

    1. Creation of geometric entities inside Geometry assembly
    2. Standard entities depend on geometric entities
    3. Move licensing from control assembly to geometry assembly

    The next stage is moving most of the CAD algorithms from Control to Geometry assembly. Moving data translators needs to be evaluated as well. 

     

    3
  • Stage I of this project is ready to be tested in the Beta just released, please check this article: https://devdept.zendesk.com/hc/en-us/community/posts/4408685943826-Eyeshot-2022-Beta

    0
  • Does this mean that there is hope that Eyeshot 2022 might be fully .NET Core compatible?

    0
  • Currently, the only limit is the licensing system, not compatible with modern versions of .NET Framework.

    We are always talking about the geometric kernel, no plan to port UI in the short term.

    0
  • Thank you for your hard work! So I guess the answer is no and we should look forward to 2023 for .NET Core support?

    0
  • No plans to port the UI portion to NET5.0-Windows?

    0
  • Regarding the licensing system, have you tried Cryptolens?

    Home - Cryptolens

    It is easy to implement and it is possible to have Node-locked (as now) or floating licenses.

    Cryptolens Docs & Support for Licensing and Payments

     

    Regarding the .NET Core topic, I agree with Willem. Especially with the Blazor UI.

    I here more and more customers asking for the possibility to make something Web-based instead of Desktop apps. The barrier of entry is to high for some users that they deviates from desktop and prefers Web solutions apparently...

     

    1
  • Steffen web base already exist it uses many technologies to load the models into a viewport. WebGL, Threejs.

    In Eyeshot there is already an option to export to web your model. Although if you want to bring it in a GLTF or GLB format (for VR experience for example) you will need to update the automated ThreeJs code they put in the HTML as it's was an older version last time i used it about 2 years ago.

    I don't use it that much as web is a very very bad platform for me because as it is extremely slow and models takes multiple times more RAM than the desktop version for a lower quality version. Note that we do Solidworks/NX qualtity level of work so mileage may vary.

    0
  • This post opens with:

    > We don't want to be left behind and would like to move to Core 3.0 as soon as possible

    Meanwhile, Core 3.0, Core 3.1, .NET 5 and .NET 6 have been rolled out. This feature is already obsolete and, honestly speaking, it's becoming a problem. We're bound to .NET Framework and need to move to a newer tech, the feeling from the outside is that we won't get Eyeshot ported before .NET 8, since .NET 7 will not be a LTS version.

    I think it's time to share with use the expected timeline for the migration, as the drawbacks of not moving our application to .NET 6 are becoming greater than the benefit of keep using Eyeshot.

    6

Please sign in to leave a comment.

Didn't find what you were looking for?

New post