Leaderboard

It's not an upgrade code but a Product ID. Technically it is a GUID (globally unique identifier). It is virtually guaranteed to be different each time a new one is generated. This Product ID is stored inside the Build Spec for your executable. If you create a new Build Spec this product ID is each time newly generated. If you clone a Build Spec, the Product ID is cloned too. The Installer stores the Product ID in the registry and when installing a new product it will search for that Product ID and if it finds it it will consider the current install to be the same product. It then checks the version and if the new version is newer than the already installed version, it will proceed to install over the existing application. Otherwise it silently skips the installation of that product. Now, please forgive me but your approach of cloning Build Specs to make a new version is most likely useless. As you create a new version of your application you usually do that because you changed some functionality of your code. But even though your old build spec is retained, it still points to the VIs on disk as they are now, most likely having been overwritten by your last changes. So even if you go back and launch an older build spec, you most likely will build the new code (or maybe a mix of new and old code, which has even more interesting effects to debug) with the only change being that it claims to be an older version. The best way to maintain a history of older versions is to use proper source code control. That way you always use the same build spec for each version (with modifications as needed for your new version), but if you need to, you can always go back to an earlier version of your app. A poor mans solution is to copy the ENTIRE source tree including project file and what else for each new version. I did that before using proper source code control, also zipping the entire source tree up but while it is a solution, it is pretty wasteful and cumbersom. Here again, you don't create a new Build Spec for each version but rather keep the original Build Spec in your project.

Ohh another fun story time (need to write these down before I forget). So I'm on site at a place where we are deploying a tester that is designed to replace testers that were already there. They had 5 testers, and this first visit was to replace one of them with our new design which was faster better more scaleable etc. There were some things we couldn't test until we were on site and one of those things was the network authentication and logging. So we got onsite and went to replace the first system, and we asked for login credentials for their network. We were told we couldn't get any for a couple days. So I went over to one of the existing testers and looked at the credentials it was using since the source was on the old stand. It had something like User: Tester and Password:Tester1234 on all 5 testers. So I used those credentials and the new tester and 4 of the older ones were running just fine. I mentioned to the customer that this seems like a weak password and user name and that all systems were using the same credentials. At that moment out of the corner of my eye the IT guy ran off quickly. A few minutes later he came back and said he fixed it. By that he meant that the user name and password no longer worked. They didn't seem to care that the new system didn't work yet, until I went over to one of the older 4 systems that all of the sudden could no longer test parts and was holding up the line. I just thought it was comical that they fixed the loop hole which had apparently been running fine for years, without thinking that it would break everything using it.

What’s the point of anti-virus software that a virus can get around by renaming itself “labview.exe�

Here's a fun little project I had. It was to make a frequency sweep on a counter. This particular project used the BNC connector on a cDAQ-9188, and no c-series cards, just the chassis. It does this by generating the array of frequency/duty cycle pair. It will output that frequency and duty cycle for one cycle of the wave, then do the next frequency duty cycle pair. At the time I had no idea that a counter could have a buffer of finite samples. In my mind this means it has two hardware timers, one for the frequency and duty cycle, the other to handle when the next frequency duty cycle needs to be. If your counter supports this type of buffered write of N samples this shouldn't be a problem. You just need to do a decent amount of math to come up with the array of frequency and duty cycles that you want the card to play. https://decibel.ni.com/content/docs/DOC-32352 This example isn't meant to be a drop in solution, but just a way of showing that it is possible to control the time at which a new frequency and duty cycle occur.