TestStand 2010 deployment on a new computer with TestStand 2010 SP1

[GreggRupp]

I have a custom sequence editor built in TestStand 2010. I have a user with a new install of TestStand 2010 SP1. The following issues have risen with trying to run TestStand or  the Custom Sequence Editor.

The installer  I created installs the files in TestStand Application Data Directory \TestStand 2010  (not SP1 folder) so the Station Globals, TextExec and Tools are not updated when TestStand SP1 is loaded. They are installed into a new TestStand 2010 folder

The Public Directory \Components\Step Types and Type Palettes are also in a TestStand 2010 folder  (not SP1 folder).

Is ther a way to rectify this in the deployment tool?

[AllenP]

You must build in TestStand 2010 SP1.

[Skeptical]

I was just going to post my own message when I found this one. We had TestStand 2010 installed and then just installed SP1. Any reasonable person would view a service pack as a cumulative set of patches that would overwrite the existing install of the current version. I would have expected that SP1 would have installed in the TestStand 2010 folder. But NO. It installs in it its own folder. So, if you've customized anything like the process model or the front end callbacks you have to go mess with those again.

I find no rational reason for this and it makes me really irritated with NI. My experience with NI software in general is suffering because of stupid stuff like this. And while I'm on a rant. Could NI fix the stupid Uninstaller program in the control panel. They have a tiny little list box to list all the NI software installed and you can't resize the stupid form to make it bigger so you have constantly scroll back and forth to read the full names of the software installed. That's just amateurish.

Thanks for listening to my rant.

[Kyle_M]

Skeptical,

First, Im sorry for any inconvenince it has caused, but we do not like to overwrite versions for a number of reasons. It allows users to develop without the possibility of breaking what already works, and also allows testing on multiple versions. On a production machine, it is extremely handy to be able to not change the working side of the machine while testing the new version. Im sorry if the naming convention caused confusion, but were trying to make sure our customers have the most stable experience possible.

As for the uninstaller program, you may want to make a post to the Idea Exchange. Many of our best new features come from user suggestions like this. 

Regards,

Kyle Mozdzyn

Applications Engineering

National Instruments

[Skeptical]

Thanks for your response. I understand the desire to maintain stability on customers systems. I guess in my view as service pack should never break things. It just fixes bugs. Most other applications overwrite the actual application with a service pack.

Thanks.

[GreggRupp]

Kyle,

My issue was a with a user with a new install on a new corporate machine. There was not a previous version of TestStand 2010 that was  non-SP1. 

If the installer was able to copy the files on the machine with SP1 installed into the "Public Documents\Test Stand SP1\" folder opposed to creating a new "Public Documents\TestStand 2010" folder we probably would not have seen this.

Even if we had our Custom Step Types in a folder that is not "TestStand Public Documents Directory", the "ini" files that are in the "TestStand Application Data Directory\Cfg" folder can be updated because it creates a new folder that is not SP1 and these "ini" files have to be manually copied to the SP1 folder.

[Kyle_M]

Skeptical,

While I agree no new release should ever break things, it is an unfortunate reality sometimes because no test routine could check for all possible uses. Again, I apologize for any inconvenience this has caused.

Regards,

Kyle Mozdzyn

Applications Engineering

National Instruments