Automatically Installing Custom Step Types in TestStand 4.2

[K_seeker]

We have developed Custom Step types that needs to be integrated in a deployed TestStand System (customized UI with TestStand RunTime Engine) . We can customize the palette manually and add the related INI file. We also understand that the information gets saved in Testexec.ini in Cfg folder @ C:\ProgramData\National Instruments\TestStand 4.2\Cfg. What I am curious is how this process can be automated.

Thanks

[AllenP]

In most deployment cases (where you will not be developing any further), you do not need to deploy type palette files.  All type information is stored in the sequence files that are deployed.  However, if you want the type palette on the deployed on that machine, create a type palette file with all of the types you wish to deploy, and have it copied to the <TestStandPublic>\Components\TypePalettes directory.

[K_seeker]

By simply copying the INI files (of new step types) to <TestStandPublic>\Components\TypePalettes and restarting my Custom TS UI application next time the new step type will appear in the insertion pallete for me?

[AllenP]

This is correct.

[lordsathish]

Have you renamed the MyTypes.ini in the TestStand public ? You should be able to add the MyTyped.ini in the workspace file and deploy it. Whats the exact problem you are facing ?

Thanks,

Sathish

[crelf]

I work with K_seeker: we're distributing a palette of custom goodness for a customer of ours - we created a workspace, included all the goodness (including the custom palette ini), built a deployment that installs it to the TypePalettes folder and it all works great - thanks for everyone's help.

[dug9000]

---

@AllenP wrote:

In most deployment cases (where you will not be developing any further), you do not need to deploy type palette files.  All type information is stored in the sequence files that are deployed.  However, if you want the type palette on the deployed on that machine, create a type palette file with all of the types you wish to deploy, and have it copied to the <TestStandPublic>\Components\TypePalettes directory.

---

I just want to add to the above that there are very good reasons to use type palettes even in a deployment. Using a type palette in a deployment ensures that all of the sequences on the deployed machine will use the version of the type in the type palette file and helps ensure that you won't get type conflict errors as long as the version in the type palette file is the newest version. If you instead just rely on the sequence file having the type definition you might end up with a mix of various different versions of your types in many different sequence files and depending on the order in which they are loaded you might end up using the wrong version of the type or getting type conflict errors at runtime. Using type palettes is recommended as a way to control which type versions are being used and to keep types more organized and centralized.

-Doug

[crelf]

---

dug9000 wrote:

I just want to add to the above that there are very good reasons to use type palettes even in a deployment. Using a type palette in a deployment ensures that all of the sequences on the deployed machine will use the version of the type in the type palette file... Using type palettes is recommended as a way to control which type versions are being used and to keep types more organized and centralized.

---

Absolutely - that's exactly why we're doing it this way.  Our customer is in a regulated industry, and we need to control their development environment configuration very tightly.  Speaking of which, so when will there be VIPM (TestStand Edition)? 🙂