Hello,

is this error just in the "help" window of Visual Studio (i.e. just a documentation/help issue), or does cause more serious consequences as well?

This looks like some kind of version mismatch. Have you been using other build of Version 5.23 before, or an earlier version (e.g. number 5.22, or less?)

Can you please check your Global Assembly Cache, to see if multiple versions of the same assembly aren't present? (and if so, delete the incorrect ones; or delete them all, and reinstall the product).

Also, please check you solution/project directory (and, in general, the whole computer..._ - if there are copies of the (old) assemblies, clean them all, and rebuild.

I hope this helps.

I have analyzed the problem. It is a bit of a mystery. What happens is that (unlike the ICONICS Data Spy), we are in a .NET world, and thus at some point we need to convert the incoming VARIANT into a .NET object.
The underlying method used to do this is Microsoft's Marshal.GetObjectForNativeVariant. And in this method, it throws the SafeArrayTypeMismatchException for the VT_ARRAY | VT_R4 that comes from your server.

Further inspection of the VARIANT shows that it is, in a way, truly invalid: in its parray->fFeatures, it has the FADF_HAVEVARTYPE flag (0x80) set, which indicates that the high word of the parray->cLocks field should contain the VARTYPE - but it contains zero instead. Re-setting the FADF_HAVEVARTYPE resolves the problem, and the value then converts in Marshal.GetObjectForNativeVariant successfully. I have modified our code so that it sanitizes the incoming variants in this way.

So far so good - but the mysterious part is that similarly "broken" variants appear to be very common, AND in most cases, the Marshal.GetObjectForNativeVariant converts them just fine (including your VT_ARRAY | VT_I4). I do not know why it has decided to refuse just certain VARIANTs that come just from your server. Also note that there are parts in between the server and the client, such as the OPC Proxy, that may change the VARIANT - so it may even be OK on your side too.

Anyway, a new, more forgiving build of QuickOPC 5.23 (494.1) is now on the Web site for download.

Best regards

I can confirm that I was able to run your server and connect to it.
I will try to reproduce and troubleshoot the problem later - hopefully by tomorrow.

Yes, this is possible too. Let me know how I can get hold of the server. I can also give you a FTP location to upload to, if you like (attaching to the forum topic is probably not the right way to go).

I understand now. Thanks for explanation. I do not see anything wrong with your code, either.
Can you please post the as much as possible about the exception, then? The call stack, the Source property, etc.

The trace file you have sent me cannot be from this code.

It does not contain the first read, for "InjectPC.IdraSystem.Data.ExtraParameters1". It only shows the second read, for "InjectPC.IdraSystem.Data.ExtraParameters".