Building EXE with name given by date

[innocent_oreo]

Hi,

I was wondering if someone knows how to make a VI that will change the target filename in a project build specification, and then build the target (into an exe). I want the built target to have the name "XXX%y%m%d.exe" where this is a string that will go into a Format Date/Time String node (using the current date) so will come out like XXX161220. I have the feeling I can use the App Builder VIs found in vi.lib/AppBuilder, but I don't really understand how to use these. So far I have mostly copied code from a stack overflow post showing how to read some target properties. However while NI_AB_API_Build.lvclass:Get Destination Name.vi works to do this, NI_AB_API_Build.lvclass: Set Destination.vi gives me an error (-4500, which is undefined and occurs, following the call chain, in AB_API Set Destination.vi) when I feed in the formatted string. I'm using LV2013. Attached is a PNG of the sort of current state of the test VI I have, almost identical to the SO post I got it from.

I only want to do this because I don't keep good practises, and keep accidentally overwriting old .exe's that work with new ones with new bugs... I figure if I knew how to use these VIs properly I might be able to optimise the build routine a bit better.

[Bob_Schor]

---

@innocent_oreo wrote:

I only want to do this because I don't keep good practises, and keep accidentally overwriting old .exe's that work with new ones with new bugs... I figure if I knew how to use these VIs properly I might be able to optimise the build routine a bit better.

---

Dear (not so) Innocent,

     If you are not using Version Control of some form, you definitely are not using "good practices".  Please look into getting space on a Subversion Server, on GIT, or some other VCS and start using it for your LabVIEW code.

     The Great Advantage is if you use VCS, commit your changes regularly, and document what you have done (that is, when you commit, write enough of a note to yourself, say one line, so if you have to "undo" something that doesn't work), you'll know at what version in the Repository things broke.  This will completely obviate the need to "time-stamp" your EXE.

 You can find more information on the Web, but (almost all) good LabVIEW programmers use some form of Version Control.    

Bob Schor

[perhult]

As Bob said, consider using version control!

To answer your question: Try using "Post build action" in the build specifications. It should be simple to create a vi which renames (or in worst case if the exe is still locked: copying) the exe that was created (since you know the name of it already) and adds the date to the new filename.

[billko]

I like SVN woth the Tortoise interface.  With SVN you can even create a repository on your computer.  Not ideal, but if your IT is finnicky about putting stuff on the server...

[innocent_oreo]

Hi,

Thanks for the suggestion about using source control. I have tortoise SVN installed and it works pretty well. I haven't been using it lately because of issues coordinating with other members of the repo (who are constantly busy either frantically coding or away fixing hardware), but I hope that we will get back to using it soon, I am very keen on the idea personally.

I didn't know about post build actions. I'm trying what was suggested by Per Hult now (it takes at least 10 minutes to build this thing).

I'm still curious about the App Builder VI's though. If anyone knows where a good place to find out more about them I would be interested to know about it.

[Bob_Schor]

---

@innocent_oreo wrote:

Thanks for the suggestion about using source control. I have tortoise SVN installed and it works pretty well. I haven't been using it lately because of issues coordinating with other members of the repo (who are constantly busy either frantically coding or away fixing hardware), but I hope that we will get back to using it soon, I am very keen on the idea personally.

---

Are all of the "members of the repo" working on the same Project?  If so, then coordination could be a problem.  But typically only a few (2 or 3) people are likely to be working on the same piece of code, and if you (all) make a practice of "Update at start of work, Work, Commit at End of Work" (where "Work" is at most a day, and can be as short as a few hours), you are less likely to "clash" with your co-workers.

If you have non-overlapping Projects, it make sense to have non-overlapping "Projects" (each with trunk, tags, and branches Folders) in your Repository.  This will even further reduce the risk of conflicts.

Bob Schor