Is there a way to leverage NLREG in C#, or from any other .NET language? Currently, we only can find it as a COM object, which gives us issues when we change platforms (32 to 64 and the like).
Unless you actually need the 64-bit memory space in your NLREG client, just set the target platform in your client project to x86 (not AnyCPU), then it'll always work regardless of 32- or 64-bit OS.
Your question wasn't clear if you were changing the target compiled platform for your client, or if you're trying to run on a 64-bit OS- I'm assuming the latter.
Related
I have an application that we're trying to migrate to 64bit from 32bit. It's .NET, compiled using the x64 flags. However, we have a large number of DLLs written in FORTRAN 90 compiled for 32bit. The functions in the FORTRAN DLLs are fairly simple: you put data in, you pull data out; no state of any sort. We also don't spend a lot of time there, a total of maybe 3%, but the calculation logic it performs is invaluable.
Can I somehow call the 32bit DLLs from 64bit code? MSDN suggests that I can't, period. I've done some simple hacking and verified this. Everything throws an invalid entry point exception. The only possible solution i've found so far is to create COM+ wrappers for all of the 32bit DLL functions and invoke COM from the 64bit process. This seems like quite a headache. We can also run the process in WoW emulation, but then the memory ceiling wouldn't be increased, capping at around 1.6gb.
Is there any other way to call the 32bit DLLs from a 64bit CLR process?
You'll need to have the 32-bit dll loaded into a separate 32-bit process, and have your 64 bit process communicate with it via interprocess communication. I don't think there is any way a 32-bit dll can be loaded into a 64 bit process otherwise.
There is a pretty good article here:
Accessing 32-bit DLLs from 64-bit code
You need to write your executable processes as 32-bit processes (versus Any CPU or x64) so that they'll be loaded with WoW32 for Vista. This will load them in the 32-bit emulation mode and you won't have the entry point problem. You can leave you libraries in AnyCPU mode, but your executables have to be compiled as x86.
John's answer is correct if you don't want to recompile your existing dlls; however that might be an option for you as well.
Our team is currently migrating our x86 FORTRAN code to x64 to increase the memory ceiling.
I am designing a client application that will list several applications that I offer. A user will pick the application, and press run, then the application will be downloaded and will be loaded into the client application's domain using Assembly.Load. Here's the snippet of where it gets loaded:
var vAsm = Assembly.Load(client.GetBase());
var vEP = vAsm.EntryPoint;
var vSC = vAsm.GetType(vEP.DeclaringType.FullName).GetMethod("SetClient");
var vInst = vAsm.CreateInstance(vEP.Name);
vSC.Invoke(vInst, new object[] { client, license });
vEP.Invoke(vInst, null);
Problem: Two of the current applications are 32bit. However one of my applications is 64bit.
Question: If I build the client application in AnyCPU, will it be able to load both the 32bit applications AND the 64bit application? Or is there maybe a setting that launches it in 64bit if the machine supports it? This would be ideal, as I would just detect if they are 32bit/64bit and warn them that the one application is not supported on their machine if that's the case.
I will be testing this myself, but maybe somebody could give me some sort of advice to handle this.
Thanks!
To answer your first question, if you compile the application as AnyCPU you let Windows decide which CLR to pick. In my experience, it usually works out to Windows picking the x64 CLR on x64 operating systems and the x86 CLR on x86 operating systems but I'm not certain if that's always a guarantee. AnyCPU does not mean that it gets to run in both. You will only be able to load the version of the application which corresponds to the architecture of the CLR which loaded your client application.
I've had to deal with this sort of thing in some of the applications that I work with at the place where I'm working. I've run into some frustrating bugs when I tried interoperating with applications compiled for a specific architecture and applications compiled for AnyCPU. To make things easier and more predictable, I just ended up compiling the "AnyCPU" applications which had to interact with the "non AnyCPU" applications for each architecture for which they had to interact. There may be some people who have a more sophisticated setup but it wasn't worth the headache for me.
So, the answer to the second question is more advice. I'd just compile the client application for a specific architecture so that you know for sure which architecture that you're dealing with and then add appropriate code to detect the architecture. In fact, I think that you could use some compiler directives to store some sort of indicator as to which architecture that you're running under or even put a "detection" branch specific to each architecture in the compiler directive and that would help you do the warning that you're thinking of doing.
The alternative is to keep the client application as AnyCPU and detect which architecture the application is currently running under (if memory serves, it's IntPtr.Size == 8 for x64 applications but there may be more reliable methods; not sure...) and then only launch the appropriate applications. But still, you have to be mindful of the fact that, even with AnyCPU, you can only load applications of the specific architecture of the CLR which is running your AnyCPU client application.
Does that make sense?
You should build all your binaries in AnyCPU. That way, on a 64-bit OS, they'll run as 64-bit and on a 32-bit OS, they'll run as 32-bit. If you compile to x64, it won't run on a 32-bit OS at all. If you compile to x86, you'll always run as 32-bit, even on a 64-bit OS. The final rule is that you can't mix & match x86 and x64 bins in the same process. The mismatching ones will fail to load.
We have a WebService that's been running for a while, there's about 6~ projects on it.
Recently, we had to support a C++ 32 bit library, I tested and I had to set the project's target platform to x86 or I'd get the BadImageFormatException. So this new project is set to compile on x86, but everything else is set to AnyCPU.
After publishing the WebService, I get the error Unable to find ?.dll when calling the function.
Is there anyway I can add this new project as x86 without having to set my WCF to x86 as well, or am I doing something wrong and this should've worked?
It is possible but all binaries (.exe-s and .dll-s) must share the same target platform for it to work. You cannot load a 32-bit DLL into a 64-bit process or the other way around.
If you're hosting your web service under IIS, the target platform of the app pool determines what kind of DLL-s you can load.
If you have exported functions in your unmanaged DLL-s, your P/Invoke declarations must also match the target platform - specifically, if you pass pointers, those will have to be correctly mapped to 32/64-bit pointers. (Usually IntPtr takes care of this.) P/Invoke declarations really turn into possible problems if you support both platforms with a single source base (compiled into platform-specific binaries).
Depending on what you're trying to do, you may also need to deal with handling platform-specific references. This question has more detail about that.
I need to check if an executable programm compiled for 64 bit version or for 32 bit version on a Windows system.
I think this question is hard to answer, because a .NET executable in Windows contains code in two forms:
The first part is a native stub that brings in the system's available runtime (for older Windows systems, when the OS loader didn't natively recognize CLR assemblies). It can be either 32-bit or 64-bit, like other Windows applications. You can find out its target architecture by analyzing its PE header.
As you can tell, this is rather straightforward to determine. However, I suspect it may also be largely irrelevant for your use case (and for most use cases), because this first part does't contain the "useful" part of your program and is there primarily for legacy reasons.
The second part is the IL (bytecode) that will get JIT-compiled and then executed. This is the useful part, but this is largely platform agnostic when not running. It's the runtime JIT-generated code that becomes 32-bit or 64-bit.
Now, if the assembly is explicitly built using the x86 or x64 configuration, it will be marked as such and you can find out programmatically without running it whether it's going to be 32-bit or 64-bit.
However, if it's marked as AnyCPU (like most assemblies are, these days) you can't know beforehand what to expect from the JIT-compiled code. You can only really find out at runtime (by asking the environment or by comparing the size of IntPtr for example). Or you can make an educated guess - if your current program is running under 32-bit Windows (but determining this from unmanaged code may be unreliable), you definitely don't have to expect that a .NET assembly would generate 64-bit CPU instructions. However, if you're running under 64-bit Windows (again, the most likely scenario), it won't be that easy, especially considering that the semantics of the AnyCPU configuration changed with .NET 4.5 and you'll have to account for those changes as well.
Now, here's the catch that you might already have realized: The first part and the second part may not match. And they often don't, because the most common scenario is building with the AnyCPU configuration (which will typically yield a 32-bit PE executable) and deploying on 64-bit systems, where the IL will be JIT-compiled to 64-bit instructions.
In the end, you'll have to decide specifically which of the two you want to know (and whether it's worth the trouble). You may also want to explore other options, like taking advantage of the fact that AnyCPU assemblies can load as either 32-bit or 64-bit and in many cases you can use them without checking.
We have a Windows Service app written in C# targeted for AnyCPU. It runs on a Win2003 (32bit) server. Recently it started to run out of memory.
What is involved in redeploying this service to a Win2003 (64bit) box. Do I need to recompile it and will the App get more memory if I do not recompile it?
Nothing special if the exe is set for AnyCPU- the 64-bit CLR will load by default on a 64-bit machine. You just have to make sure you're REALLY AnyCPU ready (no unsafe OR safe 32-bit pointer math assumptions, etc). If you're running all managed code with no PInvokes, you should be in good shape.