• DepthAI-v2

  • depthai-core version update best practices

Is there a guide or best practice to follow when updating depthai-core versions?

Specifically, I have a Visual Studio dll project that leverages depthai-core among other dlls and I made my source edits to ensure a proper build. However, once my GUI application runs and tries to leverage my custom dll (which again uses depthai-core among others) it crashes saying it can't find my custom dll (though I know the path is correct and the only change is the depthai-core update).

I haven't had time to debug deeper yet so I thought I'd ask if there is a guide or best practice for this? I'm updating from v2.24.0 to v2.29.0 and if I recall correctly, the last time I updated to v2.24.0 I had to to use DependenciesGUI to help determine the missing dependencies.

Is there a better way? Any tips?

    luxd TBF, I'm not to familiar with how windows handles this, I generally use VSC to handle core versions.

    CLAUDE
    There isn't an official comprehensive guide for updating depthai-core versions in Visual Studio projects, but I can share some best practices and troubleshooting steps:

    1. Dependencies Management:

    2. DependencyWalker or Dependencies GUI are good tools, but modern alternatives like Process Monitor (ProcMon) can provide more detailed insights

    3. Check both direct and transitive dependencies since depthai-core updates might bring new dependencies

    4. Build Configuration:

    5. Ensure all projects in your solution use consistent runtime libraries (e.g., all /MD or all /MT)

    6. Match the platform toolset and Windows SDK version across all projects

    7. Verify that the architecture (x86/x64) matches between depthai-core and your DLL

    8. Common Issues:

    9. DLL loading failures often occur because of missing dependencies in the search path

    10. Runtime version mismatches between depthai-core and your application

    11. ABI compatibility issues if mixing debug/release builds

    For your specific case, here are troubleshooting steps:

    1. First-level verification:

      dumpbin /dependents YourCustomDLL.dll

    2. Enable loader snaps to see detailed DLL loading:

      // Add to your application's entry point
SetEnvironmentVariable("ENABLE_LOADER_SNAPS", "1");

    3. Use Process Monitor to trace DLL loading:

    4. Filter for Process Name = your application

    5. Filter for Operation = CreateFile, QueryOpen, Load Image

    6. Look for "NAME NOT FOUND" or "ACCESS DENIED" results

    7. Verify DLL compatibility:

    8. Check if depthai-core 2.29.0 requires newer Visual C++ redistributables

    9. Ensure all dependent DLLs are either in the same directory as your executable or in the system PATH

    Thanks,
    Jaka

    • luxd replied to this.
        5 days later

        jakaskerl So in looking at this a bit deeper I see there is a dependency change from v2.26.0 to v2.27.0 regarding curl. It's in CMakeLists.txt L482-488 if the previous link doesn't deep link properly.

        When I point to v2.26.0 dlls in my Visual Studio project from depthai's prebuilt depthai-core-v2.26.0-win64/bin/ everything works—currently these are depthai-core.dll, depthai-opencv.dll, and libusb-1.0.dll. This is true for all update cases from v2.24.0 through v2.26.0.

        However, when I do the same with v2.27.0 I get the aforementioned crash.

        I'm currently under the impression that the crash is due to the lack of a curl.dll (or similar) that should be included in the depthai-core-v2.27.0-win64/bin dir.

        1. Should this missing dll be included? I'm thinking yes, akin to how the libusb-1.0.dll is—but I'd love to know why I'm wrong if so.
        2. Am I misunderstanding something?
        3. I'm less familiar with building from source in C++, so I may need to start doing this, but does the v7.88.1-p0-custom curl dll result as part of the build process when DEPTHAI_ENABLE_CURL is enabled?
            10 days later