Search code examples
vb.netversiondllimportmigrating

Dll won't load problem migrating from VS2019 under Windows 10 to VS2022 under Windows VB

As above I'm migrating an app from Win10, VS2019 to Win11 VS2022. In the Win11/2022 environment, I'm getting a "Unable to load dll...or one of it's dependencies. The specified module could not be found." Note that the parent app is a 32 bit (X86) vb app. The DLL is c++ (vs2013).

The DLL is fully qualified. I ran dumpbin against the dll and the 6 dependencies are all in syswow64 as is the dll.

Here's the declaration and offending function call,

<DllImport("C:\windows\syswow64\MyFile.dll", CallingConvention:=CallingConvention.Cdecl)>

Public Shared Function MyFile_open_device(ByVal index As Integer, ByRef errorCode As IntPtr) As Integer

End Function

In the mainline code MyFile_open_device is nested in a Try block that in turn throws the Try block's text explanation.

Other than questions you may have or suggestions as to how to diagnose (both of which are welcome), I'm wondering if anyone is aware of any changes between 10/11 or 2019/2022 that would cause this condition.

Here's the declaration and offending function call,

<DllImport("C:\windows\syswow64\MyFile.dll", CallingConvention:=CallingConvention.Cdecl)>

Public Shared Function MyFile_open_device(ByVal index As Integer, ByRef errorCode As IntPtr) As Integer

End Function

I'm getting a "Unable to load dll...or one of it's dependencies. The specified module could not be found."

Solution

  • Have you forced the project to x86?

    You can't use "ANY CPU" since vs2022 is the FIRST version of VS that is x64 bits.

    So, when you build and run, you going to have a x64 bit project when using ANY CPU. Previous versions of VS meant that ANY CPU resulted in a x32 bit default and run, since any version of vs before vs2022 was a x32 bit version.

    Now that vs2022 is x64 bits, then the default ANY CPU results in your project running as x64 bits, and as such, they can't consume x32 bit dll's.

    Hence, select (force) the project to run as x32 bits from here:

    enter image description here

    In addition to the above, I have to say that .dll's in the c:\windows has been locked down for years, and thus often such .dll's will be locked down, or even intercepted by virus scanning software. And to copy such files to the system folder, you will need elevated rights (hence, that location is really less then ideal for your custom dll’s).

    Even projects previous to vs2022 should force the CPU settings, since unless your code and dependencies can run as x64, or x32 bits, (all .net code .dll's), then leaving this to chance and using ANY CPU means you have little idea as to what bit size your application will run as.

    In your case, since those are x32 bit dll's, then you need to force your project to run as x86, and the default ANY CPU now results in an x64 bit program, not a x32 one (which was the default result when using versions of VS before vs2022.

    I would move those .dll's, and also right click on them, and make sure they are un-blocked, since .net will not consume such .dll's if they been for example downloaded from the internet. In fact, even when downloading a zip file with some sample code and .dll's in that zip file? When you un-zip, the files are blocked and can't be used by .net.

    So, you need to ensure that you un-block the zip file before unpacking, since any .dll's inside of that zip will also be tagged as blocked and un-safe.

    So, unblock the zip file before un-zipping. Or, after un-zipping, then unblock all files and .dll's in that unzipped folder.

    Hence this option:

    enter image description here