Professional OPC
Development Tools

logos

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.

Impossible to install/use QuickOpc (EasyUACLient) in Visual Studio

More
09 Oct 2024 06:42 #13214 by support
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

Please Log in or Create an account to join the conversation.

More
08 Oct 2024 13:03 #13212 by _laurent1988_
Hello,

We are talking about combining libraries built with NuGet packages dynamically in runtime.

Actually, there's only one library built with nuget packages : the one that manages my OPC dialog and that uses QuickOPC parts. None other projects reference a single nuget package.
And the issue seems to appear between QuickOPC elements (according to ILSpy) : OpcLabs.BaseLibs, that needs System.Diagnostics.DiagnosticSource, Version=6.0.0.0, and other QuickOPC assemblies, that need System.Diagnostics.DiagnosticSource, Version=6.0.0.1.

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.

But that's the case of my solution : everything is (and will always be) embeded in the same solution, and even built in the same folder.

Well, nevermind, I tried giving up my modular architecture and using the QuickOPC components directly in my main application, without any kind of at-runtime dynamic binding with outside libraries nor references to outside solution libraries (EasyUAClient created only in the main Winform application which is the startup proj of my solution).
But still the System.Diagnostics.DiagnosticSource, Version=6.0.0.0 missing assembly exception is thrown :(

By the way, something weird (?) happens when drag and dropping an EasyUAClient component directly on a form : the nuget packages downgrade their version by themselves to the previous one (5.80.347 to 5.80.324). Is it a clue to a possible fix ?

I understand and respect your last point. If anybody else (clients) in the forums have encountered similar issues when using modularity/plugin architecture in their projects that use QuickOPC/nuget packages, I'm interested in some feedback.

Regards,
Laurent

Please Log in or Create an account to join the conversation.

More
30 Sep 2024 13:50 #13193 by support
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

Please Log in or Create an account to join the conversation.

More
30 Sep 2024 12:09 #13192 by _laurent1988_
OK... I manage a solution with a startup project that is a Windows form project ("STAN", in the picture enclosed).
A couple of other projects are libraries that is used by the main program to dial with remote devices. All projects target the 4.7.2 framework.

Among those projects is a library that dial through OPC-UA protocol.This library (OPC_UA.dll, compiled and generated with no error by the project highlighted in the picture encloded) contains the implementation of interfaces that declare members that I need to dial with OPC devices, and, of course, references the QuickOPC UA components.

This structure works fine with another dll project used with the NI-VISA protocol.At runtime, in my main application, when I want to choose the OPC protocol, I select (via an openFiledialog) my OPC_UA.dll file, that was generated by the project embedded in the same solution (*), and the first thing the code inside the library does is creating a new EasyUAClient. This creation fails and throws the System.Diagnostics.DiagnosticSources 6.0.0.0 missing library that is raised through the Visual Studio debogger and through my application exception management as well.
The exact same code but replacing the QuickOPC EasyUAClient by a PicoOPC Client works fine, with no exception raised when creating at runtime the PicoOPC Client.

Binding redirection, as mentionned in a previous message, added in my main application STAN app.config file, isn't working and do not prevent the exception.

(*) same exception appears if I split and generate the projects on different solution/location.

English is not my native language and I probably failed in explaining what happened, but succeeded in looking like I just open Visual Studio for the first time this morning :(

Regards,Laurent
Attachments:

Please Log in or Create an account to join the conversation.

More
30 Sep 2024 11:07 #13191 by support
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

Please Log in or Create an account to join the conversation.

More
30 Sep 2024 10:00 #13190 by _laurent1988_
Hello, and thank you for the feedback,

1. Actually, it's a .NET framework library, which contains a Windows form though. The target framework is 4.7.2, but the issue remains the same with 4.8 (missing System.DiagnosticsDiagnosticSource 6.0.0.0 assembly).
2. The <name>.dll.config file :

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<sectionGroup name="userSettings" type="System.Configuration.UserSettingsGroup, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<section name="Remote.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false"/>
</sectionGroup>
</configSections>
<userSettings>
<Remote.Properties.Settings>
<setting name="AdresseOPC" serializeAs="String">
<value/>
</setting>
</Remote.Properties.Settings>
</userSettings>
<startup><supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7.2"/></startup>
<runtime>
<dependentAssembly>
<assemblyIdentity name="System.Diagnostics.DiagnosticSource" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-6.0.0.1" newVersion="6.0.0.1"/>
</dependentAssembly>
</runtime>
</configuration>


The <name>.dll.config didn't initially contain a <runtime> section (but I guess it's always the case?), but adding the binding direction you can see above is uneffective though (but I guess it's not meaningfull anyway, for a library?).
I've tried to add that binding direction in the main program that uses my opc dll, but the same missing DiagnosticSource 6.0.0.0 assembly exception is still thrown.
For what I've found with ILSpy, no other projects (and their dependencies) seem to use this System.Diagnostics.DiagnosticSource assembly except the QuickOPC parts.

I forgot to mention that the only System.Diagnostics.DiagnosticSource assembly generated by my solution is the 6.0.0.1 version, and a 6.0.0.0 version appears nowhere in my solution/projects output folders.

Best regards,
Laurent

Please Log in or Create an account to join the conversation.

More
27 Sep 2024 13:18 #13185 by support
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

Please Log in or Create an account to join the conversation.

More
27 Sep 2024 11:24 #13184 by _laurent1988_
Hello,
By digging in the assembly references in my OPC project with ILSpy, I have found that most of OpcLabs references are linked to :
// System.Diagnostics.DiagnosticSource, Version=6.0.0.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51 (unresolved)

except OpcLabs.BaseLibs, which is linked to :
// System.Diagnostics.DiagnosticSource, Version=6.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51 (unresolved)

Could it lead to an issue, as the exception thrown by my project is relative to a missing System.Diagnostics.DiagnosticSource, Version=6.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51 assembly ?

Best regards,
Laurent

Please Log in or Create an account to join the conversation.

More
27 Sep 2024 08:11 #13180 by support
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
The following user(s) said Thank You: _laurent1988_

Please Log in or Create an account to join the conversation.

More
26 Sep 2024 09:40 #13175 by _laurent1988_
Hello,
After modifying my app and rewriting my OPC project, I face the same issue : creating an EasyUAClient object (at runtime) leads to an exception :
"FileNotFoundException : Impossible de charger le fichier ou l'assembly 'System.Diagnostics.DiagnosticSource, Version=6.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' ou une de ses dépendances. Le fichier spécifié est introuvable."

Installing nuget System.Diagnostics.DiagnosticSource package (latest 8.0.0.0 assembly version or lower) does not solve this issue.

I followed the methods you told me through our previous messages (nuget packages management, version, etc.), and eventually tried to clean some unnecessary assemblies.
But I didn't really identify the deleted assemblies references that resolved the previous issue, last time, and it doesn't work this time :-(

As I mentionned before, PicoOPC UA seems to work for me, so I'm interested in swapping my QuickOPC licence to a PicoOPC UA licence.
Is it possible ? (I don't care about the price difference, as at that time of dev, I must have a working solution - at all costs).

Regards,
Laurent

Please Log in or Create an account to join the conversation.

Moderators: support
Time to create page: 0.073 seconds