Missing DLL file from autobuilt distribution kit

[andytheape]

Hi folks,

Here's an interesting one for you. Would appreciate any light anyone could shed on this!

I have a LabWindows project which interfaces to a third-party (not NI) piece of hardware via a set of libraries/headers etc. provided by the manufacturer. I build this project into a distribution kit and LabWindows automatically includes one of the required DLLs for this hardware in the distribution kit. On my development machine, everything comes together beautifully and I get a nice distribution kit that installs just fine.

Now, I love my continuous integration, so I have a Windows 2000 box here working as an autobuilder. I use Draco.NET to poll my Subversion repository for changes and when it sees something change, it grabs the latest version of the source and attempts to build me a distribution kit via a NAnt build script which calls a hacked version of NI's ActiveX build.exe program which I've modified to support building of distribution kits.

Here's the problem: these autobuilt distribution kits never include that particular DLL. What makes this stranger is that if I fire off the build by hand on the server (running the NAnt script myself at the command prompt), the distribution kits do contain the DLL. This would suggest everything is in place that needs to be: the machine is obviously capable of giving me a good build.

Anyone got any clues as to what might be going on here? Could it be something to do with the user the build process is running as? File permissions? Something strange with the ActiveX distribution kit call? I'm sure there's something I've overlooked here, but can't see it myself.

Many thanks,


Andy

PS, NI, I would love to have full support for building distribution kits at the command line... you know, just in case some of your programmers were bored one Sunday afternoon The ActiveX hack works for me most of the time, but if the build bombs on the autobuilder for some reason, LabWindows tends to spit out an error dialogue box and then just sit there. Of course, NAnt never gets to hear about it so it just fails with a timeout and Draco.NET simply sends me an email to say the build timed out. All the useful information (the real reason for the build failure) is trapped in that error box and I'm left with another stranded instance of CVI running on the server. compile.exe project.prj -distributionKit would make me a very happy chap!

[Mert_A.]

Hi Andy,

After looking into this, I discovered that this is a bug that was introduced between version 8.0.1 and 8.1.  The project dependency DLLs (like the one you are missing) will fail to be added if the project has not been built between the time CVI is launched and the time you initiate the distribution build.  Even though the distribution build will initiate project builds as needed, it is too late at that point.  This will be fixed in the next release of CVI.

For now, you can workaround the problem by editing build.exe to explicitly build the project before building the distribution.  I'm sorry for any inconvenience this has caused you.  If you have any trouble with the workaround, let me know, and I'll make sure we get it all figured out.

Mert A.

National Instruments

P.S. You can submit product suggestions like this one via our website.  Using that channel ensures that your suggestion is not forgotten or missed. 🙂

[andytheape]

Thanks for the prompt reply, Mert.

I should have mentioned that I'm actually running 7.1.1... would that still make sense from what you discovered about 8.0.1 and 8.1? I'll have a crack at hacking the build.exe project a bit more.

Curiously, I have another project that don't seem to have the problem, but the DLLs in that project are linked in via function panels. With the problem project, it's just a lone .lib and a bunch of headers. Or maybe that's just coincidence.

I'll definitely submit a product suggestion though. Thanks for the pointer.

Cheers,


Andy

[Mert_A.]

Andy,

Well, this is a remarkable coincidence.  It looks like two separate bugs with nearly identical symptoms were introduced at different times completely independently.  I have yet to diagnose the 7.1.1 bug, but I have reproduced it, just as you describe.  It seems to only happen when the .lib file is directly included in the project.  One thing I can suggest is opening your project in CVI and manually creating a distribution kit.  I noticed that if I created a distribution manually, the default settings did include the DLL in question.  If you then save the project file, the distribution settings are stored in the .prj.  Subsequent automated distribution builds should use these stored settings, and your DLL should be included.

Please let me know if the workaround I proposed fixes the problem on your end.  I'll look into this further to see if there is a better workaround I can suggest.

Mert A.

National Instruments

[andytheape]

Sorry for the delay in getting back to you, Mert. As is usual, I got pulled away from the project just as I was starting to get to the bottom of the issue!

Thanks for your suggestions. Actually, I don't think I ever had a problem getting the DLL to be included when manually building the project so I guess I escaped the bugs you describe.

However, I did some more detailed testing & experiments to try and narrow this one down. This is what I've learnt:

- Manually building the distribution kit (I mean clicking Build->Create distribution kit...) always works (the DLL is correctly included)
- Manually starting the autobuild process always works (issuing the NAnt build commands at a cmd prompt)
- But, when the autobuild process is triggered automatically (i.e. by the version control monitor [Draco.NET] calling the NAnt script) the DLL in this case is not included

Now, one thought I had here is that in the first two cases (which work correctly) the NAnt script/LabWindows build process runs as me (i.e. I'm logged into the system).

In the third case (which fails) the process must be running as a system process (it's triggered by a service running as a LocalSystem user)... could this have something to do with it? Could LabWindows not have the right permissions to grab the DLL? How does it know which DLL to grab anyway?

It's still curious to me that I have another project which includes various DLLs and that project has no problem. However, like I mentioned before, in that project the DLLs are associated with instrument drivers linked in via function panels. In the problem case, it's just a solitary .lib and it's associated headers.

Investigations continue... comments and thoughts welcome!

Cheers,


Andy