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
- Installation, Deployment
- OpcLabs.QuickOpc 5.70.1053 - .NET Framework 8 - Problem
OpcLabs.QuickOpc 5.70.1053 - .NET Framework 8 - Problem
thanks for letting me know.
Yes, if the code was effectively doing something that was not needed for service install, and it was that part that was causing the issue, then of course bypassing that code is the best way to deal with it - not only it resolves the problem, but removes unnecessary operations as well.
Best regards
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
there is one more possible workaround to try (I know I could have tested it myself but cannot do it at the moment and wanted to reply quickly): See kb.opclabs.com/Assemblies.config_files .
In your case, you can create a copy of your application EXE.config file (with the binding redirects) into Assemblies.config file - in the same directory as the EXE file. And then run InstallUtil exe and see if it helps.
Best regards
Please Log in or Create an account to join the conversation.
The StackOverflow post mentions GAC, but the issue has absolutely nothing to do with the GAC.
We have documented that the referencing model has been changed from assembly references to package references. This has many/far reaching consequences that are not specific to QuickOPC, and cannot be listed in their entirety.
In this case, this is clearly a Microsoft design problem. The binding redirects in the config file are taken into account when you run the EXE standalone. But they are not taken into account when your EXE is loaded by InstallUtil. InstallUtil uses its *own* configuration file - just as any other .NET app.Again, this behavior is unrelated to QuickOPC, it will happen with any program that specifies binding redirects in its configuration file.
Best regards
Please Log in or Create an account to join the conversation.
I can try workarounds but bear in mind this services installers used to work on the previous QuickOPC release, so the breaking changes are on your side and there is no mentioning on the 'Guidelines and Precautions for Upgrading to OPC Data Client V2022.2 (5.70)' document regarding this behavior besides mentioning something about the GAC which is probably related to how InstallUtil tries to resolve referenced assemblies.
Beast regards.
Please Log in or Create an account to join the conversation.
I think you are dealing with this: stackoverflow.com/questions/3940120/installutil-bindingredirect
- suggested solutions are there as well.
Best regards
Please Log in or Create an account to join the conversation.
Here is the same sample project, removed everything, upgraded NuGet to PackageReference mode, installed only OpcLabs.QuickOpc 5.70.1053. And the issue remains, able to run standalone debug/release .exe, service install always fails.
Please Log in or Create an account to join the conversation.
Please first migrate to PackageReference: See the bottom part of opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...es%20in%20Visual%20Studio.html .
This may not solve the problem, but would be much better starting point for further investigation.
If you keep getting problems, please post the updated project, as before.
Best regards
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
Your project references the individual assemblies taken from the packages, instead of referencing only the NuGet packages necessary. This way it is not going to work.
Best regards
Please Log in or Create an account to join the conversation.
- Forum
- Discussions
- QuickOPC-Classic in .NET
- Installation, Deployment
- OpcLabs.QuickOpc 5.70.1053 - .NET Framework 8 - Problem