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
- Feature Requests & Product Improvement Ideas
- Please support PackageReference for NuGet packages
Please support PackageReference for NuGet packages
20 Sep 2018 14:50 #6696
by support
Replied by support on topic Please support PackageReference for NuGet packages
Hello,
many thanks for the detailed report. No, you are not expected to do anything special to enable the assembly unpacking.
I will try to reproduce the problem with the project you provided on GitHub, and let you know then.
From our point of view, the problem is not in the fact that these App_Web_* assemblies are not present in the output. That should be OK by itself. We see the problem in the fact that you get an exception in that case.
Best regards
many thanks for the detailed report. No, you are not expected to do anything special to enable the assembly unpacking.
I will try to reproduce the problem with the project you provided on GitHub, and let you know then.
From our point of view, the problem is not in the fact that these App_Web_* assemblies are not present in the output. That should be OK by itself. We see the problem in the fact that you get an exception in that case.
Best regards
The following user(s) said Thank You: binki
Please Log in or Create an account to join the conversation.
20 Sep 2018 14:41 #6695
by binki
Replied by binki on topic Please support PackageReference for NuGet packages
Hi,
If I make a very simple project which calls EasyDAClient.Create() and simply add OpcLabs.QuickOpc using PackageReference, then I get a stacktrace when running. But if I use packages.config, I don’t. The only difference I can tell is that packages.config results in the App_Web_OpcLabs.EasyOpcClassicRaw.*.dll files being copied. Otherwise, it might actually be a bug in NuGet/VisualStudio. If the latter, I will try to find a workaround.
Here is a side-by-side screenshot: i.imgur.com/xKUmX4b.png . The project on the left is at github.com/binki/QuickOpcPackagesConfig . The project on the right is at github.com/binki/QuickOpcPackageReference .
Here is my stacktrace from the PackageReference project:
Here is the directory listing of the packages.config’s bin/Debug:
Here is the directory listing of the PackageReference’s bin/Debug:
I am still convinced that I get the different behavior because one directory has the App_Web_* assemblies copied to it whereas the other one doesn’t. If I compile the project, then manually copy over App_Web_OpcLabs.EasyOpcClassicRaw.*.dll before trying to run it, then I don’t get the crash.
I’m using OpcLabs.QuickOpc-5.53.315 via nuget.
I found this NuGet bug: github.com/NuGet/Home/issues/7276#issuecomment-423029619 . In this bug, it states that PackageReference *should* behave like packages.config by copying all files from the nuget’s lib/net452 folder to my project’s output directory. If the native code should automatically be unpacked and loaded, then the statement I made in that bug is incorrect. However, unless I’m mistaken, the empirical evidence is otherwise…. Since NuGet says it’s a bug, it’s possible that a future implementation of PackageReference itself will correctly copy all of the files and in the meantime I can try to write up a workaround in my .csproj file.
Am I supposed to somehow initialize the library to trigger the assembly unpacking? If so, I never realized that before. Please let me know.
Thanks for any help!
If I make a very simple project which calls EasyDAClient.Create() and simply add OpcLabs.QuickOpc using PackageReference, then I get a stacktrace when running. But if I use packages.config, I don’t. The only difference I can tell is that packages.config results in the App_Web_OpcLabs.EasyOpcClassicRaw.*.dll files being copied. Otherwise, it might actually be a bug in NuGet/VisualStudio. If the latter, I will try to find a workaround.
Here is a side-by-side screenshot: i.imgur.com/xKUmX4b.png . The project on the left is at github.com/binki/QuickOpcPackagesConfig . The project on the right is at github.com/binki/QuickOpcPackageReference .
Here is my stacktrace from the PackageReference project:
Unhandled Exception: System.TypeInitializationException: The type initializer for 'OpcLabs.EasyOpc.DataAccess.EasyDAClient' threw an exception. ---> System.IO.FileNotFoundException: Could not load file or assembly 'App_Web_OpcLabs.EasyOpcClassicRaw.x86, Version=5.53.315.1, Culture=neutral, PublicKeyToken=6faddca41dacb409' or one of its dependencies. The system cannot find the file specified.
+ It is possible that Microsoft Visual C++ Redistributable Package is not installed.
at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
at System.Reflection.RuntimeAssembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean forIntrospection)
at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
at System.Reflection.Assembly.Load(String assemblyString)
at OpcLabs.EasyOpc.Implementations.Native.Assemblies.LoadRawAssembly(String name)
at OpcLabs.EasyOpc.Implementations.Native.Assemblies.get_EasyOpcClassicRaw()
at OpcLabs.EasyOpc.Implementations.Native.Assemblies.GetRawType(String name)
at OpcLabs.EasyOpc.Implementations.Native.DataAccess.NativeEasyDAClient.get_RawType()
at OpcLabs.EasyOpc.Implementations.Native.DataAccess.NativeEasyDAClient.set_AdaptableParameters(EasyDAAdaptableParameters value)
at OpcLabs.EasyOpc.DataAccess.EasyDAClient..cctor()
--- End of inner exception stack trace ---
at OpcLabs.EasyOpc.DataAccess.EasyDAClient.Create()
at QuickOpcPackageReference.Program.Main(String[] args) in C:\Users\binki\source\repos\QuickOpcPackageReference\QuickOpcPackageReference\Program.cs:line 9Here is the directory listing of the packages.config’s bin/Debug:
C:\Users\binki\source\repos\QuickOpcPackagesConfig\QuickOpcPackagesConfig\bin\Debug>DIR
Volume in drive C has no label.
Volume Serial Number is D220-7412
Directory of C:\Users\binki\source\repos\QuickOpcPackagesConfig\QuickOpcPackagesConfig\bin\Debug
2018-09-20 09:51 <DIR> .
2018-09-20 09:51 <DIR> ..
2018-08-03 19:25 3,942,400 App_Web_OpcLabs.EasyOpcClassicRaw.amd64.dll
2018-08-03 19:25 2,809,856 App_Web_OpcLabs.EasyOpcClassicRaw.x86.dll
2018-08-03 19:25 6,181,888 OpcLabs.BaseLib.dll
2018-08-03 19:25 1,649,784 OpcLabs.BaseLib.xml
2018-08-03 19:25 6,393,856 OpcLabs.BaseLibForms.dll
2018-08-03 19:25 7,349,707 OpcLabs.BaseLibForms.xml
2018-08-03 19:25 18,677,760 OpcLabs.EasyOpcClassic.dll
2018-08-03 19:25 2,508,947 OpcLabs.EasyOpcClassic.xml
2018-08-03 19:25 8,456,704 OpcLabs.EasyOpcUA.dll
2018-08-03 19:25 4,487,926 OpcLabs.EasyOpcUA.xml
2018-09-20 09:51 5,120 QuickOpcPackagesConfig.exe
2018-09-20 09:37 189 QuickOpcPackagesConfig.exe.config
2018-09-20 09:51 15,872 QuickOpcPackagesConfig.pdb
13 File(s) 62,480,009 bytes
2 Dir(s) 29,011,046,400 bytes freeHere is the directory listing of the PackageReference’s bin/Debug:
C:\Users\binki\source\repos\QuickOpcPackageReference\QuickOpcPackageReference\bin\Debug>DIR
Volume in drive C has no label.
Volume Serial Number is D220-7412
Directory of C:\Users\binki\source\repos\QuickOpcPackageReference\QuickOpcPackageReference\bin\Debug
2018-09-20 09:51 <DIR> .
2018-09-20 09:51 <DIR> ..
2018-08-03 19:25 6,181,888 OpcLabs.BaseLib.dll
2018-08-03 19:25 6,393,856 OpcLabs.BaseLibForms.dll
2018-08-03 19:25 18,677,760 OpcLabs.EasyOpcClassic.dll
2018-08-03 19:25 8,456,704 OpcLabs.EasyOpcUA.dll
2018-09-20 09:51 5,120 QuickOpcPackageReference.exe
2018-09-20 09:41 189 QuickOpcPackageReference.exe.config
2018-09-20 09:51 15,872 QuickOpcPackageReference.pdb
7 File(s) 39,731,389 bytes
2 Dir(s) 29,011,685,376 bytes freeI am still convinced that I get the different behavior because one directory has the App_Web_* assemblies copied to it whereas the other one doesn’t. If I compile the project, then manually copy over App_Web_OpcLabs.EasyOpcClassicRaw.*.dll before trying to run it, then I don’t get the crash.
I’m using OpcLabs.QuickOpc-5.53.315 via nuget.
I found this NuGet bug: github.com/NuGet/Home/issues/7276#issuecomment-423029619 . In this bug, it states that PackageReference *should* behave like packages.config by copying all files from the nuget’s lib/net452 folder to my project’s output directory. If the native code should automatically be unpacked and loaded, then the statement I made in that bug is incorrect. However, unless I’m mistaken, the empirical evidence is otherwise…. Since NuGet says it’s a bug, it’s possible that a future implementation of PackageReference itself will correctly copy all of the files and in the meantime I can try to write up a workaround in my .csproj file.
Am I supposed to somehow initialize the library to trigger the assembly unpacking? If so, I never realized that before. Please let me know.
Thanks for any help!
Please Log in or Create an account to join the conversation.
20 Sep 2018 05:14 #6691
by support
Replied by support on topic Please support PackageReference for NuGet packages
There should be no need for the App_Web_* assemblies to be contained in the output folder, in 99% of cases. These assemblies are embedded inside the EasyOpcClassic assembly and loaded in runtime as necessary.
Do you actually have a problem in terms that something does not work as it should? If so, please describe it (guidelines: www.opclabs.com/forum/announcements12/2365-rules-for-forum-posts ). If you just think that these files should be in your output folder, but everything else works, then it is as designed, and there is no problem to speak about, as explained above.
Best regards
Do you actually have a problem in terms that something does not work as it should? If so, please describe it (guidelines: www.opclabs.com/forum/announcements12/2365-rules-for-forum-posts ). If you just think that these files should be in your output folder, but everything else works, then it is as designed, and there is no problem to speak about, as explained above.
Best regards
Please Log in or Create an account to join the conversation.
19 Sep 2018 23:41 #6690
by binki
Please support PackageReference for NuGet packages was created by binki
If I try to use PackageReference to reference packages versions 5.52.184 or 5.53.315, the nuspec only references OpcLabs.BaseLib.dll, OpcLabs.BaseLibForms.dll, OpcLabs.EasyOpcClassic.dll, and OpcLabs.EasyOpcUA.dll.
Please consider testing your packages with a VisualStudio-15.8 .csproj which references the NuGet using PackageReference instead of packages.config and verify that the bin/Debug folder contains the necesary App_Web_OpcLabs.EasyOpcClassicRaw.amd64.dll and App_Web_OpcLabs.EasyOpcClassicRaw.x86.dll files. Maybe these need to be added to as references to the .nuspec and a version bump released to get it to work?
Thanks!
Please consider testing your packages with a VisualStudio-15.8 .csproj which references the NuGet using PackageReference instead of packages.config and verify that the bin/Debug folder contains the necesary App_Web_OpcLabs.EasyOpcClassicRaw.amd64.dll and App_Web_OpcLabs.EasyOpcClassicRaw.x86.dll files. Maybe these need to be added to as references to the .nuspec and a version bump released to get it to work?
Thanks!
Please Log in or Create an account to join the conversation.
Moderators: support
- Forum
- Discussions
- Feature Requests & Product Improvement Ideas
- Please support PackageReference for NuGet packages
Time to create page: 0.069 seconds