- Posts: 30
- Thank you received: 3
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
DCOM got error "2147746131" from the computer <RemoteComputerName> when attempting to activate the server: {13486D51-4821-11D2-A494-3CB306C10000}
We also performed an additional test. Since the OPC Expert client is able to connect to this remote OPC server, and OPC Expert has a "mimic" mode in which it connects to remote servers and re-exposes them as a local DA server, we configured OPC Expert as such and it runs as a local DA server on the same machine as our application using QuickOPC. Before testing this setup with our QuickOPC based client, we first confirmed that the other OPC client from Integration Objects was working. The Integration Objects OPC client was able to connect to the local OPC Expert DA server and create a group with one item ID successfully. So from this standpoint, the local OPC Expert DA server is working as a proxy to the real remote ArchestrA DA server. We then attempted to point our QuickOPC based service to this now local DA server. No luck. In this setup, QuickOPC reports the new error "Class not registered (0x80040154)".
Please Log in or Create an account to join the conversation.
Please rebuild your project with QuickOPC 5.63 build 183.1 or later (available on www.nuget.org, and as an installer on our Web page), and retest.
Best regards
Please Log in or Create an account to join the conversation.
Yes, I am using nuget to reference all the QuickOPC assemblies.
Please Log in or Create an account to join the conversation.
No, I do not think that the web proxy can be related to this.
You might be facing a bug in QuickOPC 5.63. Let me do the changes/fixes I mentioned, and make a new build. I will post here again when it is ready. Possibly tomorrow, but I cannot promise that.
Are you referencing the assemblies from the Setup installer, or via NuGet packages?
Best regards
Please Log in or Create an account to join the conversation.
We have attempted running our Windows service under the same user account used to remote into the system. This account did work with the OPC clients however not when used by the service. We did not test with this account though to the extent shown in my first post in the thread.Have you tried running your Windows service (temporarily) under some regular user account (such as your own), or running the browsing code from "normal" app (not a Windows service|)?
We ran the two OPC clients using the same account as setup in the service. These two OPC clients were able to browse and subscribe to items successfully whereas the service was not able to do so with the same account.It can still be DCOM configuration/permissions issue if your Windows service was running under account different from what the other, working OPC clients are using.
A potential important detail I left out. The machine on which our service (and the two working OPC clients) resides also has a web proxy configured for all outbound http/s traffic leaving the local network. Is there any chance that QuickOPC would pick up and use a machine wide web proxy setting?
Please Log in or Create an account to join the conversation.
thanks for the detailed problem description.
If you are connecting to a remote server, the OPCEnum on the client machine is not relevant/used. And it is also OK for it to be at Manual, because DCOM will start it when needed.
Have you tried running your Windows service (temporarily) under some regular user account (such as your own), or running the browsing code from "normal" app (not a Windows service|)? It can still be DCOM configuration/permissions issue if your Windows service was running under account different from what the other, working OPC clients are using.
Saying that, we have made recently improvement, but also bug fixes into this precise area of code in QuickOPC - but, releasing them is planned with QuickOPC 2022.2 which is not going to be soon. If the suggestions above fail to give resolution, I will look into back-porting these changes into the version your are using.
Best regards
Please Log in or Create an account to join the conversation.
[OpcLabs.BaseLib.Runtime.InteropServices.ComManagement:Configuration:SecurityParameters]
TurnOffCallSecurity=false # tried both true/false
EnsureDataIntegrity=false # tried both true/false
AllowImpersonateClient=false # tried both true/false
UseCustomSecurity=true # tried both true/false
[OpcLabs.EasyOpc.DataAccess.EasyDAClient:SharedParameters:MachineParameters]
BrowseViaCategories=true # tried both true/false
BrowseFromRegistry=true
[OpcLabs.EasyOpc.DataAccess.EasyDAClient:SharedParameters:MachineParameters:ComInstantiationParameters]
ExecutionContext=23 # tried both 23 & 21
[OpcLabs.EasyOpc.DataAccess.EasyDAClient:SharedParameters:ClientParameters:ComInstantiationParameters]
TurnOffActivationSecurity=false
Along with manipulating the settings above, we have also tried giving QuickOpc the server descriptor which includes the ProgID only, CLSID only, and both the ProgID and CLSID of the OPC server. All of these attempts have resulted in us seeing the error "No method available to convert ProgID to CLSID (E_FAIL.0xC0049039)" in the data change event handler following the initial subscription attempt. When we set BrowseViaCategories=false and used the CLSID only I would have expected a different error since OPCEnum should not be used in this scenario; instead forcing a registry search for the CLSID we provided. This was not the case, and we received the same error in the subject of this post. Another interesting thing about the host machine our application lives on, is that the OPCEnum Windows service is in Manual mode but not running. Since we are connecting to a remote OPC server here, should we care at all about the state of the OPCEnum Windows service on the local machine?
Weirdly enough, there are two OPC clients (OPC Expert and the other from Integration Objects) on the same machine as our application, both "run as" the same account as our Windows service application which are able to connect and subscribe to items on the remote OPC DA server. Not sure where to go next since two unrelated OPC clients are working leading me to believe firewall, DCOM, and associated permissions are all correct.
Please Log in or Create an account to join the conversation.
- Forum
- Discussions
- QuickOPC-Classic in .NET
- Connections, Reconnections, COM/DCOM
- Getting error: No method available to convert ProgID to CLSID