Hello.
My project is in the attachment.

Best regards

Hello.
I attempted to reproduce the issue, but have not succeeded. This was done with Release x64 build, outside of Visual Studio, with no OPC connection interruptions.

Here is the result of my test run, over the course of 3 hours. It shows no signs of memory leak.



For record, there were following differences (known to me) from your test:

1. I updated the referenced version of QuickOPC package to the recent one (2022.2) available as of today. In the process, I changed the format of references from "packages.config" to the new "Package Reference".
2. Switched the project to target .NET Framework 4.7.2, as it is the new minimum required by the current version.
3. Replaced the initialization of ServerDescriptor by a single call to "new ServerDescriptor("...")", because the particular overload of ServerElement you wer eusing is no longer present in the current version, and it was unnecessary to use ServerElement there.
4. Added some diagnostics output (Console.WriteLine) to better indicate operation failures, and count the number of EasyDAClient objects in use at any particular moment.

I do not think that differences #2, 3, or 4 have any significance. Difference #1 may be the cause; we have not specifically fixed any memory leak between your version and ours, but there were lots of changes everywhere, so it is always a possibility that it is gone now. Another explanation is that there is some other difference that I do not know about.

Either way, until I have a reproducible scenario, there is nothing else I can do.

Best regards

There are multiple reasons for EasyDAClient existing as an IDisposable object and not a set of static methods (leaving aside that we are doing OOP and static methods are not "nice"). Not everybody is affected by these reasons, but they are all very important, and some of them are:

1. There is no direct way to expose static classes/methods to COM, and our product can be used from COM tools and languages as well.

2. Although the EasyDAClient, by default, manages connections, in what appears a "shared" mode, it also has some per-instance settings (see the Reference doc). So some users may want separate instances because of the need to have different some of these per-instance settings. And you may set it to "Isolated" mode, in which the connections created by that instance will not be shared by other instances. So you have a complete flexibility, in case you need it. But normally you don't.

3. For developers using VS designer, such as in WinForms, you need to have a way to drag the EasyDAClient to the designer surface from the toolbox. For it, it has to be a true object (not a static class). And it has to derive from Component, which means it must be IDisposable.

4. The SharedInstance is for ease of use. It is fine to use it in non-library projects, because you know you are the only one using it. But if you are writing a library, you would be risking that the per-instance settings will conflict with somebody else's. This is all explained in the doc.

Regards

Thank you.

I want to note that what you are doing with the pool is not needed either. One EasyDAClient can connect to multiple servers. You are writing code for what is already in the product.

Regards

Hello.

Regarding "...so we need to be able to Open, Close, Read, Write and somehow recreate the connection if errors are being thrown" : Still, this is misunderstanding of how EasyDAClient works. You do not achieve "recreating the connections" by disposing of the EasyDAClient. The connections are independent of that. EasyDAClient manages the connections automatically, and recreates them as needed. But anyway, you can of course dispose of the EasyDAClient it if you like. But it is totally useless in this respect. What influences when the connections are created and removed are the operations on the EasyDAClient objects (reads, writes, subscriptions), and not the object creation and disposal.

I rebuilt your project and will be running the tests. I will let you know then.

In your report, you describe what happens running the Debug x64 configuration inside VS, and Release x64 outside VS. Have you also tried at least one of the remaining combinations (Debug x64 outside VS, or Release x64 inside VS), and if so, what were the results?

Regards

Hello.
I will have a look at it. Please allow some time. I have some comments too:

1. Not only it is not necessary to dispose of the EasyDAClient after each operation, it is also not necessary (in fact, it is highly discouraged) to dispose of it because you detected some failure. Doing so is a misunderstanding of the QuickOPC concept. The EasyDAClient does *not* represent a connection. The principles of operation are described in the User's Guide. For an application like the one in your example, you can simple create and keep using a single EasyDAClient object. But I understand this rule/recommendation does not invalidate the point about memory leak.

2. There are conflicting requirements to the object disposal:
- Users want that the disposal works synchronously; i.e. does not return after it is done, and after it returns, resources are cleaned up.
- Users want that the disposal does never "block".
Unfortunately, these two requirements are at direct conflict, when you think it through, and cannot be fulfilled together. I think our current implementation prefers the quick return from the Dispose(), which means that the actual resource disposal can lag behind.

3. I think I have seen conflicts of the Task mechanism with EasyDAClient. Is there a particular reason you are using it, or have to use it?

4. Our current version is QuickOPC 2022.2 (5.70). This is what I will test with. If this issue results in some code change, it will be done into version 2022.2. We do not update older versions.

Best regards