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.
- QuickOPC-Classic in .NET
- Live Binding, Live Mapping
- Upgrading a Project with Live Binding
Upgrading a Project with Live Binding
The basic procedure for fixing the project saved in "regular" 5.40 Build 315.1 is as follows:
1. Close Visual Studio. Make backups of your solutions.
2. Ideally, uninstall all QuickOPC/OPCData versions you have on the computer, and specifically, make sure you do not have any OpcLabs.* assemblies anywhere. In principle that wouldn't be a problem if you keep track of which one is which, but because the old and new ones are almost identical, there is such a high risk of confusion that I really highly recommend this.
3. Install Version 5.40B Build 315.1.
4. Start Visual Studio and open your solution/project.
5. Check the project references. if they point to the newly installed assemblies, fine. If the references do not point to valid assembly files, remove them and add again, pointing to assemblies from 5.40B Build 315.1.Save the project.
6. Open each form in the project, and re-save it. You will need to change something and then change it back, to force Visual Studio designer to actually re-generate the code. What I have done in my test is that I have changed some Form property (such as BackgroundColor) back and forth, and then did File->Save All.
After this, the projects should be in the correct format. That is, later versions should be able to open them and work with them.
In my test, I then installed 2018.3 and it worked, with two extra changes:
a) project's target framework had to be changed to 4.6.2 or later, as that is the minimum for 2018.3,
b) because some namespace changes, I had to do textual search & replace (Ctrl+Shift+H) and replace AddressSpace.BrowsePath by Navigation.BrowsePath (for OPC DA) and/or AddressSpace.UABrowsePath by Navigation.UABrowsePath (for OPC UA).
I will provide the installer package links via email.
The customer is using build 5.40.315.1.
Below is the directory listing of assemblies after an installation of that build. (Might be needed later to identify differences in file times/sizes from the files instaleld by the new 5.40 "branch").
Volume in drive C has no label. Volume Serial Number is F43C-A784 Directory of C:\Program Files\Software Toolbox\OPCData 5.4\Assemblies\net452 07/29/2019 02:30 AM <DIR> . 07/29/2019 02:30 AM <DIR> .. 07/29/2016 08:05 AM 4,073,472 App_Web_OpcLabs.EasyOpcClassicRaw.amd64.dll 07/29/2016 08:00 AM 2,906,624 App_Web_OpcLabs.EasyOpcClassicRaw.x86.dll 07/29/2019 02:25 AM <DIR> CodeContracts 07/29/2019 02:25 AM <DIR> Design 07/29/2016 07:51 AM 6,857,728 OpcLabs.BaseLib.dll 07/29/2016 07:50 AM 1,121,916 OpcLabs.BaseLib.XML 07/29/2016 07:55 AM 1,948,160 OpcLabs.BaseLibForms.dll 07/29/2016 07:55 AM 371,360 OpcLabs.BaseLibForms.XML 07/29/2016 08:06 AM 17,815,552 OpcLabs.EasyOpcClassic.dll 07/29/2016 08:05 AM 1,067,635 OpcLabs.EasyOpcClassic.XML 07/29/2016 08:08 AM 1,912,832 OpcLabs.EasyOpcClassicForms.dll 07/29/2016 08:08 AM 226,452 OpcLabs.EasyOpcClassicForms.xml 07/29/2016 07:53 AM 1,696,768 OpcLabs.EasyOpcClassicInternal.dll 07/29/2016 07:53 AM 1,476,055 OpcLabs.EasyOpcClassicInternal.XML 07/29/2016 07:59 AM 9,253,376 OpcLabs.EasyOpcUA.dll 07/29/2016 07:59 AM 2,665,405 OpcLabs.EasyOpcUA.xml 07/29/2016 08:03 AM 781,312 OpcLabs.EasyOpcUAForms.dll 07/29/2016 08:03 AM 138,895 OpcLabs.EasyOpcUAForms.XML 07/29/2016 08:07 AM 44,544 OpcLabs.OpcComplexEventProcessing.dll 07/29/2016 08:07 AM 35,085 OpcLabs.OpcComplexEventProcessing.xml 18 File(s) 54,393,171 bytes Directory of C:\Program Files\Software Toolbox\OPCData 5.4\Assemblies\net452\CodeContracts 07/29/2019 02:25 AM <DIR> . 07/29/2019 02:25 AM <DIR> .. 07/29/2019 02:25 AM 103 Code Contracts (Download).url 1 File(s) 103 bytes Directory of C:\Program Files\Software Toolbox\OPCData 5.4\Assemblies\net452\Design 07/29/2019 02:25 AM <DIR> . 07/29/2019 02:25 AM <DIR> .. 07/29/2016 07:58 AM 200,704 OpcLabs.BaseLibDesign.dll 07/29/2016 07:50 AM 34,304 OpcLabs.BaseLibToolbox.dll 07/29/2016 08:09 AM 66,048 OpcLabs.EasyOpcClassicDesign.dll 07/29/2016 07:51 AM 21,504 OpcLabs.EasyOpcClassicToolbox.dll 07/29/2016 08:04 AM 39,936 OpcLabs.EasyOpcUADesign.dll 07/29/2016 07:51 AM 19,968 OpcLabs.EasyOpcUAToolbox.dll 6 File(s) 382,464 bytes Total Files Listed: 25 File(s) 54,775,738 bytes 8 Dir(s) 53,366,116,352 bytes free
The customer would then use 5.40R2 to open all forms, and re-save them. This would convert them to the correct format, which should then be readable in any newer version.
I was out of the office for the last week, but I heard back from the customer today. They are dealing with 400 binding points in their application. I did not mention to them any possibility of going back and fixing the older version, but given the number of bindings we are dealing with, they requested a fix to it on their own.
I do have a question though. Let's say you do go back and fix V5.40. For the sake of this response, I will called it 5.40R2. Wouldn't they still be faced with the same issue of not being able to convert their current application from 5.40 to 5.40R2 because of the difference in format?
Please advise how we should proceed.
I have found the cause. Basically, there is a bug in version 5.40 that causes it to store the bindings in wrong (binary resource) format, only recognizable by version 5.40 - instead of the proper code/text format. The subsequent version (2016.2) does it correctly already.
The problem is, that there is no realistic way to make newer versions read that format from 5.40. This means we are dealing with somewhat serious issue regarding the inability to upgrade live bindings saved in 5.40 to any newer version.
How big is the customer's project? if it were not too big, I would probably come up with a manual procedure that would involve 1) deleting the point bindings using text editor, and 2) re-creating them, one by one, in newer version.
The only other alternative I see is as follows: I would have to go back to version 5,.40, and fix it. This is not easy because it is 3 years old, and even the building environment for it has changed quite a lot since. And I would have to cherry-pick the changes from 2016.2 and project them back to 5.40. And make a new build. All that together is quite a task for me. A customer would then install this fixed build of 5.40, and open and re-save each form. The project should become upgradable by doing this.
You know that as a rule, we do not go back to make fixes to older versions. And I would rather follow the rule consistently if possible. But I understand that this is somewhat special issue, because it prevents a project upgrade. Please let me know whether the manual process outlined above would be acceptable instead.
But yes, those steps you listed are what I was doing and also what I instructed the customer to do. Thank you for your guidance and I will await your next response.
I am somewhat puzzled - the "upgraded" project does not appear to be upgraded at all. It references the 5.40 assemblies, and contains their copies in itself. Specifically, if you open the LiveBindingUpgrade.vbproj in a text editor, you will see
<Reference Include="App_Web_OpcLabs.EasyOpcClassicRaw.x86, Version=5.40.315.1, Culture=neutral, PublicKeyToken=6faddca41dacb409, processorArchitecture=x86"> <SpecificVersion>False</SpecificVersion> </Reference> <Reference Include="NetToolKit, Version=22.214.171.1244, Culture=neutral, PublicKeyToken=5107b9c608443dcc" /> <Reference Include="OpcLabs.BaseLib, Version=5.40.315.1, Culture=neutral, PublicKeyToken=6faddca41dacb409, processorArchitecture=MSIL"> <SpecificVersion>False</SpecificVersion> </Reference> <Reference Include="OpcLabs.EasyOpcClassic, Version=5.40.315.1, Culture=neutral, PublicKeyToken=6faddca41dacb409, processorArchitecture=MSIL"> <SpecificVersion>False</SpecificVersion> </Reference>
1. Open the solution in VS, and in Solution Explorer, under Solution... -> LiveBindingUpgrade -> References, delete App_Web_OpcLabs.easyOpcClassicRaw.x86, delete OpcLabs.BaseLib, delete OpcLabs.EasyOpcClassic.
2. Right-click on Reference in the Solution Explorer, select Add Reference. Select Browse on the left. Click the Browse button (bottom right).Locate the assemblies of the latest version (they are in the QuickOPC installation directory under Assemblies), and select (with help of Ctrl) OpcLabs.BaseLib.dll and OpcLabs.EasyOpcClassic.dll. Press the Add button.Press the OK button in the Reference manager Dialog.
But you are right in principle - after doing this, I also got the error with Resx file. This seems to be due to the fact that for whatever reason, the live bindings are not stored in the form as they should (in textual form) - instead, they are in binary, and the newer version cannot decode that.
I will investigate this separately now (it will take some time), and let you know then.
- QuickOPC-Classic in .NET
- Live Binding, Live Mapping
- Upgrading a Project with Live Binding