64 Bit

Nov 20, 2012 at 6:39 AM

I have extensive code written in 32 bit.  How can I change to 64 bit Dot Spatial?

A simple road map would be appreciated.  Not using GDAL.   Thx.

Nov 20, 2012 at 1:05 PM

I think most of the dotspatial dlls are compiled in "anyCPU" configuration... which I don't exactly know what it means. 

However I downloaded source code and opened it (dotspatial.sln) with the free microsoft visual c# express... it gives me some warnings but in the end the project opens. If you hae microsoft visual c# pro maybe it would be better.

Then I change the compiler target to x64 for the components and plugins I need to be 64bit (in project setting) and recompile the source. 

Then I copy the recompiled dlls to the debug folder of my project and compile the project 64bit.

I don't know if this helps or if you need more detailed instructions

Oscar

Developer
Nov 26, 2012 at 6:28 PM

"AnyCPU" means that the JIT (Just In Time) compiler will convert the binary (Dot Spatial DLL in this case) to the appropriate target at run-time.  This is all for free in the .NET Runtime system.  You should be able to always build the Dot Spatial DLLs with the AnyCPU setting.  If your application that references the AnyCPU Dot Spatial DLLs is 64-bit, the Dot Spatial DLLs will be loaded as 64-bit DLLs.  Otherwise, they will be loaded as 32-bit.  The following statement is probably still true, but I did not verify it with the latest version of Visual Studio: You should avoid compiling DLLs as 64-bit if you ever are going to have a Windows Form or Control that depends on that DLL.  The reason is that the Visual Studio Designer is a 32-bit application and it will have trouble loading your form/control in the designer if it depends on a 64-bit DLL.

We build our application (.exes) as either x86(32-bit) or AnyCPU, but always reference the AnyCPU Dot Spatial DLLs.  We deploy the the x86 exes on 32-bit systems and the AnyCPU exes on 64-bit systems.  The AnyCPU exes will run as 64-bit processes on a 64-bit OS.  The only reason we did not build all of our .NET executables as AnyCPU was because we also depended on native DLLs and we wanted to have a build target we could key off of so we could build and include the appropriate native DLLs during the build process.

Hope this helps.

Kyle

Nov 27, 2012 at 6:55 AM

Thank you Kyle,

I have read somewhere that not all of the dlls are compiled anyCPU. The one interests me is the GDAL library which is not delivered in anyCPU compiled format.

I tried to recompile it in 64 bit (since anyCPU is not applicable, don't know why), still I cannot load the DLL when compiling 64bit my project in visual studio. 

So you know it there is some tricks to solve this problem? or detailed instruction on how to recompile it correctly?

 

Thank you

Oscar

Editor
Nov 27, 2012 at 7:56 AM
oscarafone77 wrote:

The one interests me is the GDAL library which is not delivered in anyCPU compiled format.

The GDAL CSharp bindings that come with the x64 installer by Tamas Szekeres (http://www.gisinternals.com/sdk/) are compiled targeting AnyCPU.

Now, if you place the native binaries in respective x86 and x64 binaries and check IntPtr.Size (==4 => x86, ==8 => x64) in the GDAL/OGR configuration code, you can set the appropriate paths.

Hth FObermaier

Developer
Nov 27, 2012 at 3:38 PM

Just to expound a little bit on FObermaier's response... All of the functionality in GDAL is provided in native code DLLs (not .NET DLLs);  those native code DLLs are provided by Tamas in both the x86 and x64 formats.  The Dot Spatial DLLs that use GDAL actually reference the GDAL CSharp bindings which are .NET DLLs.  Those CSharp binding DLLs than use P/Invoke to call into the native GDAL DLLs.

Developer
Nov 27, 2012 at 3:50 PM
64-bit means that you can't reference any 32-bit assemblies, at least according to the linqpad folks.

LINQPad for .NET Framework 4.x - Any CPU

If you have queries or scripts that use more than 3GB of memory, you'll want the AnyCPU LINQPad build. This lets you use all available memory on X64 systems. It also lets you reference external assemblies built only for X64.

The flipside of running this build (on X64) is that you can't reference external assemblies built only for X86.(And X86 is the default for executables in Visual Studio 2010!) The AnyCPU build also uses around 60% more memory due to references taking 64 instead of 32 bits.



On Tue, Nov 27, 2012 at 8:38 AM, kellison <notifications@codeplex.com> wrote:

From: kellison

Just to expound a little bit on FObermaier's response... All of the functionality in GDAL is provided in native code DLLs (not .NET DLLs); those native code DLLs are provided by Tamas in both the x86 and x64 formats. The Dot Spatial DLLs that use GDAL actually reference the GDAL CSharp bindings which are .NET DLLs. Those CSharp binding DLLs than use P/Invoke to call into the native GDAL DLLs.

Read the full discussion online.

To add a post to this discussion, reply to this email (DotSpatial@discussions.codeplex.com)

To start a new discussion for this project, email DotSpatial@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Editor
Nov 27, 2012 at 7:39 PM

Feel free to check out (http://goo.gl/xuAG3)

Hth FObermaier

Nov 28, 2012 at 7:30 AM

 

In the dotspatial source code directories I found a txt file explaining how to make gdal 64bit

In the file it is written:

"1) Set The bitness of DotSpatial.Data.Rasters.GdalExtension to x64 or x86 and then build it.

2) Build the corresponding GdalExtension64 or GdalExtension32

3) Build your application with the applicable bitness (you can leave all the supporting libraries as AnyCPU).

By default we have things setup to run as 32bit on 64 bit machines."

 

I tried to do so, but then when I run my 64bit app the 64bit compiled GDAL plugin is not loaded (neither the 32bit one, and this is coherent on what Valentinedwv said)

Any idea why this is not working?

thank you

Oscar

Editor
Nov 28, 2012 at 6:28 PM

The point I was trying to make is that you do not need to split GdalExtensions project into x86 and x64 if you reference the managed GDAL assemblies (*_csharp.dll) provided by the GDAL x64 installer. All you have to do is create two seperate directories for the native binaires and one for the support files.

If you set your GdalExtension project to compile for AnyCPU you can check for the pointer size (IntPtr.Size) in the configuration code and set the GDAL environment accordingly.

At least it works for me, see http://goo.gl/xuAG3 and explore the package to see what I'm talking about.

Hth FObermaier

Nov 29, 2012 at 7:51 AM

well I have visual studio 2010 express (vb.net) and I cannot find the library package manager in the tools menu.

Any other way to install the GDAL dlls?

 

Thank you

Oscat