building a web-enabled application in 8.6

[nathand]

Can someone explain the proper procedure to build a web-enabled application in LabVIEW 8.6?  (For those not using 8.6, note that it's not the same as previous versions.)  I've followed the directions in the LabVIEW Web Services Tutorial and clearly something is missing.  I have a custom niwebserver.conf (with the document root set properly, etc) included in my project, but when I build the application, LabVIEW instead copies its own niwebserver.conf, ignoring my custom one.  There's no checkbox to use a different niwebserver.conf in the build spec, the way there is for the .ini file.  Any ideas?

[Kameralina]

Hello NathanD

Is there a reason you are trying to use a custom file instead of the one that is produced by LabVIEW itself? 

I will have to look into whether this is in fact possible. 

[nathand]

Yes, there are two reasons: I need my built application to have a different DocumentRoot (as specified in the Web Services tutorial), and I also want the web server in the built application to listen on a different port than the one LabVIEW uses, so that I can run my application and LabVIEW at the same time without port conflicts.

[NathanK]

Sorry Nathan,

I could have sworn that I already responded to this one. I must have forgotten to click submit.

As you probably know- The behavior of the application builder in previous versions was to clone the current LabVIEW environment when building an executable. It would copy the web server tokens into the LV ini file to make the web server in the built exe work exactly the same as LabVIEW's web server.

We tried to do the same thing in 8.6 even though the web server configuration have many more options and is in a separate file. If the web server is turned on in LabVIEW then the application builder will copy LabVIEW's niwebserver.conf file next to the built executable so that its web server will behave the same as the web server in the LabVIEW that built it. It was anticipated that if users needed to customize the configuration that they could edit the copied niwebserver.conf after the application was built and before including it in an installer as they would have edited LabVIEW's ini file in earlier versions.

Ok- now that I've babbled about things that you already know. The actual answer to you question is this: The page that you linked to has two mistakes that will be corrected.

1- The name of the LabVIEW ini config token to specify a custom web server config file is WebServer.ConfigFilePath

2- Don't name your custom config file 'niwebserver.conf' because, as you discovered, it will be overwritten by the app builder when it copies LabVIEW's niwebserver.conf.

Let me know if this helps.

[nathand]

Thanks, those corrections (particularly the name of the .ini token) should help.  I had tried putting my custom niwebserver.conf in the data directory of my application, where it wouldn't be overwritten, but I couldn't get the application to read it there no matter how I specified the path in the .ini file - now I understand why.  I assume that with the correct token I can place the web server configuration file in a subdirectory (for example, data) without problems.

As an aside, I don't see this as identical to the previous behavior, in that LabVIEW 8.5 allows specifying a custom .ini file which could contain web server directives that didn't match the LabVIEW defaults.  It would be nice to have a similar option for the web server configuration.

[NathanK]

Thanks for the feedback. We've been putting some effort into improving this particular use case. It is very helpful when you let us know which tasks were less than easy

[a100man]

Hi Nathan,

Any chance of updating that web page? I just lost a day scratching my head because of the misinformation on that page  

document: 4TR9F13S