NOTE: This main purpose of the question to UNDERSTAND/EXPLAIN the assembly binding behavior of the CLR. The solution should be evident once the
As far as I can work out and with a fair amount of supposition...
The .NET assemblies in the /bin folder are automatically loaded by ASP.NET when the website starts, but any native win32 DLLs aren't loaded.
The DLLImport is failing because the DllImport is done relative to the w3wp.exe process NOT relative to the website project. An AppPool can be shared between many websites so your website's /bin folder can't be the CurrentDirectory for the w3wp.exe process even supposing there aren't security issues with doing that.
So to find the DLL, IIS is looking first in the folder where 'w3wp.exe' is located, and then checking the Windows System folders.
In theory, you should be able to use LoadLibrary() and GetProcAddress() to load the DLLs from a specific folder.
Incidentally, If you're using DllImport() in a class defined within the website project you may need to change the default compilation mode for ASP.NET to 'safe'. To allow unsafe code to be used you can update your web.config file: