This is a bug report/workaround notice for web services on LabView 2009.
LabView on Windows supports web services. A web service is Labview code that is executed by LabView's embedded web server in response to a URL. The process for building a web service with LabView is similar to the process for building an EXE: VIs are stripped of their block diagram, copied to target location, zipped, and renamed to a .lvws extension. To actually use a web service, it must be "deployed". The act of deploying the web service takes the *.lvws file, unzips it to the web service deployment path, and registers the deployed web service with with the embedded web server.
I have been working on an issue with web services where the service builds and deploys successfully but fails to work (it returns HTTP error 404). The cause of failure is VI path lengths that exceed Windows' MAX_PATH limit. See this thread .
It is easy to exceed MAX_PATH. The web service deployment folder for LV2009 is %CommonAppData%\National Instruments\Web Services 2009 32-bit\User Services\deployed\{web service name}-{37 char GUID} . On XP/2003, %CommonAppData% maps to "C:\Documents and Settings\All Users\Application Data", with the result that the deployment paths are a minimum of 160 characters long before any user VIs are counted. User paths can easily consume the remaining 90-odd characters because web services are deployed with the "preserve disk hierarchy" flag set to true, which means the original hierarchy of VIs is re-created as part of deploying the web service. The full path of, for example, a VI in the commonly-used OpenG Variant Config library is:
C:\Documents and Settings\All Users\Application Data\
National Instruments\Web Services 2009 32-bit\UserServices\deployed\TestWebService-0459F868-AECF-4CBF-81F9-0E67EA27A5D7\internal.llb\
LabVIEW 2009\user.lib\_OpenG.lib\variantconfig\variantconfig.llb\Encode Section and Key Names__ogtk.vi
This is 288 characters, and not a legal WinAPI path. Unlike an EXE, web services are unzipped on the disk prior to execution, so the exceeding MAX_PATH in this manner results in failure during unzipping.
LabView 2009 web service issues:
- LabView should not declare that a web service deployed successfully when in fact it failed during the unzipping portion of the deployment and required files are missing.
- LabView should provide guidance on MAX_PATH limits during deployment of web services as it does when building an EXE.
- Everyone is trying to do the right thing with descriptive paths, but the WinAPI can't take it. NI should consider shortening deployment paths inside %CommonAppData%.
- The user disk hierarchy should not be re-created inside the web service deployment directory. The "preserve disk hierarchy" option is new with LV 2009 and, while it is much appreciated in the EXE context, it leads to failure in the web service case. Enabling the "Advanced -> Use LabView 8.x file layout" switch on the web service properties pages flattens the hierarchy and allows the build to succeed (in most cases.) This should be the default for web service builds.
Use of Advanced -> Use LabView 8.x file layout was suggested by John Lokanis in
this LAVA post. Setting this switch is the workaround for the issue under LV 2009. It reduces the above path to:
C:\Documents and Settings\All Users\Application Data\National Instruments\Web Services 2009 32-bit\UserServices\deployed\TestWebService-0459F868-AECF-4CBF-81F9-0E67EA27A5D7\internal.llb\Encode Section and Key Names__ogtk.vi
which is still a mouthful, but under the MAX_PATH limit.
-Rob
