05-09-2012 06:01 PM
In CVI2009, I'm trying to add a command to copy the DLL output of a project to a bin directory above the source folder.
I've tried the following command line in the Post-build Actions:
xcopy MyDll.dll ..\..\Bin /Y
This works fine when I execute it in a Cmd window, or as a batch file. But when I try adding it to the Post-build Action, I get a message that says "Build Failed. CVI could not execute one or more of your build steps."
I've tried calling it as a batch file using the CALL command, but no luck. I also can't see what's happening when the build is running because the Window >> Build Output option is grayed out.
I've tried this with the special variables and as hard coded text, but I saw no difference.
I've read and tried everything I can in the help and the forums. Any ideas on what I'm doing wrong here?
Solved! Go to Solution.
05-09-2012 06:41 PM - edited 05-09-2012 06:45 PM
Have you tried fully qualifying the MyDll.dll filename with its path? Could be the working directory isn't what you think it is at the time the shell gets your command from CVI.
05-09-2012 06:44 PM
And depending upon how CVI parses the string that is your command line, it might not be handling the embedded blanks in it. Have you tried enclosing the string in quotes?
05-10-2012 08:41 AM
Yes and yes. The example I provided above was the simplest version that I could get to work via the Cmd line and in a batch file, but I tried the full hard coded path to the file without any special variables. I could get that to work in both the Cmd Line and the batch file, but not in a Post-build Action. The thing that confuses me though is that the help says the following:
Actions can be any command supported by a Windows batch file. You can pass arguments, either hard-coded or special LabWindows/CVI variables, to the action. If you specify a batch file as an action, you must use the CALL command. Before any actions are executed, LabWindows/CVI sets the directory of the project as the current working directory.
LabWindows/CVI creates a batch file containing the actions for each step, and then runs the batch file. You can view the output of the build steps in the Build Output window.
The working directory should be set to where I've get my external tests to work, but I have not been able to see any evidence of a batch file being created or the ability to see the output of the build steps in the Build Output window; At best I can only see warnings in the Build Output window during the compile phase, but when the build starts, the Build Window disappears and the Window > Build Output menu option is grayed out.
If CVI is creating a batch file like it says, where would that file exist?
05-10-2012 01:58 PM
I can't explain why the post-build action isn't working for you, but I still wanted to suggest that, if your entire purpose for creating the build action is to copy the DLL built by your project, there's a specific option that you can set for CVI to do this, without the need for a custom build action:
Build>>Target Settings>>Where to copy DLL
05-10-2012 02:59 PM
Have you tried putting something in your bat file to make it pause? That way you might be able to get into the shell CVI has spawned and verify environment variable values and get some insight into what's going on. Then again, if CVI insists on wrapping your bat file in another bat file it might not work.
Don't know of anything else to try off the top of my head. I have a feeling of deja vu on this topic, I've tried to get batch files to run after a build, but I can't recall if I got it to work or if I gave up
As Luis says, the dll copy can be achieved using the linker without the post-build facility. I usually move the DLL / Libs that way, but there's a vulnerability there in that if you are moving the DLL and its associated lib into a folder in the LoadLibraryEx search path (and usually I am), it can be really annoying later on if the client executable manages to find the copy of an old version of your DLL if you don't make sure to keep copying later builds of the DLL to the same second folder.
05-14-2012 01:45 PM
I did take a look at that, but that option requires a hard coded path, and doesn't like "..\..\bin" as a path. Since we're using Source Control, the full path can change based on the view used. I appreciate the suggestion though, as it is a fallback option that could have been used.
For whatever reason that I cannot pin down, as of this morning I am now getting the Build Output window and it is telling me I have prototype problems and type definition issues. Once I cleared those up, I tried adding the command to the post-build and it worked as intended. I can only assume that something wasn't quite right with the function panel and the while it would let my DLL build, it was masking it's problems and the Build Output window. I can bring up the Build Output window from the Window menu, and it's documented the process as described in the help. I'm not sure what I did to make this start working, as I've been in and out of the header, source and .fp files before I noticed it was working.
I'm going to chalk this up as a undocumented CVI "Feature" and move on. Thanks for the help!
05-15-2012 10:58 AM
Ah, okay. Normally, all paths in the project are considered relative to the project itself (or to the CVI installation directory), as long as they're in the same logical drive as the project file. For that to happen, you don't have to enter them as relative paths (with ".."). You can enter them as absolute paths, and they'll still be saved as relative paths, so that if the project is loaded from a different location, they will be fixed up.
Unfortunately, up until CVI 2010, this loose relative path policy didn't extend to the paths in the Target Settings dialog. Those would only be considered relative to the project if they were in some sub-folder under the project, or in the same folder. This restriction has recently been removed, and the next version of CVI will allow these paths to be considered relative as long as they're in the same logical drive.
In any case, I'm glad that things are now working for you.