depthai-core version update best practices

luxd

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?

jakaskerl

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:

Dependencies Management:
DependencyWalker or Dependencies GUI are good tools, but modern alternatives like Process Monitor (ProcMon) can provide more detailed insights
Check both direct and transitive dependencies since depthai-core updates might bring new dependencies
Build Configuration:
Ensure all projects in your solution use consistent runtime libraries (e.g., all /MD or all /MT)
Match the platform toolset and Windows SDK version across all projects
Verify that the architecture (x86/x64) matches between depthai-core and your DLL
Common Issues:
DLL loading failures often occur because of missing dependencies in the search path
Runtime version mismatches between depthai-core and your application
ABI compatibility issues if mixing debug/release builds

For your specific case, here are troubleshooting steps:

First-level verification:

dumpbin /dependents YourCustomDLL.dll

Enable loader snaps to see detailed DLL loading:

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

Use Process Monitor to trace DLL loading:
Filter for Process Name = your application
Filter for Operation = CreateFile, QueryOpen, Load Image
Look for "NAME NOT FOUND" or "ACCESS DENIED" results
Verify DLL compatibility:
Check if depthai-core 2.29.0 requires newer Visual C++ redistributables
Ensure all dependent DLLs are either in the same directory as your executable or in the system PATH

Thanks,
Jaka

luxd

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.

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.
Am I misunderstanding something?
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?

jakaskerl

luxd
cc @MatevzMorato on this 🙂

luxd

@MatevzMorato Bumping this for when you have a moment