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


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!

  • .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.


    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.


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

  • To answer your last question...

    The REST API is fundamentally different, as you use HTTP requests to interact with it, rather than the COM interface.  There are advantages (e.g. you can use any language or operating system to interact, as long as it can make HTTP requests) and disadvantages (e.g. the REST API does not have the breadth of functionality that the COM API does) to using the REST API.  You pick your poison.

    But: no, you shouldn't need to move just because you've updated the framework runtime you've targeted.

  • 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,

  • When testing a simple connection with the COM API, I failed to import the dependency using the .Net6. 

    Isn't the Interop.MFilesAPI the correct dependency to work with the COM API? Is there any piece I am missing?

    Thank you!

  • Aha, you're using the nuget package.  I notice that the nuget package only explicitly targets .NET Framework.  I will speak to PD about getting that updated.

    You should be able to remove the nuget package and instead add a COM reference to the M-Files API.

    Note, though, that the machine running this needs to be Windows, and to have some component of M-Files (e.g. the desktop client) installed.  If you can't guarantee those things then you would perhaps need to move to the REST API.  If so, then you may want to look at something like the open-source MFWSClient sample library.