indirect `DllImport`-ed files are not copied on "Out"-Deployment for a TestRun

[LukasGelke]

Summary

I need to copy a Native DLL to the Test-Run-Deplyoment folder, with "minimal effort". (For VisualStudio locally and vstest/dotnet in Pipelines)

Background and Motivation

As System.Data.SqlClient is deprecated, we are switching to Microsoft.Data.SqlClient. One caveat is that (under Windows, but currently our main Platform) there is a Native DLL necesarry (Microsoft.Data.SqlClient.SNI.x64.dll (NetFramework) / win-x64\native\Microsoft.Data.SqlClient.SNI.dll (Net) or whatever target architechture). These DLLs are present in the build output. However it will not be copied upon an MsTest Deployment (ie the "Out" folder), because it is only referenced via Dll-Import as far as i understand

Proposed Feature

(one of:)
a) DeploymentItemAttribute for entire Assembly

• currently, tests will work if given [DeploymentItem("Microsoft.Data.SqlClient.SNI.x64.dll")]. However it is unfeasible to provide this attribute for all affected tests (even if using it on the class)
  • and there would be #ifs for NetFramework vs net8
• making a crude Compile-Include in the Directory.Build.targets would certainly be convenient, even if that's bad design

b) simmilar to a: a Property-List in the runsettings that specifies such files (with the same syntax as the sttribute? And/Or EnvVar resolution?)

• this appears to had been possible previously with the also now deprecated testsettings file. But I cannot find information if this exists in the runsettings format (without using legacy stuff)

c) "somehow" figure out that there is a Dependency

• the DllImportAttribute may not specify a full path and no search path; so not sure if going just by reflection and that name would be reliable
• unless there may be a runsettings-Property, i.e. Name-Allow-List or similar

d) "somehow" change the M.D.SqlClient Library, so that MsTest can pick it up

• which would be "their issue"
• not sure if that's even possible at all or has other/worse implications/drawbacks

Alternative Designs

Trying to reference the SNI.dll in the Test Project does not work. Using None/Content will not copy it on Test. Using Reference is not possible, because it does only allow managed dlls.

[nohwnd]

So if I read this correctly your bin folder has all the right dependencies, and it is just the deployment folder that you get because of DeploymentItem that does not have that dependency?

We generally try to discourage usage of DeploymentItem attribute, is there a specific reason why you are using it?

[LukasGelke]

yes.
Though we use a combined OutputDirectoy in our builds, for legacy reasons (yes its not recommended), but it has the SNI.dll

Test method ... threw exception: 
Unable to load DLL 'Microsoft.Data.SqlClient.SNI.x64.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)

while the working directory is esentially <Repo>\TestResults\Deploy_<Name> 20250502T143731_28600\Out

---

I know that DeplyomentItem is discouraged, and we have started to transition to different, more stable implementations (ie Streams instead of files).

The reason i choose DeploymentItem is because it was the first thing that worked out of the box (at least "small scale").

Come to think of it, another idea would be to include the SNI.dll in the Test-Project/Assembly as an embedded Resource but this seems kind of a roundabout way (since its a DLL after all) - but might be the way.

Since this issue also affects NetFramework, i also found no way to attach to some sort of assembly resolution event easily, that includes native dlls.

It also seems that the Deplyoment is enabled by default. Disabling that would probably also get the tests to pass again, however it seems like an unwise decision (because one presumes it is default true for a good reason), and because a bunch of tests still "pollute" the run directory anyway (which may not desired locally with VS)

[LukasGelke]

I found a workaround: include the appropriate native dll via EmbeddedResource and GeneratePathProperty in the appropriate test-projects via Directory.Build.targets, and extract them at Test-Init. Using File.Exists and a Mutex also solves any (?) IOExceptions caused by parallelism.
It's kinda hacky, but it works for now.