Building LabVIEW Executables That Prompt For Administrative Rights Under Vista

[YohanShminge]

Hi Everyone,

I've discovered the hard way the differences between Vista and XP...  I've got a compiled LabVIEW program that needs administrative privledges to run.  However, when a user launches the program without proper rights under Vista, it doesn't prompt for administrative rights, it just runs and produces strange errors.  Is there a way to make the program prompt the user for administrative rights so that they don't always have to right-click and select "Run as administrator"?  I heard mention of a "manifest" file that can do this, but I haven't found any details.

Thanks!

[TCPlomp]

I have no solution, but do you know why have to be an Admin to run your program? Do you write data to c:\program files? or any other 'forbidden' location?

Maybe rewriting your app is the best option?

Ton

[YohanShminge]

Well I suspect there are a couple of things causing the administrator requirement.  I do need to write to Program Files for one important thing.  I need to copy two .NET DLLs from another location to my program's execution path (in Program Files) so that they can be used in my program.  Unless you know a way that I can provide a path to those DLLs, this has to be done.  Those same DLLs may or may not need Administrative rights, I'm not sure yet.  Someone mentioned that maybe if I were accessing the DLLs using COM instead of .NET it might not need Administrative privileges?

[TCPlomp]

Why do you need to copy these .Net dlls?

Aren't they properly installed on the computer?

The GAC (I forgot where that stands for) has a list of all installed .Net interfaces if I'm correct.

Ton

[YohanShminge]

Well I'm not too familiar with this, but it seems they're not listed in the GAC (global assembly cache, I believe).  At least, they're not listed under the assembly list when I add a constructor node to LabVIEW.  Now we've got some similar code using these DLLs in MATLAB via the COM interface like so: h = actxserver('RPI_IOBoard.IOBoard').  That works without any path, so the files must be registered somehow?  I suppose if I went with a COM interface that might remove the requirement for copying files...