Online Forums
Technical support is provided through Support Forums below. Anybody can view them; you need to Register/Login to our site (see links in upper right corner) in order to Post questions. You do not have to be a licensed user of our product.
Please read Rules for forum posts before reporting your issue or asking a question. OPC Labs team is actively monitoring the forums, and replies as soon as possible. Various technical information can also be found in our Knowledge Base. For your convenience, we have also assembled a Frequently Asked Questions page.
Do not use the Contact page for technical issues.
- Forum
- Discussions
- QuickOPC-Classic in .NET
- Connections, Reconnections, COM/DCOM
- Getting error: No method available to convert ProgID to CLSID
Getting error: No method available to convert ProgID to CLSID
04 Jun 2022 15:18 #10926
by support
Replied by support on topic Getting error: No method available to convert ProgID to CLSID
Hello,
there are three changes going from 5.63.194 to 5.63.221:
- fix for Live Binding users - problem when opening forms with OPC UA bindings
- OPC DA fix - you could get ArgumentException when subscribing to the same item more than once with different update rates
- OPC XML-DA reconnection fix
Best regards
there are three changes going from 5.63.194 to 5.63.221:
- fix for Live Binding users - problem when opening forms with OPC UA bindings
- OPC DA fix - you could get ArgumentException when subscribing to the same item more than once with different update rates
- OPC XML-DA reconnection fix
Best regards
The following user(s) said Thank You: tblong
Please Log in or Create an account to join the conversation.
03 Jun 2022 14:32 #10925
by tblong
Replied by tblong on topic Getting error: No method available to convert ProgID to CLSID
Follow up question regarding the difference between v5.63.194 and v5.63.221. While all our issues were fixed in this thread with v5.63.194, is there any material difference between these two versions to be concerned with? I looked on the
What's new in QuickOPC 2022.1
and do not notice any updates that would impact us here.
Please Log in or Create an account to join the conversation.
14 May 2022 06:51 #10867
by support
Replied by support on topic Getting error: No method available to convert ProgID to CLSID
Thank you for update, and I am glad that it works now!
There was one more suspicious place that we fixed together with the CLSID parsing in 5.63.194.1, and I think that it probably was what has lead to resolution.
Thanks for your cooperation, it has helped us to improve the product.
Best regards
There was one more suspicious place that we fixed together with the CLSID parsing in 5.63.194.1, and I think that it probably was what has lead to resolution.
Thanks for your cooperation, it has helped us to improve the product.
Best regards
The following user(s) said Thank You: tblong
Please Log in or Create an account to join the conversation.
13 May 2022 20:57 #10866
by tblong
Replied by tblong on topic Getting error: No method available to convert ProgID to CLSID
All is resolved now using QuickOPC v5.63.194.1. Once again, amazing support though this so thank you very much. Adding a summary below of the progression to success.
Using QuickOPC v5.63.162
This is the version that began this thread and the one we were consistently getting the error "No method available to convert ProgID to CLSID." This was the case through many permutations of our Intrinsic Component config settings that can be seen in the first post of this thread. We also went though using the ProgID only, the CLSID only, and both the ProgID + CLSID in the ServerDescriptor class using the URL syntax. We also tried disabling the Windows firewall entirely on the same machine as our Windows service using QuickOPC. Same error result throughout.
Using QuickOPC v5.63.194.1
This version fixed all issues including parsing the URL syntax correctly in the ServerDescriptor class when just the CLSID was included like this "opcda://MachineName/{19d98a61-b3ca-4143-0088-35464d714ea0}." When we first started up our Windows service with this QuickOPC version, we got the error "The RPC server is unavailable" which is indicative of firewall configuration issues however at this point we had not tried disabling the firewall yet as we had with the prior version. We added a firewall rule allowing our program inbound access from all TCP ports. From here we began getting "Access is denied" errors. A step in the right direction. At this point, we recalled having an RDP session on the remote machine seeing that the ArchestrA FSGateway DCOM Authentication Level was set to a value of None. The configuration change was made to our Intrinsic Component config file below to match how the remote OPC server was setup:
That did the trick. Got all all relevant OPC items subscribed and began receiving ItemChanged events successfully and without errors. We ended up using just the ProgID in the URL syntax like "opcda://MachineName/ArchestrA.FSGateway.2" however using just the CLSID worked as well.
Using QuickOPC v5.63.162
This is the version that began this thread and the one we were consistently getting the error "No method available to convert ProgID to CLSID." This was the case through many permutations of our Intrinsic Component config settings that can be seen in the first post of this thread. We also went though using the ProgID only, the CLSID only, and both the ProgID + CLSID in the ServerDescriptor class using the URL syntax. We also tried disabling the Windows firewall entirely on the same machine as our Windows service using QuickOPC. Same error result throughout.
Using QuickOPC v5.63.194.1
This version fixed all issues including parsing the URL syntax correctly in the ServerDescriptor class when just the CLSID was included like this "opcda://MachineName/{19d98a61-b3ca-4143-0088-35464d714ea0}." When we first started up our Windows service with this QuickOPC version, we got the error "The RPC server is unavailable" which is indicative of firewall configuration issues however at this point we had not tried disabling the firewall yet as we had with the prior version. We added a firewall rule allowing our program inbound access from all TCP ports. From here we began getting "Access is denied" errors. A step in the right direction. At this point, we recalled having an RDP session on the remote machine seeing that the ArchestrA FSGateway DCOM Authentication Level was set to a value of None. The configuration change was made to our Intrinsic Component config file below to match how the remote OPC server was setup:
[OpcLabs.BaseLib.Runtime.InteropServices.ComManagement:Configuration:SecurityParameters]
TurnOffCallSecurity=truePlease Log in or Create an account to join the conversation.
12 May 2022 18:22 #10865
by support
Replied by support on topic Getting error: No method available to convert ProgID to CLSID
Hello,
thank you for the additional information. The full ErrorMessage from the test with EnableNativeClient = false would be useful.
Yes, so far your tests were never actually using the CLSID (due to bug on our side).
There is a new build with this bug fixed. Please download QuickOPC 5.63.194.1 (or later) - the installer is on our Web site, and the packages are on nuget.org - rebuild, and retest.
Best regards
thank you for the additional information. The full ErrorMessage from the test with EnableNativeClient = false would be useful.
Yes, so far your tests were never actually using the CLSID (due to bug on our side).
There is a new build with this bug fixed. Please download QuickOPC 5.63.194.1 (or later) - the installer is on our Web site, and the packages are on nuget.org - rebuild, and retest.
Best regards
The following user(s) said Thank You: tblong
Please Log in or Create an account to join the conversation.
12 May 2022 13:01 #10864
by tblong
Thank you much again for this. I notice now also that the ServerDescriptor.ServerClass property gets filled in with the ProgID if we supply it with a URL string containing both the ProgID + CLSID. Didn't notice this before since the ServerDescriptor.Clsid and ServerDescriptor.ProgId seemed to be set correctly. This bug tells me that QuickOPC in our service has never tried to use the CLSID directly when connecting and thus is always trying to use OPCEnum. Is this assumption correct? Even with this bug, still doesn't explain how the other two clients are working since all we've supplied them with is the ProgID as well. We are doing some additional investigation later this afternoon with all the tools provided within the full QuickOPC installer.
If we uncover any additional details with the QuickOPC tools I'll be sure to post them here as well. I'll await your patch update and include any additional error logging you suggest in our next update.
Replied by tblong on topic Getting error: No method available to convert ProgID to CLSID
Yes, this is indeed the OperationEventArgs.ErrorMessageBrief property in the logs. What would you ideally like to see here, the OperationEventArgs.ErrorMessage property? It can get quite excessive in the logs when all items have the same issue, which is why the brief was chosen. Happy to add anything else you would like to see once we have the updated build in place fixing the ServerDescriptor URL string parsing issue mentioned.It would be interesting to know the full message text too (the "[...]" in the string indicates that there are extra lines; what you have displayed is probably the "MessageBrief").
Its Windows 10 Enterprise 64-bit (version 10.0.17763 build 17763) on the client side where our service and the two other OPC clients are running. Our Windows service most definitely runs as a 32-bit process as do the two other OPC clients on the same machine. The remote ArchestrA OPC server is running on Windows Server 2008 R2 and we have been told (but not been able to verify ourselves though) that the OPC server runs as a 64-bit process.Question: Is your client system 64-bit? Does your application run in 64-bit process? (use Task Manager) Do other OPC clients run in 32-bit or 64-bit process?
I will , however, prepare a new build of 2022.1 which will fix this.If we uncover any additional details with the QuickOPC tools I'll be sure to post them here as well. I'll await your patch update and include any additional error logging you suggest in our next update.
Please Log in or Create an account to join the conversation.
12 May 2022 08:20 #10863
by support
Replied by support on topic Getting error: No method available to convert ProgID to CLSID
Hello,
thanks for update. It would be interesting to know the full message text too (the "[...]" in the string indicates that there are extra lines; what you have displayed is probably the "MessageBrief").
The fact the the other implementation also cannot connect reinforces me in thinking that there might something wrong on your system (but it is not clear why other OPC client would work). Question: Is your client system 64-bit? Does your application run in 64-bit process? (use Task Manager) Do other OPC clients run in 32-bit or 64-bit process?
BUT, based on your input, I have also found a problem on our side: When you construct the ServerDescriptor using the URL string (as you do), and you only specify the scheme/machinename and CLSID (as you did in some of your tests - and it is correct to do so), we have a bug in the parsing and it does not do what intended in this case. A workaround would be to construct an empty ServerDecriptor object, and assign to its MachineName and ServerClass properties. I will , however, prepare a new build of 2022.1 which will fix this.
Best regards
thanks for update. It would be interesting to know the full message text too (the "[...]" in the string indicates that there are extra lines; what you have displayed is probably the "MessageBrief").
The fact the the other implementation also cannot connect reinforces me in thinking that there might something wrong on your system (but it is not clear why other OPC client would work). Question: Is your client system 64-bit? Does your application run in 64-bit process? (use Task Manager) Do other OPC clients run in 32-bit or 64-bit process?
BUT, based on your input, I have also found a problem on our side: When you construct the ServerDescriptor using the URL string (as you do), and you only specify the scheme/machinename and CLSID (as you did in some of your tests - and it is correct to do so), we have a bug in the parsing and it does not do what intended in this case. A workaround would be to construct an empty ServerDecriptor object, and assign to its MachineName and ServerClass properties. I will , however, prepare a new build of 2022.1 which will fix this.
Best regards
Please Log in or Create an account to join the conversation.
11 May 2022 19:26 #10862
by tblong
Replied by tblong on topic Getting error: No method available to convert ProgID to CLSID
Here is the result of setting EasyDAClient.InstanceParameters.EnableNativeClient=false below with our service using QuickOPC v5.63.183.1:
Screenshot attached also from our application's log files. On another note, we are going to install QuickOPC 2022.1 using the full installer on the same host machine as our application. This way we'll have direct access to command line (e.g. OpcCmd.exe) and UI tools using the same library version to hopefully get at the root cause here a bit faster.
OPC NET API error - result ID: E_NETWORK_ERROR; Could not connect to server.Screenshot attached also from our application's log files. On another note, we are going to install QuickOPC 2022.1 using the full installer on the same host machine as our application. This way we'll have direct access to command line (e.g. OpcCmd.exe) and UI tools using the same library version to hopefully get at the root cause here a bit faster.
Please Log in or Create an account to join the conversation.
11 May 2022 14:18 #10860
by tblong
Replied by tblong on topic Getting error: No method available to convert ProgID to CLSID
Yes, but only because the other two OPC clients which are working are being provided the same remote computer name and ProgID when connecting. The other two OPC clients are also being run-as the same user as our Windows service's log-on account.Are you absolutely sure that the remote computer name you are using, and the way you construct the ServerDescriptor for that, is correct?
Yes, we are creating the ServerDescriptor using the URL string form and a code sample is provided below with a fake remote computer name of "RemoteOPCServerName". From below when the url "urlCLSIDOnly " is used, this implies to me that OPCEnum is still trying to be used by QuickOPC when it should not be correct?Are you specifying the server using the URL string form, or setting properties in ServerDescriptor (such as MachineName) individually? I would be grateful if you can post here the piece of code (plus the relevant values, if they are not constants) you are using. You can replace the actual names by something else if they are confidential; I am looking for other omissions than just simple typos.
// Getting Error -> The RPC server is unavailable
string urlProgIDOnly = "opcda://RemoteOPCServerName/ArchestrA.FSGateway.2";
// Getting Error -> The RPC server is unavailable
string urlProgIDAndCLSID = "opcda://RemoteOPCServerName/ArchestrA.FSGateway.2/{19d98a61-b3ca-4143-0088-35464d714ea0}";
// Getting Error -> No method available to convert ProgID to CLSID
string urlCLSIDOnly = "opcda://RemoteOPCServerName/{19d98a61-b3ca-4143-0088-35464d714ea0}";
var networkSecurity = new NetworkSecurity(customNetworkCredential: false);
var serverDescriptor = new ServerDescriptor(urlProgIDOnly, networkSecurity);Noted and will do. We tried this with the original QuickOPC version in the post but not with the latest v5.63.183.1. We will give this a try and report back.And, can you please try setting EasyDAClient.InstanceParameters.EnableNativeClient to false?
Please Log in or Create an account to join the conversation.
11 May 2022 13:00 #10857
by support
Replied by support on topic Getting error: No method available to convert ProgID to CLSID
Hello.
Thank you for your investigation. I have hoped for better outcome. The changes supplied were meant to a) provide more "to the point" error message instead of "No method available...", and b) actually resolve the problem in some cases. In this sense, the first goal has been achieved, because the "The RPC server is unavailable." is now telling us better what the problem is; but it has not been resolved.
Are you absolutely sure that the remote computer name you are using, and the way you construct the ServerDescriptor for that, is correct? I am asking because "The RPC server is unavailable." is often associated with computers that cannot be accessed on the network. Are you specifying the server using the URL string form, or setting properties in ServerDescriptor (such as MachineName) individually? I would be grateful if you can post here the piece of code (plus the relevant values, if they are not constants) you are using. You can replace the actual names by something else if they are confidential; I am looking for other omissions than just simple typos.
The error in Windows event log is weird. 2147746131 (0x80040153) stands for REGDB_E_INVALIDVALUE, "Invalid value for registry". See e.g.
- www.opcti.com/Dictionary.aspx?type=2&term=206 ,
- opcexpert.com/support/0x80040153-invalid-value-for-registry/ ,
- support.exele.com/portal/en/kb/articles/wonderware-opcenum-error-0x80040153 .
I do not have more knowledge on this, but I suggest that you investigate it on your side, because it is not normal. The {13486D51-4821-11D2-A494-3CB306C10000} in the error mesage is for an object inside OPCEnum (OpcServerList).
Supplying just CLSID should work, I will investigate whether that is not a problem on our side, but can you also supply the code showing how you do it? Because, when done right, it should work.
And, can you please try setting EasyDAClient.InstanceParameters.EnableNativeClient to false? Doing so will cause QuickOPC to use a completely different low-level OPC Classic code, so there is a risk of small differences in other aspects of the component behavior - but there is also a "wild" chance that it would resolve your problem, or at least tell us a bit more. When you do that, the settings BrowseViaCategories and BrowseFromRegistry will be ignored, so you do not have to test them out.
Best regards
Thank you for your investigation. I have hoped for better outcome. The changes supplied were meant to a) provide more "to the point" error message instead of "No method available...", and b) actually resolve the problem in some cases. In this sense, the first goal has been achieved, because the "The RPC server is unavailable." is now telling us better what the problem is; but it has not been resolved.
Are you absolutely sure that the remote computer name you are using, and the way you construct the ServerDescriptor for that, is correct? I am asking because "The RPC server is unavailable." is often associated with computers that cannot be accessed on the network. Are you specifying the server using the URL string form, or setting properties in ServerDescriptor (such as MachineName) individually? I would be grateful if you can post here the piece of code (plus the relevant values, if they are not constants) you are using. You can replace the actual names by something else if they are confidential; I am looking for other omissions than just simple typos.
The error in Windows event log is weird. 2147746131 (0x80040153) stands for REGDB_E_INVALIDVALUE, "Invalid value for registry". See e.g.
- www.opcti.com/Dictionary.aspx?type=2&term=206 ,
- opcexpert.com/support/0x80040153-invalid-value-for-registry/ ,
- support.exele.com/portal/en/kb/articles/wonderware-opcenum-error-0x80040153 .
I do not have more knowledge on this, but I suggest that you investigate it on your side, because it is not normal. The {13486D51-4821-11D2-A494-3CB306C10000} in the error mesage is for an object inside OPCEnum (OpcServerList).
Supplying just CLSID should work, I will investigate whether that is not a problem on our side, but can you also supply the code showing how you do it? Because, when done right, it should work.
And, can you please try setting EasyDAClient.InstanceParameters.EnableNativeClient to false? Doing so will cause QuickOPC to use a completely different low-level OPC Classic code, so there is a risk of small differences in other aspects of the component behavior - but there is also a "wild" chance that it would resolve your problem, or at least tell us a bit more. When you do that, the settings BrowseViaCategories and BrowseFromRegistry will be ignored, so you do not have to test them out.
Best regards
Please Log in or Create an account to join the conversation.
Moderators: support
- Forum
- Discussions
- QuickOPC-Classic in .NET
- Connections, Reconnections, COM/DCOM
- Getting error: No method available to convert ProgID to CLSID
Time to create page: 0.069 seconds