Haven't done much with Windows for a long time, but IIRC Windows looks in the current directory for DLLs by default, and it has it in subdirectories. IIRC, there's some way to make an app search relative directories in the exe and maybe the Ginger guys dicked that up? WINE seems to run it if I move the DLLs into the base directory.

$ wget https://github.com/DominaeDev/ginger/releases/download/release-1.6.2/ginger_v1.6.2.zip
$ unp -U ginger_v1.6.2.zip 
$ cd ginger_v1.6.2/
$ wine Ginger.exe 
Unhandled Exception:
System.TypeLoadException: Could not load type of field 'Ginger.SpellChecker:s_Hunspell' (0) due to: Could not load file or assembly 'NHunspell, Version=1.2.5554.16953, Culture=neutral, PublicKeyToken=1ac793ea843b4366' or one of its dependencies.
$ mv Libraries/x64/* ./
$ wine Ginger.exe

And then it works.

EDIT: Hmm. I was thinking that Windows might have something like -rpath to search relative paths for DLLs, but it sounds like it doesn't:

https://ibob.bg/blog/2018/12/16/windows-rpath/

Anyway, you should know that on other operating systems when linking with a shared library (.so or .dylib file), you can supply a search path for it to the linker itself. In fact, to some people’s occasional frustration, the default search path when linking with no specific arguments is the absolute path to the shared library. This search path is called an rpath.

If you do multi-platform programming, you’ve probably experienced frustration with the lack of rpaths on Windows.

If you’re not a Windows programmer, I don’t know why you’re reading this article, but to put it simply: In Windows, shared libraries, or DLLs, don’t have rpaths. Instead the executable searches for a shared library by filename in a variety of places which you cannot control when building the executable. It searches the files in the same directory as the executable, then files in your PATH environment variable, and some other insignificant places. And if the DLL isn’t there?…

When dealing with third party libraries, you typically don’t have such fine control over where their DLL files end up, so copying them alongside your executables is often the choice. This is probably the most popular solution for third party libraries. It’s employed by many existing package managers. This requires a common output directory6 and carries with it the drawbacks of having one, but it’s also wasteful, having multiple copies of the same files over and over again.

To avoid this waste there’s another popular approach here and that is copying or installing third party DLLs to some directory in your PATH. This fixes the problem of filename clashes, but introduces a new one: the so called DLL Hell. DLL Hell is when you have multiple DLLs with the same name in your PATH. Executables will automatically load the first one which matches, but that may not be what you want. There might be differences in version or Debug/Release differences. Such problems are hard to detect and often lead to crazy behavior or, worse, subtle and hard to detect bugs. There is a way to deal with that on Windows (I mentioned redirection manifests above), but it requires you to have control over the DLLs as opposed to the executables. If a third-party vendor doesn’t support redirection manifests, it may be really hard to add them on your own.

So it sounds like copying DLLs a la what I did above isn't an unheard-of approach...