Error running some HTTP VIs

[Neil Pate]

Hi All,

 

I have a strange error which manifests itself on some of the PCs I am trying to run a built application on. I stripped everything out and have traced the error down to a single VI, OpenHandle.vi in the HTTP library which ships with LabVIEW. The error code I get out seems to point to something fundamentally wrong with this PC as it is saying "Failed to load library".

 

This does not happen on all PCs, only some. Does anybody know if the HTTP VIs call some DLL or something (the VI is password protected) that I should be distributing with the application?

 

Has anybody seen this error before? Google does not seem to know much about it.

[Neil Pate]

OK, hopefully gotten to the bottom of it. Looks like it was just a messed up installation of LabVIEW. Removing everything NI related and re-installing the runtime seems to have fixed it.

 

Is there a holding thumbs emoticon?

[Neil Pate]

More info on this error in case anybody else stumbles upon it.

 

I still do not know what causes this problem, and the only reliable solution I have found so far is to install the LV runtime engine manually before proceeding with the application installer. This is not a very satisfying fix for the problem, and am not devoting some time to looking into alternate install creators as I do not think the one built into LabVIEW is doing a very good job.

[mje]

We abandoned the NI built installers with the 2011 release over similar issues, the 64-bit IDE was failing to package up the entire RTE even when asked. You're not alone.

[Neil Pate]

We abandoned the NI built installers with the 2011 release over similar issues, the 64-bit IDE was failing to package up the entire RTE even when asked. You're not alone.

 

"Glad" to hear I am not alone in my frustrations here. If you don't mind me asking which 3rd party setup generation tool did you settle on? From speaking with a few others it seems that Inno Setup is quite a good option.

[mje]

InnoSetup is awesome.

We have a corporate installer team that handles installers for all our commercial products and they use InstallShield. I'm grateful for what the installer team contributes and think they do a great job, but I don't have any positive recommendations regarding the use of InstallShield itself.

For non-commercial projects which my group maintains full control of (internal software, beta-collaborations, R&D) we use Jack D's Deploy which uses InnoSetup under the hood. I haven't found anything I can't do by hacking up an InnoSetup script. Mixed mode 32/64 bit installers, doing install time checks (Pascal!) for third party libraries and installing if missing, it allows me to do exactly what I want. I definitely recommend InnoSetup, whether you use it directly or through a product like Deploy.

[ShaunR]

InnoSetup is awesome.

 

I concur. Make sure you get the GUI which is separate (Inno Setup is the script engine).

[Neil Pate]

Thanks guys, I have done a bit of tinkering with InnoSetup (and the Script generation GUI) and really like it.

 

Now I just have to figure out how to include the various bits and pieces of the runtime engine, webservices and .NET client.

[Neil Pate]

Hi All,

 

So I have spent a large portion of my weekend either changing nappies or trying to get a LabVIEW application running on a fresh PC (in a VM). Basically I am trying to streamline the RTE (using a technique similar to Jack's described here). I will admit I have not made very much progress, I can run a very simple app, but have not yet found the magic sauce for making .NET4 DLLs work, or WebServices.

 

I have two simple builds that I am trying to run. One is a simple .NET DLL test, the other a WebService test. The first fails to run properly with a broken run arrow, the second runs, but I get a LabVIEW error the same at the original post in this thread.

 

Any tips here on which parts of the RTE I should be using? Note I tried the components described in this document to try and make the WebServices work, no luck.

 

Edit: ok figured out the .NET portion (maybe) needed to include VC2010MSMs.

 

Help!

Neil

[mje]

My recommendation is to just ship everything. If you try to be too sneaky with the RTE it can cause you issues if another application installs that loads the same environment. What if you don't install the math libraries but another application needs it? Most installers only check for the registry key added by the core RTE. I don't know how "well" the NI built installers behave with a previously segmented environment, but I expect not well considering if they did their job people like us wouldn't be on this mess.

If you try to outsmart the RTE, it will likely cause issues because it's just not that smart to begin with. I really do wish it was, because like you I've lost days to these issues.

[Neil Pate]

Yeah I have that feeling too, it just feels so unnecessary to package the whole RTE with my application. Also, it makes the install process a bit weird as the user has to click through the LV RTE install dialogs. If I could find a way to supress those I would settle for that. This should be possible, I just have no idea how

[Phillip Brooks]

I think that these RTE Install options are still valid:

 

Silent Installation of the LabVIEW Run-Time Engine

[ShaunR]

Yeah I have that feeling too, it just feels so unnecessary to package the whole RTE with my application. Also, it makes the install process a bit weird as the user has to click through the LV RTE install dialogs. If I could find a way to supress those I would settle for that. This should be possible, I just have no idea how

Edit:

Yes. What Phillip said.

Edited February 24, 2014 by ShaunR

[mje]

There are many things you'll find on at NI's website, which makes me think that at least some people there must be banging their heads running into these issues, so maybe there is hope.

 

There's many ways to skin this one: I take the RTE distributed by NI, run the self-extracting EXE locally, then package up the result into my installer. At run-time I evaluate which (32 or 64 bit) to extract/execute and call the setup.exe with "/q /AcceptLicenses yes /r /disableNotificationCheck" (reference).

I'll add my code for checking if the native version of the LV RTE is present:

function IsLabVIEWMissing: Boolean;begin    result := not RegKeyExists(HKLM, 'SOFTWARENational InstrumentsLabVIEW Run-Time13.0');end;

Tests like this are evaluated in the Files and Run sections to determine if the appropriate item needs to be executed. Similar tests for .NET, MSVC.

[Neil Pate]

Thanks for the tips guys,

 

I am getting there, slowly! This is my current [Run] section

 

[Run];Filename: "{tmp}InstallDotNET4dotNetFx40_Full_x86_x64.exe"; Parameters: "/q"; WorkingDir: "{tmp}InstallDotNET4"Filename: "{tmp}LVRTE_Extractedsetup.exe"; Parameters: "/q /AcceptLicenses yes /log /r /disableNotificationCheck"; WorkingDir: "{tmp}LVRTE_extracted"; Flags: waituntilterminated

[Neil Pate]

Although this process is painful I am learning a tonne of new things about VirtualBox and InnoSetup.

 

VirtualBox is a mighty impressive piece of software, I cannot believe I have not been making more use of it (especially snapshotting).

[JackDunaway]

I am trying to streamline the RTE (using a technique similar to Jack's described here). I will admit I have not made very much progress, I can run a very simple app, but have not yet found the magic sauce for making .NET4 DLLs work, or WebServices.

 

If you're distributing a Web Service, ship the entire, Full RTE. LV2013 Web service run-time dependencies reticulate throughout a wide smattering of RTE packages, and I've been as-yet unsuccessful to pare to a reasonable subset. (Reference: experience gained through significant efforts over the past year to do this, and far more time in front of ProcMon consoles than what's healthy)

My recommendation is to just ship everything. If you try to be too sneaky with the RTE it can cause you issues if another application installs that loads the same environment. What if you don't install the math libraries but another application needs it? Most installers only check for the registry key added by the core RTE. I don't know how "well" the NI built installers behave with a previously segmented environment, but I expect not well considering if they did their job people like us wouldn't be on this mess.

 

 

True. A pre-requisite for paring the RTE is the assumption that other LabVIEW applications deployed into the same environment package all their dependencies as part of the deployment. If you're distributing apps that don't ensure all dependencies are within the deployment, instead assuming the deployment environment already contains expected dependencies, even though that's a risky deployment strategy, it's likely to end in some heartache for both dev and end-users.

[Neil Pate]

If you're distributing a Web Service, ship the entire, Full RTE. LV2013 Web service run-time dependencies reticulate throughout a wide smattering of RTE packages, and I've been as-yet unsuccessful to pare to a reasonable subset. (Reference: experience gained through significant efforts over the past year to do this, and far more time in front of ProcMon consoles than what's healthy)

 

This is what I ended up doing. I spent days trying to figure out which dependencies were required, and gave up in the end after trying many different "sensible" permutations.

 

I have gained a whole heap of Inno Setup knowldege and random installer stuff now though, so I suppose it is time well spent.

[ShaunR]

This is what I ended up doing. I spent days trying to figure out which dependencies were required, and gave up in the end after trying many different "sensible" permutations.

 

I have gained a whole heap of Inno Setup knowldege and random installer stuff now though, so I suppose it is time well spent.

 

If you are as impressed with Inno Setup as I am (couldn't live without it). you might consider a donation.

[Neil Pate]

If you are as impressed with Inno Setup as I am (couldn't live without it). you might consider a donation.

 

Indeed, a worthy cause. I was browsing the donation page earlier today and spotted a few familiar names there