Re: Using .NET/Link on 64-bit Windows Server
- To: mathgroup at smc.vnet.net
- Subject: [mg125038] Re: Using .NET/Link on 64-bit Windows Server
- From: Todd Gayley <tgayley at wolfram.com>
- Date: Sun, 19 Feb 2012 06:29:44 -0500 (EST)
- Delivered-to: l-mathgroup@mail-archive0.wolfram.com
- References: <jhfuve$sp0$1@smc.vnet.net>
At 05:24 AM 2/17/2012, Joe Eddy wrote: >Okay, I figured out that this is a problem with the .NET/Link library >on a 64-bit machine when using NativeLink. The NativeLink constructor >doesn't have any code to detect when running a 64-bit application on a >64-bit OS, so it will never use the Win64 API. I added some code to >detect this to the library and now it seems to be working fine on both >64- and 32-bit machines. > >I already posted a follow-up with example code of the change I made in >the NativeLink class. Joe, Your version of .NET/Link is several years old, and was the last version not to support 64-bit .NET processes. I'm glad you were able to modify the source code to hook up the support for 64-bit programs (experimental at the time). This is one advantage of shipping the full source code to a component like .NET/Link. An alternative, however, is to simply force your own program to launch in 32-bit mode. That is the program that determines the bitness of the .NET process. This could be as simple as setting a flag in Visual Studio when you compile your program (you mention that your program is set as "AnyCPU", which will make it launch by default as 64-bit on 64-bit Windows; you should set it to "x86" instead). This isn't feasible if your program requires a 64-bit component, such as a native C-language 64-bit DLL, in which case you must run 64-bit and .NET/Link must be able to run 64-bit as well. Since version 7 of Mathematica, .NET/Link has happily supported 32-bit or 64-bit .NET programs, so most readers need not be concerned with these details. Todd Gayley Wolfram Research