Published Web Services, support directory dlls

[msoflaherty]

I've been building my first application using NI Web Services. It's worked pretty well; I have a collection of web resources under my web service, with a startup vi set to my main application. When I run from right-click->Start, it starts up, publishes the service to the debug application web server and I can view and interact via the web. Great.

Similarly, I can right-click and do 'Publish', in which case the service gets pushed to the NI application web server, no longer on the debug port (8001) but on the normal port (8080). All well and good: pages are still accessible and the startup vi of my application clearly runs in the background to support it.

However, I have content (ZMQ messaging) that when built as an application requires dll's in the support (data) directory. Normally with a built application i'd just copy them in, but in this case the build files are only generated when i publish, and 'restarting' the service doesn't seem to do anything. In fact, given the different structure for files in this case, I'm not even sure where i'd put them.

Can anyone advise how to include support dll's for published web services?

Thanks

[msoflaherty]

A second, less important and unrelated query is the use of remote front panels for published web services.

When starting the web resource from right-click->Start, i can view and interact with the startup vi's front panel, and (with some difficulty) even got it available via a web browser for remote control. But when published, the front panel doesn't show (even including a front-panel open invoke method - presumably the FP gets stripped out, but without access to the build specifications, i don't see how to prevent this), and I haven't been able to figure out the necessary steps to make it available from a browser. Both of these would be nice - I'd like the front panel to be available for local users, and the remote front panel would offer a more polished interface for people with the LVRTE installed. 

Is this even possible - to publish remote front panels from the application web server? I've seen details for remote front panels within the IDE and for built applications, but I don't think either of these instructions work for published web resources.

[msoflaherty]

So the dlls required by ZMQ are located via a vi that will derive a path based on a conditional disable structure, returning a path either to 'vi.lib/addons/zmq/lvzmq64.dll' in the case of a non-runtime environment, or to 'application directory/data/lvzmq64.dll' for runtime environment. The call library node is returning error 7, indicating it can't find them, so somehow these paths aren't being found.

I tried just replacing the conditional structure with a constant absolute filepath to the file in vilib/addons/zmq, since I'm not bothered about portability, but still no luck; looking at the 'Call Library Node' help page, it seems this absolute path will get converted to a relative path automatically on build anyway (very helpful).

I then followed up on how to otherwise specify where to find missing dlls.

If the application had a .ini file i could edit, I could add the vi search path to that, but there isn't an .exe and I can't find the relevant .ini.

Alternatively, labview will search locations specified in the 'path' environmental variable - so i added the path in vilib/addons/zmq to that. Nope.

Alternatively, labview will search Windows\System32 - so i copied the dlls in there. Nope.

Alternatively, I tried editing the vi search path in the project. I'm not sure if this gets passed down, but it was a last ditch try. And nope.

... Any other ideas?

[msoflaherty]

OK, well I tried removing the path to the dll and simply specifying by name. Now it works.

It seems a bit of a flaw that, if you want to specify by path, the fall-back searches won't operate.

I don't know which of the dll's it's now finding - those in vilib, those in system32... at some point i'll try deleting them and see where it fails.

I'm not going to mark this 'solved' yet, as this doesn't seem like a "solution" for providing support directories to web published services.

Question 2 is still open, on remote front panels, but perhaps would be better migrated to a new thread.