I'm a bit of a beginner to C# and I've recently built a Windows Form Application GUI which executes a MATLAB function in much the same way as the answer presented here. So essentially using the Process.Start method to run the MATLAB function in the background.
This works fine with a 32-bit compiled MATLAB function, however compiling the function as a 64-bit executable leads to an error when executing from the WFA GUI - "Could not find version 8.2 of the MCR. Attempting to load mclmcrrt8_2.dll."
If I run the compiled function outside of the WFA GUI I have no problems. So it seems that the WFA cannot execute 64-bit processes, is there a workaround for this?
Thanks for any help.
You cannot have both MATLAB and MCR installed on the same machine and consistently run at deployed app.
I have not had any luck if both x32 and x64 MCR are installed, but you can have different version of the MCR installed, although that's not optimum.
If you have an x64 MCR deployed MATLAB, you must use x64 in your c# app.
This is not clearly documented, and these are from my experience deployed the same MATLAB base as a COM DLL, an x32 .NET assembly, and an x64 C++ shared library.
Related
I have written a COM control in c# .Net 4.5, this COM control uses a 3rd party dll to communicate with a USB device.
On Windows 7 32bit everything works 100% from both VBScript and the VB6 app. On Windows 7 64bit the VBScript fails when calling the 3rd party dll function that uses the USB device.
The exception is: "System.AccessViolationException" with message: "Attempted to read or write protected memory. This is often an indication that other memory is corrupt."
What I don't understand is that the same COM control (and the same USB driver) works when instantiated from the VB6 app, but not from the VBScript.
I have looked at the loaded assemblies and registry access using Process Monitor when running the VB6 app and the VBScript but I cannot see anything out of the ordinary.
Any suggestions of what I can troubleshoot or test next?
Here's the deal. Applications written from VB6 are 32-bit. Your application works on 32-bit Windows and from a VB6 app on Windows 64 (which is running as 32-bit, since VB6 produces 32-bits. So, we know that your DLL works with 32-bit applications.
The thing is, when you run a VB script on Windows 64, it runs as a 64-bit process and you have a mismatch with your 32-bit DLL. If you run the VB script with the 32-bit version of the VB script engine (c:\windows\syswow64\wscript.exe or c:\windows\syswow64\cscript.exe) does it work? It probably will.
Now, if you compiled your DLL with the AnyCPU processor setting, then you can still register your DLL and get it to work with a 64-bit process. Just be sure to use the regasm.exe that is in the 64-bit hive.
For example register your DLL as such,
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\regasm.exe /tlb /codebase c:\path\to\yourdll.dll
I made a default Silverlight 5 project in VS2013 and let Visual Sudio create the sample web host as a web application. I then ran it and saw that it loaded fine.
Now things get odd: I want to call some C++ code (cryptopp) so I think that I need Silverlight to run as x86 to include it. When I swap it to build as x86 and run the app in the browser it crashes (not calling anything yet, only swapping the debug build configuration to x86).
So: Is it even possible to run Silverlight as x86?
Edit:
64 bit OS. 32bit and 64bit IE both fail to display
Your only chance to call a lib written in C++ (and therefore unmanaged code) is to run your silverlight app with elevated trust.
You did not mention that you configured it to require elevated trust, so maybe that's where your actual problem lies? I don't think it has anything to do with x86 vs x64.
The answer is apparently no.
No you cannot run a Silverlight app that has been compiled as x86. It fails to initialize.
It appears to have a hard time loading an assembly that is required for a base, empty Silverlight app. We've verified it on 3 machines in both Silverlight 4 and 5.
How c# written code is running on mac version of Mono. Can you please explain because as far as i know Mac doesn't support .exe files. Then when we build a c# application how it run on Mac.
It's a massive topic. But to address the .exe file point, you would launch mono with the .exe as the parameter of the mono process. It's not the native OS that is 'supporting' the .exe, it is mono itself.
This is really no different to any .net implementation, in that the 'executable' runs in a sandbox, not directly interfacing with the OS.
We have a c# executable that loads a 32bit dll written in C++ which dynamically loads another 32bit dll (the first dll is a wrapper).
When this is built on a 32bit machine (with VS toolset v100) it all works correctly.
When it is built on a 64bit machine (with VS toolset v110) it runs on some machines, but on others it gets a FileNotFoundException on the wrapper dll. It works on some 64bit machines, fails on some and fails on at least one 32bit machine.
The failure happens in Assembly.LoadFrom, where the location comes from Assembly.GetExecutingAssembly().Location. The dll is in the same dir as the exe, which was build as x86.
If build on a 64bit machine to get a failing version, then I drop in a version of the wrapper dll built on a 32bit machine, it works properly (so it's not really a file not found problem, but rather a 'correct' file not found one).
Any ideas why this is failing? Is it the build machine, or the toolset? Or something else? Is there something I can set in the build to get it working properly (I'd like to continue building on a 64bit box)?
Do you have all dependency dlls installed on the client machines? Like VC Runtime, other libraries you depend on?
I want to build an application using Quicktime ActiveX interop that could run on a 64bit windows seven OS.
My problem is that the 3 dll : AxInterop.QTOControlLib.dll, Interop.QTOControlLib.dll, Interop.QTOLibrary.dll seems not to be compatible with 64bit OS => It leads to a crash as soon as the application is started.
How can I pass through this?
You must build your program as a x86 program. You can set this at the project properties.