Understood. If QWORDs were invalid under WoW6432Node, then Windows wouldn't allow them.

I'm not sure if the issue lies with the Windows installer, or if it's the MSI file itself that is being generated by my Visual Studio Installer Project. I even tried compiling for x64, but other issues cropped up with the installer project (related to the installer class I'm using for the Windows service generating a BadImageFormatException... it was another rabbit hole).

But, without too much trouble, I was able to get a REGEDIT process fired off during installation to correctly import the registry values for the license, so I'm not going to spend any more time investigating.

Thanks again for your time!

When I mentioned that it's running as a service previously, I was talking about my (client) application.
To fix my issue, I set the OPC Server to run as a service.

I'll try calling the REGEDIT process to import .reg files during the install. I think this might mean we'll have .reg files sitting out in the installation folder, but I guess that's unavoidable.

I'm not positive, but I think there might be an issue in QuickOPC's validation of licenses when the application using QuickOPC is 32-bit. Let me try to explain:

When the (32bit application) installer runs and inserts the registry keys, it's causing the QWORD values ("NotAfter", "NotBefore", and "ReleaseDateCovered") under WoW6432Node to be added to the registry as binary values rather than QWORD. This is because QWORD is a 64bit value.

Correct me if I'm wrong, but my understanding is that the registry entry WoW6432Node is the view of the registry for a 32bit application on a 64bit system. Therefore, it doesn't make sense to require that these three registry values be QWORDs for license validation.

Of course I don't know how the license validation is occurring, but maybe the 32bit application is reading the (32bit) registry values and passing them to a 64bit license validation application?

When I load the license through the License Manager to correct the registry, it sets those three values to be QWORDs under WoW6432Node. I'm confused as to why Windows even allows 64bit values under the 32bit view of the registry.

Just wanted to update that I was able to get my connectivity issues resolved.

I don't know much about the OPC software on the server side, but I was able to find where you can have RSLinx start as a service. I changed it to start as a service, and it seems to work fine now. I don't have the desire or time to figure out which setting was tripping me up before, but it still confuses me.

Now I just have to figure out why the Microsoft Visual Studio installer project is messing up the registry.
After installing a new version of our application, we're getting the "invalid license" error after 30 minutes. I've done some comparisons, and it looks like Visual Studio is converting the QWORD values to BINARY for some reason - but only under Wow6432Node.

I configured both OpcEnum and RSLinx to run as a specific user in the DCOM Config, and now I'm getting the following error:

Exception Type: OpcLabs.EasyOpc.OperationModel.OpcException
Exception Message: An OPC operation failure with error code -2146959355 (0x80080005) occurred, originating from 'OpcLabs.EasyOpcRaw.DataAccess.RawEasyDAClient'. The inner exception contains details about the problem.
Inner Exception Type: System.Runtime.InteropServices.COMException
Inner Exception Message: Server execution failed

I tried a couple of different admin users, getting this exception each time.

Could I be missing some kind of configuration on the client side in code? I'm setting UseCustomSecurity to false, but could there be something else?

Note that I'm also setting the static property:

before creating an instance of the EasyDAClient.

Thanks for the quick response!

Identity is set to "The interactive user" (and under General, Authentication Level is "None").

One weird thing is that I'm not 100% positive of the server under DCOM Config. The customer doesn't know anything about their setup, and it'd require getting their vendor involved, which would not be easy (or cheap). I know it's Rockwell's "RSLinx Remote OPC Server", but the closest thing listed is "RSLinx", so I'm assuming that's it. I've done some searching online, and it sounds like it is.

OpcEnum is configured the same as RSLinx.