Compile and Run on Windows 64

Developer
Oct 13, 2010 at 5:35 PM

Hello,

I downloaded the latest Source code and compiled it on Windows 64 / VS2010.  The TestForm app throws all sorts of errors about not being able to load the required assemblies.  I've seen this before and conclude it is a 32/64 mismatch.  So, I set the build type to Any CPU for all assemblies.  Compile and run. Testform.exe runs fairly well.  Still lots of run time errors but they don't apear to be build type related.

Great.

Now I want to open the Main form in the VS2010 designed and the designer complains that: "Could not load file or assembly 'DotSpatial.Symbology, Version=1.0.0.0, Culture=neutral, PublicKeyToken=6178c08da7998387' or one of its dependencies. The system cannot find the file specified."  I just built it and it ran fine.  The dlls are in a [dotspatial]/release folder (which seems wrong to begin with since this is a debug build).  So, the dll's are in the specified build location but the designer can't find them.

Is there a "How to Build" document somewhere?

Anyone seen these problems before?  Am I doing something silly in my dev. env.

Thanks,

Garth

 

Oct 16, 2010 at 6:32 PM

I just downloaded the latest source code and got the same problem with you. Here's the steps how I resolve it:

1. Change all the project targe framework to .net framework 4.0.(some of them is V3.5)

2. Change the project output path to "..\Release\" to make sure all dlls are included in the realease folder.

3. If the "assembly not found" error still exists, check the "copy local" property of referenced assembly, some of them may need to be changed to 'true'.

hope this helps.

Developer
Oct 16, 2010 at 9:20 PM
We need to come up with a single solution to x86 and x64 simultaneous builds, and development. Otherwise we end up committing changes to a solution/project that screw up a different developer.
* always build and test both Debug and release. (with a clean inbetween)
* write (and run and maintain) units tests

1) I'm not sure the v4 is the issue. I'm pretty sure it's not, since I've did at least the compiles for v3.5.
* I compile to v4 using a flag in ms build, and the autobuild environment.
 
2)  we need to separate out the 3rd party unmanaged x86/x64 into separate directoriesm and use a platform hint

3) I also suggest that for apps, we recode the example apps, so that the Dotspatial Dll's are in a directory (and use app.config probing runtime/probing/privatePath )


configuration>
3
····<configSections>
4
····</configSections>
5
··<runtime>
6
····<!--·see·http://msdn.microsoft.com/en-us/library/4191fzwb.aspx·-->
7
····<assemblyBinding·xmlns="urn:schemas-microsoft-com:asm.v1">
8
······<probing·privatePath="DotSpatial"/>
9
····</assemblyBinding>
10
··</runtime>
11
</configuration>
On Sat, Oct 16, 2010 at 10:32 AM, braveheal <notifications@codeplex.com> wrote:

From: braveheal

I just downloaded the latest source code and got the same problem with you. Here's the steps how I resolve it:

1. Change all the project targe framework to .net framework 4.0.(some of them is V3.5)

2. Change the project output path to "..\Release\" to make sure all dlls are included in the realease folder.

3. If the "assembly not found" error still exists, check the "copy local" property of referenced assembly, some of them may need to be changed to 'true'.

hope this helps.

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


Developer
Oct 16, 2010 at 10:06 PM
Edited Oct 16, 2010 at 11:17 PM

This is a good idea.  On top of that, the switch to NUnit may produce an additional x64 problem for some tests.  When I tried to run the unit test for the projections library set up for x64, it didn't work.  We may need to see if there are separate NUnit libraries for x86 and x64 versions, but I'm not sure how to get my plugins to the IDE to know which NUnit to run, even if they have separate libraries.  At least we could start by setting up the NUnit unit tests as part of the x86 build.

Ted


 

Developer
Oct 16, 2010 at 11:15 PM
Edited Oct 16, 2010 at 11:18 PM

Update.  I have altered the build configurations so that we now have the four possible output build paths.

[root]\Release\x86
[root]\Release\x64
[root]\Debug\x86
[root]\Debug\x64

I have removed the "AnyCPU" and "Mixed" configuration options as they were confusing and could not be counted on to run predictably from developer to developer based on what platform the developer was running on.  The GDAL project is set to not build under the x64 projects since it relies on x86 unmanaged dlls.

I haven't learned about any clever simultaneous settings yet, but this should prevent overwriting of incompatible or mixed framework versions of libraries to the same directory, causing potential platform conflicts.

Ted

Developer
Oct 18, 2010 at 2:43 AM

Update.  While the folder structure remains the same, the x64 modules will not produce working controls unless we alter the build configuration to AnyCPU instead.  The purpose of this is not to deny people on x86 to build x64 applications but rather to allow the visual studio designer to add run-time instances of the controls, while still producing a final application which is fully 64 bit.  So now the build output in the x64 folders is actually AnyCPU, but I will keep the x64 folder name since it is a little clearer.

Ted