.NET DLL loading issue

We have our plugin running as a third party DLL inside Rhinoceros 5 (SR10 64-bit). Our application’s UI is written using WPF in C# on Win 7 (using Visual Studio 2010/2012) and it also uses two other DLLs, including another DLL with code written in C# and a mixed-mode managed C++ DLL. We are running into a situation where the our DLL is failing to load inside Rhino.

Looking at the dependency walker of the C# DLL doesn’t reveal anything (there is no tree of dependent DLLs). But the managed C++ DLL shows the whole tree of dependent DLLs and says the system cannot find the following files:

API-MS-WIN-APPMODEL-RUNTIME-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
API-MS-WIN-SHCORE-SCALING-L1-1-1.DLL
DCOMP.DLL
IESHIMS.DLL

We first discovered this from our customer installations and not on our systems. But when my boss gave me a build from his machine, I was able reproduce this loading problem on my machine as well. My initial thought was that perhaps we are missing some re-distributable (of VC or .NET). However I have VC2010, VC2012 and also .NET 4.5 on my machine. So that missing re-distributables should not be an issue for me. Can anyone let us know what it is missing? or how to fix this loading issue? Since our application runs inside Rhino, we don’t have much details on the error, other than the message “Unable to load the dll; application initialization failed”.

Are you using the right bitness (32/64) of all DLL’s?

We are currently trying only 64 bit versions (all projects use the x64 settings).

Start by running the TestDotNetMessages command and then restart Rhino and try loading your plug-in. You will find much more loading information dumped into the command window.

Dale, thanks for that tip. At least I was able to figure out why the DLL built by Mike was not loading on my machine and also vice versa. It was a date formatting issue (as I live in India the date is in ddmmyyyy format) in our code. But Mike is having an issue loading the DLL built on a machine and installed on another one. I will send you his traceback as soon as I get it.

It looks like that was the only issue and we were able to verify that it works by commenting out the date check. Interestingly while I understand why the build from Mike didn’t work for me and vice versa (due to date formatting), I can’t figure out why the build was not working even for a Mike’s build from one machine to another. Since both of his machines are apparently in the same country/culture. Anyway, we have currently comment out that date check and will try to figure out how to do it properly.

Thanks for the help guys!