Hello,
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

Hello,

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

Hello.
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

Hello.

I think you are dealing with this: stackoverflow.com/questions/3940120/installutil-bindingredirect
- suggested solutions are there as well.

Best regards

Oh, I see. You did not. But Visual Studio did, because it is using the old "packages.config" model. That actually may work, but it is not the recommended way, plus it makes it impossible for me to reproduce the problem because now the project you sent to me references the assemblies but does not actually contain them.

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

Hello.

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