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

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

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,

Craig Hawker

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.