Teststand Execution Profiler - add loaded DLL version info

[magnux]

When profiling an sequence, it's would be useful if also the version of .NET DLL that was loaded/unloaded could be displayed in the report in a new column next to Item Name. I have not found a way to do do this. I think this would be helpful to be able to compare performance of different versions of DLL:s, and also when troubleshooting sequences (e.g. when adding search directories and wrong version of a DLL is used by mistake).

Currently the only way I found to see version loaded was using tools like Visual Studio or Process Explorer, but that's run time, requiring breakpoints etc - the above approach would provide an better overview of the execution, and is more convenient.

 

[WireWeaver]

TestStand 2019 F2 added some relevant features:

https://www.ni.com/pdf/manuals/376434g.html#behavior

You can now configure "Module Paths and Environments" under the data collection menu.

Is the full path to the assembly and .NET version enough to decipher between your two assemblies?.. That should solve the "wrong search directory" issue. Is there some other reason you need the specific assembly version?

[magnux]

Thanks @WireWeaver for sharing - being able to see the path to the loaded DLL is very useful indeed!

I'll check that out!

Well, I think it's helpful to know that the correct / latest version of a DLL is used. But also for troubleshooting scenarios when   

multiple versions of the same DLL exist on the computer (that may conflict through dependecy) 

Most of the time a DLL depend on other DLL:s, that will be loaded into memory (and cached).

Let's say module A.DLL and B.DLL depend on a mathlib, but different versions of this lib. 

A.DLL => MathLib.DLL (version 1.0)

B.DLL => MathLib.DLL (version 2.0)

So if A.DLL is loaded first, then version 1.0 of the MathLib is loaded into RAM, and if then if B.DLL is loaded afterwards during the same session, it will use Mathlib 1.0, since Teststand have already loaded a DLL named Mathlib into memory (cached).

Then weird things might start to happen:

- Mathlib 2.0 might have breaking API changes to 1.0 (causing a crash / runtime error)

- Mathlib 2.0 might have a bugfixes that solves calulation errors or memory leaks, that might not be detected at first 

This kind of error might be a bit tricky to spot, but if I can get a log with all DLL versions that was actually loaded it's makes things a bit easier to sort out.

Also when benchmarking a sequence, it's interresting to compare different set of DLLs. 

BR
/Magnus