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.

Please support PackageReference for NuGet packages

1
2

support
Offline
Moderator

More

03 Feb 2022 12:18 #10581 by support

Replied by support on topic Please support PackageReference for NuGet packages

Hello.

The situation has not changed. The App_Web_* assemblies are still needed. Information about which assemblies are needed and when it in the User's Guide (which differ with the version). opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2....html#Assemblies%20(.NET).html for the latest one.

Best regards

The following user(s) said Thank You: tblong

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

tblong
Offline
Elite Member

More

02 Feb 2022 13:14 #10580 by tblong

Replied by tblong on topic Please support PackageReference for NuGet packages

@support I am in the process of upgrading our OPC DA app, which itself targets .NET Framework v4.7.2, from QuickOpc v5.59.1055->v5.62.1032 and have just a single question for now.

Question:

Are the "App_Web_*" assemblies still required to be present in the build directory to function? I see that the "App_Web_*" assemblies are still packaged with v5.62.1032. Asking as I noticed that new assemblies like "OpcComRcw.dll" are now included in v5.62 which were not included in v5.59.

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

support
Offline
Moderator

More

13 Oct 2020 20:19 #8998 by support

Replied by support on topic Please support PackageReference for NuGet packages

This is a Microsoft bug with no known workaround, so unfortunately there is nothing we can do on our side. Microsoft needs to fix it.

The following user(s) said Thank You: tblong

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

tblong
Offline
Elite Member

More

13 Oct 2020 19:35 #8997 by tblong

Replied by tblong on topic Please support PackageReference for NuGet packages

Is there any updated guidance to the issue of "App_Web_OpcLabs.EasyOpcClassicRaw.x86" not getting placed in the output directory at build time?

This is still an issue for me spinning up a brand new .NET v4.7.2 project using the PackageReference format targeting OpcLabs.QuickOpc nuget package v5.58.257. See the following example program:

using System;
using OpcLabs.BaseLib.ComponentModel;
using OpcLabs.EasyOpc.DataAccess;
 
namespace OpcTesting
{
    class Program
    {
        static void Main(string[] args)
        {
            var easy = EasyDAClient.SharedInstance;  // throws FileNotFoundException related to App_Web_OpcLabs.EasyOpcClassicRaw.x86
        }
    }
}

This makes it difficult to get started quickly going to the nuget route and also messy when one has a build server that packages up the installer. Any updated suggestions?

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

support
Offline
Moderator

More

16 Nov 2019 19:59 #7974 by support

Replied by support on topic Please support PackageReference for NuGet packages

Hello,

thanks for pointing me to github.com/NuGet/Home/issues/7276#issuecomment-486779786 . Did you mean the workaround suggested there by 'zivkan' on Apr 25 (2019)?

If so, I am afraid going that way, because by investigating further, it looks like the workaround itself is not working as intended. See github.com/NuGet/Home/issues/3830 , the comment from 'zivkan' from Oct 10 (2019). In this post, 'zivkan' (who suggested the workaround on Apr 25) confirms that it does not work - referring to an example made by 'louistio' on Oct 8, which uses precisely the workaround's technique (with "ref\") .

Best regards

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

Fitsyk
Offline
New Member

More

13 Nov 2019 08:38 #7965 by Fitsyk

Replied by Fitsyk on topic Please support PackageReference for NuGet packages

Hi guys,

Any updates on this issue?
I got the same problem recently and looks like there is a workaround described under related Nuget issue:
github.com/NuGet/Home/issues/7276#issuecomment-486779786
They require actions from your side. I can only manually reference these dlls but as you stated below it's not preferable solution.

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

support
Offline
Moderator

More

20 Sep 2018 19:32 - 20 Sep 2018 19:35 #6700 by support

Replied by support on topic Please support PackageReference for NuGet packages

Hi.

Either way of addressing this from our side, it is a kind of change that will not go to the new build of the same version (which is reserved for isolated bug fixes); it would have to be a change that accompanies a fully new version. QuickOPC 2018.3 should go out in November or December this year. So, we will check the status of the issue on the NuGet side before releasing QuickOPC 2018.3, and address it if necessary - either in the way I suggested, or the way suggested by you.

As I wrote, the explanations related to why our assemblies are made up the way they are would be quite long. It's difficult to put it into a short form. To answer, in simplified form, part of your question: We do not want to the assemblies in question (App_Web_*) be actually referenced from user's project because 1) they only contain types for internal use that the developer does not need and would only pollute the namespaces available to him with stuff he should *not* use, and 2) one of them is for 32-bit and the other for 64-bit architecture, and when they are both referenced, some tools and some hosting environments have problems with it.

Best regards

Last edit: 20 Sep 2018 19:35 by support.

The following user(s) said Thank You: binki

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

binki
Topic Author
Offline
Senior Member

More

20 Sep 2018 18:29 - 20 Sep 2018 19:59 #6699 by binki

Replied by binki on topic Please support PackageReference for NuGet packages

Hi,

I agree with your decision of how to handle this issue. The issue on Github is young (15 days) and acknowledged as a bug by the nuget team member. There is a chance that it will be fixed soon, though I don’t have much hope, personally ;-)

.

I am wondering why the ugly hack you mention would require the files to also be embedded instead of just copied to the output directory. Is putting the native assemblies as <reference/> elements in the .nuspec impossible/wrong/broken for some reason? If that is the case, you can always target PackageReference users directly with a .targets file in the build/ folder of the .nupkg and basically put my workaround in or even use the MSBuild Copy Task: docs.microsoft.com/en-us/nuget/create-packages/creating-a-pa...props-and-targets-in-a-package . While referencing a .targets file for packages.config users requires writing install.ps1/uninstall.ps1 and is rather ugly, the automatic that PackageReference uses works quite well and cleanly. Also, you can simply omit the install.ps1/uninstall.ps1 to avoid targeting packages.config users (who don’t even need it) IIRC.

I personally will use my workaround for the time being. I am only concerned that I will forget my workaroudn is in place when I go to update the NuGet package or VisualStudio in the future. In that case, if you fixed the issue from your end or VisualStudio fixed the NuGet bug, my workaround has a change (EDIT: chance) of behaving strangely.

Thanks for the help and insight!

Last edit: 20 Sep 2018 19:59 by binki. Reason: typo

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

support
Offline
Moderator

More

20 Sep 2018 17:05 #6698 by support

Replied by support on topic Please support PackageReference for NuGet packages

Thanks for this as well. I noticed you have contributed to the NuGet issue list on GitHub as well.

And, I started debugging the problem, and I realized that I have been wrong. In the recent versions, we do NOT embed the App_Web_* assemblies inside EasyOpcClassic. I confused it, because it was the way it worked in the past. So yes, they *are* needed in the Output directory. And you are exactly right in identifying this as an issue with PackageReference on the NuGet client side.

We now need to think what to do about it. Ideally, if the PackageReference problem is fixed soon, I would prefer to do nothing on our side (and you/others can use the workaround you have kindly provided, in the meantime).

But, if it's not fixed soon, we will need to do something about it. That "something" is probably going to be an ugly hack with having these files separately and ALSO embedded (both of these are needed for reasons that are quite complicated and convoluted; I can explain if you are really interested).

Best regards

The following user(s) said Thank You: binki

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

binki
Topic Author
Offline
Senior Member

More

20 Sep 2018 16:28 #6697 by binki

Replied by binki on topic Please support PackageReference for NuGet packages

I would like to share the code I am using to work around the issue in my .targets files. I put this in a shared targets file in our buildsystem. You could put it in Directory.Build.targets in the folder where your .sln file is or directly into your .csproj. This target automatically detects a reference to OpcLabs.BaseLib and adds additional references to the App_Web_OpcLabs* based on the path of OpcLabs.BaseLib.

This is somewhat of a hack and only meant for people using PackageReference who are experiencing the same issue I am. It also should be removed from your project once PackageReference changes its behavior to copy all files from the lib/net452 directory (github.com/NuGet/Home/issues/7276) or once OpcLabs releases an updated nupkg which provides an alternative workaround:

<?xml version="1.0"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <!--
      Special hack for OpcLabs.QuickOpc to work around https://github.com/NuGet/Home/issues/7276 and http://www.opclabs.com/forum/feature-requests-product-improvement-ideas/2523-please-support-packagereference-for-nuget-packages for it.
  -->
  <Target BeforeTargets="ResolveAssemblyReferences" Name="HackAddQuickOpcNativeReferences">
    <ItemGroup>
      <Reference Condition="'%(Filename)' == 'OpcLabs.BaseLib'" Include="%(RelativeDir)App_Web_OpcLabs.EasyOpcClassicRaw.amd64.dll"/>
      <Reference Condition="'%(Filename)' == 'OpcLabs.BaseLib'" Include="%(RelativeDir)App_Web_OpcLabs.EasyOpcClassicRaw.x86.dll"/>
    </ItemGroup>
  </Target>
</Project>

The following user(s) said Thank You: tblong

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

1
2

Moderators: support

Time to create page: 0.076 seconds

Powered by Kunena Forum

Joomla SEF URLs by Artio