Need a way to avoid [DefaultDllImportSearchPaths(DllImportSearchPath.System32)] on some APIs

[alexrp]

Is your feature request related to a problem? Please describe.
[DefaultDllImportSearchPaths(DllImportSearchPath.System32)] is applied to all(?) imports. However, there are some imports where it makes little sense.

Describe the solution you'd like
~Any way to selectively avoid emitting the attribute would work.

Describe alternatives you've considered
I'm not aware of any.

Additional context
In my library where I use the DbgHelp library, I specifically want the user to be able to drop the latest dbghelp.dll and symsrv.dll into their application directory and have my library pick those up. This is essential because the dbghelp.dll that ships with Windows completely lacks symbol server support (that is, symsrv.dll is missing).

[AArnott]

@alexrp, I'm not aware of a Windows licensing agreement that would support your redistributing dbghelp.dll, which otherwise ships with Windows. If you can enlighten me on this, we may offer a way to change this attribute as you requested. Otherwise we'll likely continue generating these attributes assuming the Windows license only permits these libraries to be loaded from the standard Windows location.

[alexrp]

@AArnott I don't know about the licensing situation, but the official documentation for the DbgHelp library suggests that you should get the latest library rather than relying on the one shipped with Windows because it's often out of date and lacks features. Going by that page, it also seems that only the system version of the library is non-redistributable. But it's admittedly hard to find concrete information on this topic, so I could be missing something.

I'll also note that, anecdotally, I've seen many applications ship dbghelp.dll for diagnostics purposes. It'd be surprising if they all did so in violation of whatever license the library is under.

[AArnott]

Oh wow, fascinating. I'm guessing the Windows license still applies to the files that it ships, but if Microsoft ships some of these same DLL's another way, then that other license would apply. As you say, Microsoft's own docs recommend this. I'll look for a way to solve this for you.

[alexrp]

@AArnott FWIW, I had to disable CA5393 to avoid warnings in the generated CsWin32 sources. Since that rule is built into the SDK, I wonder if it would be reasonable for CsWin32 to suppress that rule automatically on relevant methods?