Deployment w/ Custom Type (CommonResults)

[Aaron_W.]

OK, first off, I admit I'm not an expert when it comes to Types or even deploying them...hence the question. I'm looking for a recommended way to handle the situation that I have.

Situation: I have test sequences that have a modification made to CommonResults. We put a boolean variable for "IncludeInProductionLog". I expect to see this property on every step in the sequence. I have the sequence originally saved in TS 4.1 / LV 8.6 and now I'm upgrading it to TS 2013 SP1 / LV 2013 SP1. It appears that before the developers (not me) had overwritten the Type Pallets on our development machine such that this type was standard on the machine. Now, when I open it on new machine, I get a Type Conflict (no surprise here). I get the option to use the Type from the Sequence (one I want) or use the Type currently loaded in memory (default installed w/ TS).

So, I select load the Type from the Sequence File. Cool, everything looks good, but my ParallelModel.seq / NI_DatabaseTypes.ini / NI_FlowControl.ini /.../NI_Types.ini all have the (*) sign next to them as though they have been updated and need to be saved. Sure, I get that I modified the types in memory and so those Type Palettes / ProcessModel all think they have been updated. More on this later.

I'm planning on deploying (TestStand Deployment) my sequence to about 10 machines, all of them new w/ new TS installs. I don't want to have to go through and update all of the Type Palettes / type conflict dialogs that come with this. I'm looking for the way to either deploy my Type Palletes, save this CommonResults into MyTypes.ini or something such that I can just deploy the updated CommonResult Type and not have to go through all the headache of type conflicts.

Things I have tried:

I've been parsing though the documentation (I try to RTFM when I can) and it talks about versioning of the Types and having it select the latest version. Updated my sequence type to 5.2.0.0 (older version was 5.1.0.0) but I still get the same type conflict.

I know the TestStand Type Differ is out there, but again, without really understanding what I am doing and wanting to have this just "happen" with my deployment, I find myself looking for other options.

What I need:

It's pretty simple, just need to not have the Type conflicts, don't want the user to have to save any of the Types or ProcessModel and I don't even care about maintaining the original types on these systems. I'm happy to just replace them. Just wanting to make sure that I go about this with the "Best Practices" in mind.

Sorry for the long post...any recommendations would be helpful. Thanks in advance!

[dug9000 · Accepted solution]

I recommend you update all of the type palette files to have the latest version of your CommonResults type and resave them (you might need to run teststand "as admin" when doing this since the files are in the program files directory and thus are not writable by default on newer OSes). Then you need to make sure you install those into the <TestStand>\Components\TypePalettes directory on your target machines, overwriting the ones installed there by default. That will get rid of the type conflicts you are seeing.

When you open existing sequence files they will be marked as modified if they weren't already using your version of CommonResults, but you don't necessarily have to resave them all since they will get re-converted to use your CommonResults type whenever they are loaded since that type is in the type palette files, but if you want to get rid of the modification mark you will need to resave them. You can use the "Update Sequence Files..." tool in the sequence editor to resave them all at once.

In the future, you might want to consider using the newer "Additional Results" feature, or adding an Attribute to the Result object of a step instead of using CommonResults. They do not have the same issues with type conflicts and file modification because they don't involve maintaining a custom data type that is used by every step.

Hope this helps,

-Doug

[Aaron_W.]

Thanks Doug, I will do what you suggest.