Executable works on drive C, but reports broken upon launching from a mapped network drive

[PJS]

I have a built executable.  If I take the entire exe build directory and copy it to the target C drive, it works like a champ, but if I copy the entire directory to a mapped network drive, I get the following error message from the Runtime engine:

It does seem adamant, but I am getting no useful information. The program was built in LV2009 and 2009SP1 with the same result. Ideas?

[Cory_K]

The executable will work on your C drive because you have a full version of LabVIEW with all the necessary libraries and dependencies on that computer.

On a network drive, you would need to build and installer.

That way, all computers that didnt already have LabVIEW could install the necessary run-time engine (RTE),

as well as obtaining any necessary subVI's, libraries, etc.

[PJS]

The target machine has the RTE installed already, but NOT the full development environment. 

The EXE runs on the target machines local drive.

The EXE will NOT run on a mapped network drive on the SAME target machine

[Cory_K]

---

@PJS wrote:

The target machine has the RTE installed already, but NOT the full development environment. 

The EXE runs on the target machines local drive.

The EXE will NOT run on a mapped network drive on the SAME target machine

---

Oh okay I understand what the problem is now. Hmm that is strange.

Why is that error message saying "this VI is not an executable". Are you sure the build exe worked correctly?

[PJS]

If I did not build it correctly, it would not run when copied to the local machine.  

[Cory_K]

---

@PJS wrote:

If I did not build it correctly, it would not run when copied to the local machine.  

---

Touche 

[Cory_K]

Alright, here's my last shot in the dark:

You know how when working with files, you can either put a local file name, "example.example"

or you can put the full file name, "C:\blah\blah\blah\example.example"?

Maybe some Windows or LabVIEW dll's or functions are being called by LabVIEW native functions.

When looking for these files, instead of a full file name, they are only looking in the scope of the local drive.

This would work fine if the executable was running on the C drive, because thats where the Windows dlls and LabVIEW progam files are.

But this would be an issue on any other drive, including a network drive.

Spoiler

The above rambling sounds like some convoluted explanation Nicolas Cage would come up with in a National Treasure movie, but what the heck

[PJS]

That is what I am looking into at the moment.  The application gets built and has two DLLs that deploy with it.  

The first is lvanlys.dll, which I do not expect to be the problem.

The second one is from measurement computing.  DAQFlex.dll, a .Net assembly.  

When I made the build, I set the support directory in the build to be the same as the executable

To the best of my understanding, when a .Net assembly is accessed, it first looks in the EXE directory, before looking at the global cache.  It maybe that there is an issue when the EXE is on a Network share/drive instead of the local disk.  If this is the case, then I may need to install the daqflex.dll to the global cache.  

Currently the target computer (test system) is running, so I cannot pursue it till probably Monday, but we will see.

[smercurio_fc · Accepted solution]

.NET has a security protocol that will not allow you to run .NET applications (or apps that use .NET assemblies) from a network drive. This is by design.

You can set up permissions for .NET assemblies to allow .NET to run from a network drive, but I've never had much luck with this actually working. (Just Google for this.)

[PJS]

Sure enough.  Ran the MC flexdaq install and removed the TWO dlls from the build directory.  But added the MC install path into the search path of the executable ini.  Runs like a champ.

Thanks