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
- QuickOPC-Classic in .NET
- General Issues, Building
- Building with .Net 4.6.2 and x64 causes InvalidOperationException
Building with .Net 4.6.2 and x64 causes InvalidOperationException
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.
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.
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.
Please Log in or Create an account to join the conversation.
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.
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.
Please Log in or Create an account to join the conversation.
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.
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.
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.
Win 10 pro
VS 2017
QuickOpc...2016.2
Is any chance to solve this problem? (during 1 Month)
Thans for response.
Please Log in or Create an account to join the conversation.
Best regards
Please Log in or Create an account to join the conversation.
- Forum
- Discussions
- QuickOPC-Classic in .NET
- General Issues, Building
- Building with .Net 4.6.2 and x64 causes InvalidOperationException