M-Files Interop Loading Redesign (Release 5.13.38.82)

Note

This redesign supersedes the M-Files 26.1 Emergency Patch. Customers who applied that patch can revert to the standard procedure code by upgrading to MFSQL Connector 5.13.38.82 or later.

Headline change: M-Files Interop assembly loading is now install-layout independent

Background

Until release 5.13.37.81, MFSQL Connector loaded the M-Files Interop assembly (Interop.MFilesAPI.dll) directly from the M-Files installation folder on the SQL Server, constructing the path from the MFInstallPath and MFVersion values stored in MFSettings.

This approach broke twice in 2026:

  • M-Files 26.1 — the assembly folder layout changed from \Common to \Bin\X64. Addressed at the time by the M-Files 26.1 Emergency Patch.

  • M-Files 26.4 — further reshuffling of folder layout and tighter coupling between the M-Files client and server installs made the path-construction approach fundamentally fragile.

Release 5.13.38.82 redesigns Interop loading to be independent of the M-Files install layout.

What changed

Assembly source. spMFUpdateAssemblies now loads Interop.MFilesAPI.dll from a stable, MFSQL-managed folder (AssemblyInstallPath, default C:\MFSQL\Assemblies\) rather than from the M-Files install path. The DLL is shipped with the MFSQL Connector installer and placed in the managed folder during installation.

Version detection. spMFCheckAndUpdateAssemblyVersion now reads the installed M-Files version directly from the Windows registry (HKLM\SOFTWARE\Motive\M-Files) and triggers a reload only when the stored version differs from the installed version. No CLR call is required for the check itself, which means the daily fallback works even when the CLR is in a broken state.

Automated reload paths. Two paths now drive automatic assembly reload:

  1. WMI Event Alert (immediate) — fires on M-Files version change and runs the reload. New in 5.13.38.82.

  2. Daily Agent job — MFSQL Validate M-Files Version runs spMFCheckAndUpdateAssemblyVersion once per day to catch missed events. Restored and modernised in 5.13.38.82.

Manual reload path (preserved). Environments without SQL Server Agent or where WMI alerts cannot be deployed (for example, SQL Express installations) can still trigger a reload manually:

EXEC dbo.spMFUpdateAssemblies @MFilesVersion = '26.4.XXXXX.X'

The @MFilesVersion parameter is retained for logging and audit purposes; it no longer controls the assembly source path.

Operator action required after upgrade

After upgrading to 5.13.38.82 or later:

  • Confirm that Interop.MFilesAPI.dll is present in the AssemblyInstallPath folder on the SQL Server (the installer places it there automatically).

  • Verify reload by running EXEC dbo.spMFConnectionTest — no errors should be reported.

  • If you previously applied the 26.1 emergency patch, the modified spMFUpdateAssemblies is replaced cleanly by the upgrade. No additional revert steps are required.

Integration Connector — WMI Event Alert (``35.703``). The WMI alert that triggers automatic assembly reloads on M-Files version changes is deployed by 35.703.script.CreateMFilesUpdateAlert.sql. This script ships in the Integration Connector deployment bundle and runs automatically during install and upgrade — in the typical upgrade path no additional step is needed.

If you need to deploy the alert manually (for example, after a database restore or fresh installation without the full bundle):

  1. Open SSMS and connect to the SQL Server that hosts the MFSQL application database.

  2. Set the database context to the MFSQL application database.

  3. Open and run 35.703.script.CreateMFilesUpdateAlert.sql. The script is idempotent — safe to re-run without dropping the existing alert first.

Note

Multiple application databases. On a SQL Server instance with more than one MFSQL application database, run the script once per database. Each execution creates a job and WMI alert scoped to the specific database it targets.

Note

SQL Server Express. On SQL Express (no SQL Server Agent), the alert script skips alert creation cleanly. Reload assemblies manually after M-Files upgrades:

EXEC dbo.spMFUpdateAssemblies;

Compatibility notes

  • MFSettings.MFInstallPath is retained but is no longer used for Interop path resolution. It is preserved for backward compatibility with installer scripts that pass it.

  • MFSettings.MFVersion is retained for logging and for the registry-based version comparison performed by spMFCheckAndUpdateAssemblyVersion.

  • spMFGetMFilesAssemblyVersion is retained as a diagnostic-only helper. Its @IsUpdateAssembly output is informational; it no longer triggers an assembly reload.

Additional refinements in 5.13.38.82

Note

This section is expanded as the release progresses. Customer-facing wording is added here once each change is finalised in the source repo.

Settings-procedure parameter deprecation

spMFsettingsForDBUpdate retains its full signature for backward compatibility — installer scripts and maintenance procedures that pass @MFInstallationPath and @MFilesVersion continue to run unchanged. The procedure documentation is updated to reflect the new role of those two parameters:

  • @MFInstallationPath — deprecated; retained for backward compatibility only. No longer used for Interop DLL resolution.

  • @MFilesVersion — retained for informational and logging purposes. No longer controls assembly file paths.

No customer action required.

Agent job purpose realigned

The daily MFSQL Validate M-Files Version Agent job description has been reframed from “validate M-Files version and update Assemblies when changed” to “validate assembly health and reload if assemblies are missing”. This reflects the post-redesign reality: the job no longer compares stored vs installed versions to decide whether to reload — it ensures the connector’s CLR assemblies are present and healthy, calling spMFCheckAndUpdateAssemblyVersion which now reads the installed version directly from the Windows registry.

Existing installs keep their previous job description until the job is recreated; new installs receive the updated description. No customer action required.

Stale validation script cleaned up

30.100.Script.ValidateMFilesVersion.sql previously contained a one-shot validation call that was already commented out (the parameter signature it referenced no longer existed). The script body has been replaced with an explanatory header pointing to the two scripts that now own validation: 35.702 (daily Agent job) and 35.703 (WMI Event Alert). The file is retained in folder execution order; no functional change.

License expiry date parsing — robustness fix

spMFGetLicense now parses license expiry dates with a TRY_CONVERT cascade that:

  • Detects the separator (., -, or /) and selects the matching SQL conversion style.

  • For slash-separated dates, checks whether the first segment is greater than 12 before applying culture rules — this means an unambiguous dd/mm/yyyy value parses correctly even on a server whose culture is en-us, eliminating a class of silent license-validation failures.

  • Falls back through culture-guided conversions (en-gb → format 103, en-us → format 101) when the segment check is inconclusive.

Replaces the prior BEGIN TRY / BEGIN CATCH block around CONVERT(DATETIME, …) that could produce silent failures (the inner CATCH re-attempted the same conversion that had just failed). No customer action required after upgrade.

Resilient auto-reload during M-Files upgrades

During an M-Files client upgrade the installer briefly removes the previous version’s registry entry before writing the new one, leaving a short window in which no version is recorded. The WMI Event Alert can fire during that window. So that a single alert firing still completes the reload, the alert’s job now polls the registry for a bounded period (up to ~30 minutes) and reloads as soon as the new M-Files version appears — it no longer depends on a perfectly-timed second firing. If an upgrade somehow takes longer than that window, the daily Agent job remains the guaranteed fallback.

The result: after an M-Files upgrade the connector reloads its Interop assembly automatically, without waiting for the next day’s job.

The deploy scripts now include a step-content self-heal: when the on-disk script ships a new job-step body, the existing job (and its bound alert) is automatically dropped and recreated with the new step on the next deploy. No manual sp_delete_job/sp_delete_alert step is required to pick up the new alert behaviour — that work is now automatic. No customer action required.

Audit logging of assembly reloads

Automatic version checks and assembly reloads are now recorded in the connector’s process-audit tables (MFProcessBatch / MFProcessBatchDetail) when detail logging is enabled (MFSettings.App_DetailLogging = 1), giving administrators a queryable history of when an M-Files version change was detected and the assemblies were reloaded. Failures continue to be written to MFLog (which raises the existing email alert) regardless of the detail-logging setting.

SQL Server Express deployment

The Agent-job and alert scripts now detect SQL Server Express — which has no SQL Server Agent — and skip job and alert creation cleanly instead of raising an error during deployment. On SQL Express, reload assemblies manually after an M-Files upgrade using the manual reload path shown above (EXEC dbo.spMFUpdateAssemblies).

Agent-job owner default changed to sa

What changed. The Agent jobs created by 35.702 (daily validation) and 35.703 (WMI Event Alert) are now owned by sa instead of MFSQLConnect.

Why. The job step’s polling loop reads M-Files version subkeys from the Windows registry (xp_regenumkeys) and, on a detected change, delegates to spMFCheckAndUpdateAssemblyVersion which in turn calls spMFUpdateAssemblies. The reload performs sysadmin-only operations (sp_configure 'clr enabled', ALTER DATABASE SET TRUSTWORTHY, CREATE ASSEMBLY UNSAFE, sp_changedbowner) and cannot complete under a non-sysadmin owner. On installs where MFSQLConnect was not a sysadmin, the polling step’s registry read silently returned permission denied and the job looped to its timeout without reloading the assemblies, missing the M-Files version change entirely.

Upgrade behaviour. The deploy scripts include an idempotent owner self-heal: if the existing Agent job is owned by the legacy MFSQLConnect default, the owner is updated to sa automatically on re-deploy. If a site has intentionally set a different sysadmin owner, that override is preserved — the self-heal only touches the legacy default.

Environments that block sa. Many sites disable the sa login. In that case, the script still creates the job with sa as owner and emits a warning at deploy time that sa is disabled or locked. To operate the job in such environments, change the owner after deploy to any sysadmin login — for example, leaving MFSQLConnect as a sysadmin (the standard install posture) and running:

EXEC msdb.dbo.sp_update_job
     @job_name         = N'MFSQL <App_Database> — Set Assembly Update Flag',
     @owner_login_name = N'MFSQLConnect';

Apply the same change to MFSQL Validate <App_Database> M-Files Version.

No action required for installs where sa is enabled; the self-heal applies the new default automatically.

Other internal changes in 5.13.38.82

Full per-object change detail lives in Version Control — Release 5. Headline functional change is covered above.