The story:

• have a .NET8 WPF app that requires connections to various USB serial devices. Installed in Windows only.
• Wanted to get the Device Descriptors of the USB devices for further info when connecting. Similar to USB Tree View, which was based on USBView
• to get these descriptors I ended up creating a C++ project that compiles to a DLL and then are imported in a separate .NET project.
• Used the following resources to get this working:
• SO question, Blog reference, Mods to code from Blog
• All of this works fine when I build locally
• The important thing is that the C++ code uses the SetupApi.h reference

The specific issues

• during development i got the (0x8007007E) error “The specific module could not be found” relating to the SetupApi.h library. Which led to the solution of adding a pragma comment or adding the library to the linker (i tried both solutions and both work). Example Here
• Once all these linking/library issues were solved the C++ package built, created a DLL, imported to my C# .NET program fine and everything worked, locally.
• However, when I built our software and deployed it on a machine without a development environment (i.e. with visual studio), I now get the same (0x8007007E) for the same SetupApi.h. Which means that the required libraries are not installed in the PC.

Example code:

#include <iostream>
#include <Windows.h>
#include <SetupAPI.h>
#include <cfgmgr32.h >
#include <initguid.h>
#include <usbiodef.h>
#include <usbioctl.h>
#include <combaseapi.h>
#include <winioctl.h>
#include <regex>

int UsbQuery::getUSBCount() {
    //error is thrown from the below code
    HDEVINFO usbInfo = SetupDiGetClassDevs(&GUID_CLASS_USB_DEVICE, NULL, NULL, (DIGCF_PRESENT | DIGCF_DEVICEINTERFACE)); 

    SP_DEVINFO_DATA deviceData;
    deviceData.cbSize = sizeof(SP_DEVINFO_DATA);

    int i = 0;
    while (SetupDiEnumDeviceInfo(usbDeviceInfoSet, i, &deviceData))
    {
        i++;
    }
    return i;
}

What has worked

The one way i have gotten this to work is by installing Visual Studio on the PC the software is deployed to. However, this is obviously not the ultimate solution, but has lead me down the to a path of knowing there is a way to fix it. If I install Visual Studio Community with the following package (and nothing else), the software runs without error.

This package also installs the following SDK:

When I uninstall this package, the deployed software fails to find the setupAPI.h. Leading my to guess that something installed with this package includes the link needed to find SetupApi.

What I have tried

• taking the various “setupApi.dll” or “setupapi.lib” files I can find on my Dev PC and directly including them in my solution in various ways, and copying them to the deployed PC. As I noticed the System32 folder has some files with “setupApi.dll”. DOES NOT WORK
• installing numerous WindowSDK’s and the WDK (without visual studio on the computer), DOES NOT WORK.
• Finding the SDK from the image above. Which I cannot find an installer for the specific .3233 installer. Which I assume means it is specific to Visual Studio?
• trying to include the package dotnet add package Microsoft.Windows.SDK.CPP.arm --version 10.0.22621.3233 on the applicable .NET project. this causes version issues with the TargetPlatform, and was a rabbit hole I didnt think is worth solving.

The software is not really deployed in numerous locations, and there is already some hacky solutions for other aspects of its installation. So if I can copy a folder somewhere, and setup some hacky link to call it, that works too. The main thing is that I obviously cannot install Visual Studio on every computer.
If there is a way to bundle my C++ project DLL to be large and include all the requirements, that is a viable solution. But i have been unsuccessful in figuring out how to compile a C++ project DLL to bundle everything together.
If I can copy the needed *.h, *.lib, or *.dll files as an “Embedded Resource” of the Project, that is acceptable.

Deployment is done via the UWP deployment. We utilize a cloud build script to actually build and store the install files. But when we setup a new PC there are many drivers and custom installs we need, to get everything working. The need for an automated install isnt that important as each deployment already requires decent manual involvement.