VAF upgrade to .NET Core/.NET 5+

Hi M-Files and community,

As Microsoft makes a big jump in versions lately and there is soon even .NET 6 (LTS), I would be curious if M-Files plan upgrade of VAF framework on .NET Core/.NET 5+ framework. Currently we keep our VAF projects on latest .NET 4.8. I think this would be a good move to keep M-Files compatible with latest changes in Microsoft world. Also wondering if M-Files would work on servers that have only installed .NET Core and not whole .NET framework (I think system reuqirement is .NET 4.7.2+).

Is there any plans/timelines to support/be compatible with .NET Core/:NET 5+?

Best regards,

Dejan

  • I don't believe that we have any immediate plans to migrate across to Core. 4.8 was released in 2019, and frameworks have historically had about 7 years of support.

    Do you have any specific current requirements that would need Core? 

  • Hi Craig, 

    Thanks for replying. Actually, we have organization policies on new environments that only .NET Core is installed. Another obvious reason is just keeping it up with Microsoft. You are right though, .NET 4.8 will stay for some time and will be security patched .

    On the other side, there will be no new features, no language improvements etc. So I am thinking it would be worth investing there. It is a big jump as the framework is significantly differently build up (modules etc.)

    I hope I will get approval by server managers during setup of new servers. 

    Would you consider at least upgrading VAF to :NET 4.8 or are there any limitations? We can use with .NET 4.8 project but it looks like it is built with .NET 4.5. We have scanning tools which find those libraries and it is generally not accepted to use any libraries built with lower versions any more.

    Thanks.

    Dejan

  • M-Files itself has a base requirement of 4.5 (enforced in the installer, I believe). Some of our IML components already target 4.7.2 for some other reasons.

    The reality is that you can already upgrade your project framework to target 4.8 if you can guarantee that it'll be on all the servers you use. As such, moving from 4.5 only has the real effect of alienating those who do not have newer versions of the runtime.

    (of course: they should do, but in the real world it's not always the case)

    Moving to 5 or higher is a much more complex endeavour. These newer runtime have a different set of machine requirements, and a different set of available functionality in the BCL. Again: we have discussed it, and it may happen in the future, but this would be a much more significant change than even going to 4.8.

    Regards,

    Craig. 

  • As an aside: you can quite happily run a 4.5 DLL inside all the 4.x (x >= 5) runtimes. So, if you have a requirement that, from a security perspective, you will enforce 4.8, you can quite happily run 4.5 applications with all the latest 4.8 security patches. 

  • Yes, this is what we are doing currently.