Plugin is not loading on all environments

we are using XProtect smart client 2023 R1. I created a plugin in c# with .net framework 4.6.1 (I also tried 4.8).

When I build a local version (Release and Debug) from the developer laptop - the plugin works and load on the developer laptop (Win 10) and on the environment (Win 11).

When I build a version on Azure pipeline the plugin works and load on the developer laptop (Win 10) and doesn’t on the environment (Win 11).

we found that the issue is probably with msvcp140.dll or msvcp.dll

do you have any idea what can be the issue?

which versions of msvcp* are on environment Win11 ?

They might be old versions… the latest version is currently 14.42.34438.0

from an administrative command prompt on Win11 try running the command

winget upgrade Microsoft.VCRedist.2015+.x64

We are using 14.42.34433.0

Get Outlook for Android<https://aka.ms/AAb9ysg>

I assume that your plugin is a single dll and you deploy that file together with a plugin.def and nothing else.

Does the dll built the one way differ from the one built the other way?

If you introduce other dependencies you might have other dlls you have to deploy, if this is the scenario please describe what you have.

The Smart Client itself is .Net Framework 4.7.2.

Hi,

Both computers runs the exact same build from Azure pipeline.

In addition to the plugin dll, we have system and Microsoft dll’s + we have our own communication, common and logger dll’s

All dlls are .net 4.6.1 (I also tried 4.8) or netstandard2.0

Erez

What is the error you get (if any)?

I get an error on my code, that there is a mutex that is not initialize, BUT, as I wrote, the issue occurs only on one computer and another build from the developer computer works on the computer that the pipeline build didn’t worked on

The Smart Client 2023 R1comes with msvcp140.dll 14.34.31931.0 in the bin folder. But as it works in one computer and not another I think it might not be relevant.

Why is do you suspect msvcp140.dll or msvcp.dll to be the cause?

You wrote: we found that the issue is probably with msvcp140.dll or msvcp.dll

Can you explain what you found? This might be the information we lack to understand the issue you’re seeing.