Hi all,
We are currently upgrading to 9.21.1 from 9.18.5. In the 9.19 release, there is a new feature which is " Fall back to matching name rather than declared type when deserializing resources #795". This broke when we try to load our old test plans which were compatible with 9.18.5. We are not able to load the test plan in 9.21.1 but in able to in 9.18.5 without any code changes.
The error we see is this:
And some of the errors are pointing to such excerpts in the test plan:
Any ideas on this?
I dont think the issue is #795. That is only used when there is ambiguity of type and for MultimterComponent that is not the case.
Are your sure that your test step has properties called MultimeterComponent and MultimeterComponentTwo?
Hi @rolf_madsen ,
Thanks for the prompt response. I didnt mean it to be the same issue, but rather the fix might have broken the previous behaviour.
Yes, our test function/step has this property as seen below. And it works with 9.18.5.
Ok, so I don’t know how that worked before, but by setting XmlIgnore and making the setter internal, it is probably not being seen as writable. Are you sure it actually worked in 9.18 and its not that it just silently ignored the problem?
Hi @rolf_madsen,
We are sure it worked in 9.18, but and it seems like these errors can be seen in 9.18 but the test plan loading will not fail. It seems like previously, it would silently ignore, and allow the test plan to be loaded as compared to 9.21 which fails. I would hope that any changes made in reading the xml should be backward compatible from test plans saved using old versions of Keysight Editor, as these would have already been shipped to production.
Assuming we cannot re-release our test plans, what would you suggest that can be done in this case?
What happens if you try loading it with Editor v 9.21?
if everything else does not work you can always patch the plan with an ITapSerializerPlugin implementation. That is how we went from 8 to 9.
Hi @rolf_madsen,
I am able to load it with Editor v 9.21, and run the testplan. However, loading the test plan in our application seems to throw error. Doesnt the Editor Serializer use the same as what we use below? Also, could you share more about the ITapSerializerPlugin?
Editor loads the test plan as such:
// openDlg is a win32 OpenFile dialog.
var plan = TestPlan.Load(openDlg.FileName);
Anyway, I dont think that is likely to make a difference.
It is more likely that the issue is related to plugin discovery.
Just wanted understand your thought process as to why do you think its related to plugin discovery?
I checked the overloads of TestPlan.Load and it does more or less what you already showed in your code.
When you say that it fails to load is it because it throws an exception? Or will it return a broken test plan object?
When I try to load it, it throws an exception right away. See below:
When you load it with the Editor, is there a popup appearing when you try to load the test plan?
Yes correct, there is a popup if we want ignore the errors and continue. Afterwards, it will be able to load and run.
Ah ok. That makes sense. You can implement it as the Editor does it , but then you need to implement a IUserInputInterface. That class is invoked whenever something from decision from the user is needed.
When your application starts you can call UserInput.SetInterface with an instance to configure it.
Then you will be able to get a callback with the error object you then need to handle to get it to ignore the error. There is an example of it in the TUI: https://github.com/StefanHolst/opentap-tui/blob/main/OpenTAP.TUI/TuiUserInput.cs
