Another .NET Error 1172 issue

[DailyDose]

Hey everyone.  Yep, another one. Seems to be a common issue.  The whole works when I run it in Development, but after building the application, notta.  I've included my DLL (attached) in the executable build and placed it in the same folder.  LabVIEW apparently automatically includes it in the data folder of the build.

I'm running LabVIEW 2019 SP1 32-bit, Windows 10.

Things I technically haven't done is run it as administrator.  But I can't thanks to IT and their infinite wisdom.  They do, however, allow a "MOCK" admin mode I can use and it didn't work in that mode either.

The constructor node is failing and thus the rest just quits.  I've also attached a simplified version of my actual VI.

Any help would be very appreciated.

[Kyle97330 · Accepted solution]

1172 is unfortunately a catch-all error for about 95% of .NET problems.

Can you include the error text that comes along with it?  Usually it will include the name of what specific .NET exception was generated to help narrow it down.

One of the more common causes that I have seen happen where it fails after making it an EXE is that a DLL will have external dependencies that LabVIEW doesn't know about.  If there are other DLLs in the source directory where DYMO.DLS.SDK.dll comes from, you might need to manually include them.

Edit: 

After the post you made I went ahead and downloaded your DLL and ran it through a DLL checker.  It seems that it's missing the following:

DYMO.DLS.Runtime, Version=8.5.3.1897, Culture=neutral, PublicKeyToken=5426002a38745af9
DYMO.DLS, Version=8.5.3.1897, Culture=neutral, PublicKeyToken=5426002a38745af9
DYMO.Common, Version=8.5.3.1897, Culture=neutral, PublicKeyToken=5426002a38745af9
DYMO.SmartPaste, Version=2.0.0.0, Culture=neutral, PublicKeyToken=5426002a38745af9

You might want to try putting those DLLs in the "data" directory of your build and see if that helps.  

Sometimes for whatever reason the "data" directory isn't enough for LabVIEW to find the support DLLs, and I just have to put the DLLs in the same folder as the EXE (set your data directory to be the same as the application folder in the build spec).  Try that if just adding the missing DLLs doesn't work.

[DailyDose]

So I did exactly what you said and it still didn't work. (Both suggestions)  But seeing the wisdom in what you said and further reading of the error, I went ahead and dumped every single DLL related to that particular program in to my data folder.  Everything works.  Thank you.  You get credit for solution, good sir!

[Kyle97330]

If I had to guess  I would say that those 4 new DLLs had dependencies, then those dependencies had dependencies, and so on.  I've done the "just dump everything in" method before as well with Thorlabs Kinesis, ending up with nearly 100 DLLs but a working program...