Hello.

Sorry, I should have made my formulation more precise: Instead of

is built inside the same VS solution (statically) as everything else and the top project.

it should have been:

is built inside the same VS solution (statically) as everything else and the top project, AND is referenced (directly or indirectly) from the top project.

I suppose you are not referencing the project that further references QuickOPC , because you want to load it dynamically. And *that* is the problem. When the build system (for the top-level project) does not know that some NuGet package is referenced, it cannot properly determine the necessary assembly redirections at the top level.


Regarding the package downgrade when dragging from Toolbox: Remove the QuickOPC VS extension, and then reinstall the QuickOPC version you want (5.80.347 maybe).

Regards

Hello.
You should have described this at the very beginning.

What you are trying to do is very difficult to do, frankly almost impossible if it is meant to withstand any changes to the project and its other parts in the future. We are talking about combining libraries built with NuGet packages dynamically in runtime.

You would need a deep understanding about how these things work. I will now just explain why it won't work the way you are doing it. Whenever you have a library that depends on some NuGet packages, and these NuGet packages allow for *range* of versions in their dependent packages (which is practically always the case), your library can only be "hooked" together with the rest of the project if is either
- built into yet another NuGet package
- is built inside the same VS solution (statically) as everything else and the top project.

The output of the normal library build does *not* contain enough metadata about which assemblies it depends on. And the assemblies you end up with in the output folder may *not* be the final assemblies the top project will need to use. This is because the version ranges of the packages/assemblies need to be consolidated from *everything* that makes up your application (the library build itself cannot know what will be used together with it). If there is a dynamically loaded part, a problem occurs that it is not possible to determine the proper assemblies at the build time.

This is not specific to QuickOPC, this is the general nature of how NuGet packages work.

The bottom line is: I do not think this is the way to go, but if you want to pursue this way, we are not going to do it for you. Good luck.

Best regards

Hello.
What you wrote makes no sense to me.

You have an error in the runtime. That means you are running an application. You cannot run a library by itself, and you cannot "fix" the versions for the library.
In addition, the assembly binding redirections only make sense at the application level as well.

You need to be concerned with the <runtime> section of your application, and not with the library,

Also, given this kind of misunderstanding, please confirm that you are building the library and the application as part of single solution, and that the application has a project reference to the library (and not an assembly file reference).

Regards

Hello.

Thank you for this additional information. I will reply later when I evaluate what is happening.
In the meantime, can you please answer:

1. This is still the Windows Forms project targeting .NET Framework (4.7.2), right?
2. In the output directory of your project, there should be <appname>.exe.config file. In its <runtime> element, it contains assembly redirections, which influence the versions. Please post here the file, or its <runtime> part.

Thank you

Hello.

I am quite sure the errors you are getting have nothing to do specifically with QuickOPC. When making projects that use a range of NuGet packages and other assemblies, such conflicts are common, and yes, they are tedious to resolve, and you need to understand what you are doing. There is plenty of information on the Internet, and some tools available, to sort it out. Basically, if you take a project which works, you will see that the right assemblies are there. And, in the project that does not work, there is *something* that caused a different assembly be used in the output. You need to find that "something" and fix it, In some cases, if library A requires dependent assembly versions that do not overlap with dependent assembly version of library B, there may be no solution without changing library A or B.

If you wanted, I could give some help, but it looks like that you are heading elsewhere.

As to the PicoOPC, I have not provded the answer originally, because I think you should be aware that we are somewhat unsure about the future of the product, But if it works for you, you can purchase as anything else: Visit www.opclabs.com/purchase/full-price-list and go from there. But they are separate products and there is no price "swapping" between them.

Best regards