Options
  • State Verified Answer
  • Locked Locked
  • Replies 5 replies
  • Subscribers 7 subscribers
  • Views 980 views
  • Users 0 members are here
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

The M-Files API COM Interop supports .Net 6/7?

o.elliot@flobotics.io

Hello,

I am relatively new to the .net framework and I apologize if any vagueness is done.


After upgrading the .net version (from 4.8 to 6) in our machines, we lost the functions previously developed using the Mfiles COM API.
 
Is this an expected behaviour, the COM API is  not compatible with the .net 6?

If not, is there any alternative or a plan to make it compatible in the future? 

How about the rest  API, would we face the same issue?

Thank you again for the excellent support!




Parents
  • +1

    .NET is confusing.

    .NET 4.x is referred to as ".NET Framework".  It was designed to run on Windows machines only.  The latest version is 4.8.  Later versions within .NET Framework are backwards-compatible (e.g. .NET 4.8 applications can include .NET 4.5 binaries).

    Microsoft have since released a number of .NET versions (Core, 5.0, 6.0, and now 7.0) that are capable of running on many operating systems.  There are many things different between these versions and .NET Framework.  Whilst there's a lot of similarity between these newer versions (e.g. between 6.0 and 7.0), none of these are backwards-compatible with any .NET Framework.

    However.

    The M-Files COM API is not a native .NET Framework assembly.  It is a COM-exposed DLL which can be used from various environments including .NET.  The fact you're using it from .NET Framework or .NET Core or .NET 6, or something outside of the .NET environment like Powershell, should be irrelevant; provided it can interact with COM then it should be fine.

    I just tested it using a .NET 6.0 console application I happened to have available.  I could connect to a vault and get a session, etc.

    Therefore...

    The issue shouldn't inherently be related to the .NET runtime you're using.  What exactly is happening?

Reply
  • +1

    .NET is confusing.

    .NET 4.x is referred to as ".NET Framework".  It was designed to run on Windows machines only.  The latest version is 4.8.  Later versions within .NET Framework are backwards-compatible (e.g. .NET 4.8 applications can include .NET 4.5 binaries).

    Microsoft have since released a number of .NET versions (Core, 5.0, 6.0, and now 7.0) that are capable of running on many operating systems.  There are many things different between these versions and .NET Framework.  Whilst there's a lot of similarity between these newer versions (e.g. between 6.0 and 7.0), none of these are backwards-compatible with any .NET Framework.

    However.

    The M-Files COM API is not a native .NET Framework assembly.  It is a COM-exposed DLL which can be used from various environments including .NET.  The fact you're using it from .NET Framework or .NET Core or .NET 6, or something outside of the .NET environment like Powershell, should be irrelevant; provided it can interact with COM then it should be fine.

    I just tested it using a .NET 6.0 console application I happened to have available.  I could connect to a vault and get a session, etc.

    Therefore...

    The issue shouldn't inherently be related to the .NET runtime you're using.  What exactly is happening?

Children
  • 0 in reply to Craig Hawker

    Thank you so much,

    Yes, the .net is indeed very confusing but your explanation helped a lot.

    My case is a bit particular because my code is invoked inside a low-code application.

    And, In order to use the Mfiles API builtin methods / features, I have to import a dependency which seems that is not supported anymore. (this same dependency works perfectly at the previous .net 4.8 version)



    The issue started to happen after migrating the low-code application to .net 6 which is a requirement from now on.

    However, if you say it should work, It may be a bug with the low code application and I may solve migrating the code to Visual Studio and then republishing the nupkg.

    Thank you very much as always,





              

© M-Files Corporation 2024 | Privacy Policy