Copy of native DLL does not work for restricted processes about questpdf HOT 3 OPEN

Could you please share more details about your application? Does it use the legacy .NET Framework or the modern .NET 5 and beyond?

Technically, the native files should be loaded automatically by .NET. However, for some applications, this does not happen for no apparent reason. Copying files is a last-resort approach to make the library work.

from questpdf.

Ah I see, we are indeed using legacy .NET Framework (net472). I was not aware that this is only executed as a fallback. We did a workaround with a copy job in our pipeline, guess we will stick to that then :D

from questpdf.

I experienced this issue even for two identical projects in the same solution. One was working, and one was not.

I will investigate additional steps in the msbuild .targets file that can also perform the copy operation during the build process. The only difficulty is that the target runtime needs to be known during this step.

Essentially, it requires the following code in the .csproj file, which I believe could be missing in many projects. Thus, making this solution of little value.

<PropertyGroup>
  <RuntimeIdentifier>win-x64</RuntimeIdentifier> <!-- or win-x86 -->
</PropertyGroup>

from questpdf.