Hello guys.
I have searched for the last year up and down and tried lots of things about this, but nothing gets close to a solution that I like.
First some background:
We have a network and several computers running different things, but it started out by each PC running LV 8.5.1 from the local hard drive. Then in the past years we did some upgrading, one machine at a time, at a little slow pace. Some hardware got swapped, and processes got changed or altered, so it was more feasible to run in development mode to debug the changes.
Now that the process of upgrading is almost complete, I wanted to do things different for future upgrade rounds. Over the years it got messy to always alter some labview code on a machine, then on a another, and then in between forget to properly check in and update through subversion. So then there's conflicts to resolve. And this gets old quite fast.
I have a server with a spacious share that I want to host all the software on, so that every PC runs the same codebase. It works beautifully, and its a lot easier to handle code changes and subversion versions. Even different labview versions and builds are more structured like this. Then of course reality kicks in. You can't have good things just like that can you.
Most of the codebase relies on a .dll file that has all the links to a SQL server for running all sorts of queries. It is a big thing, and it was developed by an external company so we don't sit on the source for it ourselves.
So after I started to move all things to the central shares, some machines started to malfunction. It seemed it was problem with that some run Win10, some Win7 or XP. Some had LV8.5.1 and some LV2018 and 2019. So I troubleshooted into the path of different OS's and compatibilty and got a new compiled .dll for win10x64. This was all a dead end. Since the .dll suddenly stopped working on LV 8.5.1 machines too in a test, I found the culprit. Having Labview load an .dll assembly from a shared folder from another PC would always fail, if you had just booted up labview, and not touched anything that could activate the .dll on its local c: drive.
It all boils down to some stupid security thing with loading assemblies from shared folder, that the entire internet does not know how to solve or wish to keep a secret. There are some posts here, but none answers anything related. There is nothing wrong with the assembly itself, and 99% of posts on this forum attack the code inside for bugs, but it will always run perfect - if its on the c:\ drive somewhere. So please, anyone got an idea to circumvent that issue, other than keeping local copies of builds/code on every hard drive?
This is related, dead quite recent thread with no answer. I get the exact same thing happening if I open ".NET assemblies in memory" if I have an VI already open that wants to load the assembly form the shared drive:
https://forums.ni.com/t5/LabVIEW/When-I-view-net-assamblie-in-memory-I-get-error-1097/td-p/3972682?p...
I have tried this to no avail. I have never seen the "security override" option that is ringed in on any windows OS either:
https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P8XnSAK&l=en-GB
Fiddling with different .NET versions leads no where as well. Downgrading .net, upgrading .net, running as administrator or making an extra config file with loadFromRemoteSources enabled="true". Nothing. The error will come straight from the Constructor Node (error 1386) or crash the .NET assembly memory viewer with error 1097.
Have anyone been able to run code from a central server with assemblies? How did you do it to get around this bug? 😁
Thanks 🙂
