Copy of native DLL does not work for restricted processes

[rima1098]

Describe the bug
As far as I've seen this in the code, the native library is copied to the parent directory.

QuestPDF/Source/QuestPDF/Skia/SkNativeDependencyProvider.cs

Line 39 in 4172016

CopyFileIfNewer(nativeFilePath, targetPath);

This works on our development machines but when deploying software on ISS e.g. we run the process with reduced privileges and it is therefore not allowed to copy files to the parent directory. We are not able to allow the process to do this as it bears security risks.
The issue leads to the exception that the QuestPDFSkia.dll cannot be accessed as it is not present.

Expected behavior
Working with QuestPDF should be possible without giving copy previleges to the process.

Environment
2024.3.6 x64 (Professional License)

Additional context
I assume the copying is necessary to find the correct .dll depending on the runtime. Maybe you can find some other way to resolve the library without copying?

[MarcinZiabek]

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.

[rima1098]

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

[MarcinZiabek]

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>