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.

Building with .Net 4.6.2 and x64 causes InvalidOperationException

More
30 Mar 2017 15:26 #5060 by support
This issue should now be fixed. It is in QuickOPC 2016.2 Build 1144.1, now available from the download area of our Web site.

The cause of the problem was that in .NET 4.6.2, some methods have changed their behavior.

Note that QuickOPC 2016.2 does *not* officially support .NET 4.6.2 - not before the fix, and not after the fix. The official support for .NET 4.6.2. will come with QuickOPC 2017.1.

Best regards

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

More
29 Mar 2017 15:36 #5051 by support
Thank you for this. It helped.

Good news: It looks like I got the problem reproduced now. Stay tuned - I will post here when I have more information.

The type of application (WPF or Windows Forms) seem to be irrelevant - my repro is with a Console application.

Best regards

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

More
29 Mar 2017 15:02 - 30 Mar 2017 05:23 #5050 by Erik
Sorry, I am going to fast and as a result I am mixing things up.

The project does indeed build and throws a run time error the moment it wants to access something opclabs related. When I looked into it I came across msdn.microsoft.com/en-us/library/zekwfyz4.aspx

Which states:

Remarks

anycpu (default) compiles your assembly to run on any platform. Your application runs as a 64-bit process whenever possible and falls back to 32-bit when only that mode is available.

anycpu32bitpreferred compiles your assembly to run on any platform. Your application runs in 32-bit mode on systems that support both 64-bit and 32-bit applications. You can specify this option only for projects that target the .NET Framework 4.5.

ARM compiles your assembly to run on a computer that has an Advanced RISC Machine (ARM) processor.

x64 compiles your assembly to be run by the 64-bit common language runtime on a computer that supports the AMD64 or EM64T instruction set.

x86 compiles your assembly to be run by the 32-bit, x86-compatible common language runtime.

Itanium compiles your assembly to be run by the 64-bit common language runtime on a computer with an Itanium processor.

On a 64-bit Windows operating system:

Assemblies compiled with /platform:x86 execute on the 32-bit CLR running under WOW64.

A DLL compiled with the /platform:anycpu executes on the same CLR as the process into which it is loaded.

Executables that are compiled with the /platform:anycpu execute on the 64-bit CLR.

Executables compiled with /platform:anycpu32bitpreferred execute on the 32-bit CLR.

The anycpu32bitpreferred setting is valid only for executable (.EXE) files, and it requires the .NET Framework 4.5.


When building my project for AnyCpu, I get the exact same exception as in my original post. Only when I hit prefer 32bits does it compile. (including the simple example project).

I also found that projects build with AnyCpu 32bit preferred (x86 or x64) gets the benefits of x64. IE not being restricted to the first 4gb of ram. This effectively meant its a non issue in my case.

But! The take away here is that I cant get a succesfull x64 project for .net 4.6.2, AnyCpu doesnt change this. Which is what I intended to point out. Sorry for the confusion.
Last edit: 30 Mar 2017 05:23 by Erik.

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

More
29 Mar 2017 14:12 #5049 by support
Thanks for reply, but I am confused now. You wrote "(as evidenced by being unable to build x64)", but nowhere before could I find a mention of being unable to build for x64. The problem report was about runtime error, not an inability to build.

Can you please clarify.

In fact, I do not understand the first sentence of your reply either: "when compiled with AnnyCPU, it will only allow the program to run in x64 if it successfully compiled everything to x64". That's not how it works... A program compiled with AnyCPU and executed on a 64-bit systems will, without further configuration effort, always run as 64-bit.

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

More
29 Mar 2017 14:05 - 29 Mar 2017 14:07 #5048 by Erik
Note that when compiled with AnnyCPU, it will only allow the program to run in x64 if it successfully compiled everything to x64. Since a project with opclabs referenced fails on .net 4.6.2 (as evidenced by being unable to build x64) the program will never run in x64 and instead will always run x86.

Its how I found the bug in the first place, as my program was running x86 on a x64 machine.

Edit: Incase it matters, my project is WinForms and not WPF.
Last edit: 29 Mar 2017 14:07 by Erik.

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

More
29 Mar 2017 13:56 #5047 by support
This has to be some kind of conflict with something... but it's not clear with what.

I have created a new machine with 64-bit Windows 10, and VS 2017. Installed QuickOPC 2016.2, created a new WPF project and put in some code to read OPC UA data. And switched it to x64. It works.

This is similar to the case of the customer further above - we weren't able to reproduce the issue either.

Just to make my scenario close to yours, can you send me a simple project of yours that shows the problem?

And, I have a comment to your answer to Q3: It's still not clear why you would need to set the project to x64. All it does is that it instructs the loader to always JIT the MSIL code into a 64-bit code and 64-bit process (making it impossible to run on 32-bit WIndows). But when you use the normal setting (AnyCPU), it decides for itself automatically what to do, and on 64-bit computers, it will *also* run in 64-bit process, resulting in the same effect as the x64 setting.

See e.g. stackoverflow.com/questions/27758329/x86-vs-x64-vs-anycpu .

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

More
29 Mar 2017 09:49 #5044 by bmts
Hello,
response on question:
Q1: WPF application (MVVM model)
Q2: problem occure when is set x64
Q3: I have first and "empty" prototype for my project and the size of appllication has about 1GB memory during runtime. And i Have experience that the speed and response of application is better for x64.
Q4: I have all OPCUA data as classes.(LIVE MAPPING model)

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

More
26 Mar 2017 09:47 #5034 by support
Hello.

Unfortunately we were not able to reproduce the problem so far, and as such it is fairly difficult to address it in some way.

Can you please answer some additional questions:

1. What kind of project you have (e.g. Windows Forms app, Console app, Windows Service, Web app, Web service, etc.)?

2. When the problem occurs, is that with a project built specifically for x64, or is it with a project built for AnyCPU but run in a 64-bit process?

3. If you are building specifically for x64, may I ask what is the reason for it - why not AnyCPU ?

4. Are you loading an OPC UA configuration from a XML file? (opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...plication%20Configuration.html ) - probably not, as this is an advanced technique, but there is an issue in this area which I want to rule out.



Thank you

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

More
23 Mar 2017 11:55 #5033 by bmts
I have the same problem..

Win 10 pro
VS 2017
QuickOpc...2016.2

Is any chance to solve this problem? (during 1 Month)
Thans for response.
Attachments:

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

More
06 Feb 2017 06:58 #4926 by Erik
At the moment I dont realy need to build for x64. There are other area's we can improve our program. So thank you for your time, we can consider this closed.

Best regards

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

Moderators: support
Time to create page: 0.084 seconds