This project is read-only.

DotSpatial on Mono/Linux

Nov 19, 2010 at 5:18 PM

Hello everybody,

after I have successfully tried several MapWindow6-Versions on my Linux-Machine, I found out that the current version of TestViewer.exe doesn't work (I give the error message below). I tried it then on my windows 7 machine with mono to the same result. Will DotSpatial work with mono again or is this a pure windows build(which would be very sad).

Thanks and regards

Helmut

Linux-Error-Message:

** (TestViewer.exe:2621): WARNING **: Missing method System.Windows.Forms.Application::SetCompatibleTextRenderingDefault(bool) in assembly /usr/lib/mono/gac/System.Windows.Forms/1.0.5000.0__b77a5c561934e089/System.Windows.Forms.dll, referenced in assembly /home/helmut/MapWin-6/x86/TestViewer.exe

Unhandled Exception: System.MissingMethodException: Method not found: 'System.Windows.Forms.Application.SetCompatibleTextRenderingDefault'.

 

Windows-Error-Message:

WARNING: The runtime version supported by this application is unavailable.
Using default runtime: v2.0.50727

Nov 19, 2010 at 6:30 PM

Hi dimpflmoser!  Thank you for reporting this.  I personally work on a windows box, and have been overwhelmed with just trying to get stuff refactored for DotSpatial to take off.  I barely have been keeping up with trying to keep compliance with .Net 3.5, which not every single commit manages to do, though I try to check on it before posting releases to the downloads page.  It is a continuous wrestle because the Designer for 4.0 will break on certain unnecessary lines in the code automatically generated by 3.5.  So maybe if you are using a 4.0 mono and it expects 4.0 code, it is breaking on some of our older forms that also break in the designer when you open them in 4.0.  My intention is to fix those, but I haven't gotten to them all yet.  Mostly it is just lines in the automatic code that don't do anything useful and can safely be removed. 

When you save in 4.0, it will automatically update resource files to reference 4.0.0.0 libraries instead of the 2.0.0.0 libraries that 3.5 builds depend on.  You may be looking at a temporary situation where a build is created that doesn't necessarily work with 3.5, and so depending on your version of mono, may not work for you.  From what I understood, however, Mono now supports the 4.0 framework but it may require you to get the latest version of mono.  This may have been somewhat of an overstatement on their part,  since as usually what that means is "They support the 4.0 framework except...".  That being the case, I'm sure that there are simply a few lines here and there that need to be tweaked to ensure mono will work which I haven't been very good about tracking down lately as we have had some colossal changes made to the architecture lately.   I certainly am not aware of calling the specified method directly, so it is almost certainly automatically generated code, and we can probably get away with removing it.  I will see about trying to run in mono tonight and try to nix the exception that you are getting.

Ted

Nov 19, 2010 at 6:44 PM
Helmut, This is something we all agree with but only few of us have the necessary skills/time to do the Mono testing, so I'm very happy to hear you are doing this. Can you please download the source code and and do a little Mono debugging? - Dan

On Fri, Nov 19, 2010 at 1:30 PM, shade1974 <notifications@codeplex.com> wrote:

From: shade1974

Hi dimpflmoser! Thank you for reporting this. I personally work on a windows box, and have been overwhelmed with just trying to get stuff refactored for DotSpatial to take off. I barely have been keeping up with trying to keep compliance with .Net 3.5, which not every single commit manages to do, though I try to check on it before posting releases to the downloads page. It is a continuous wrestle because the Designer for 4.0 will break on certain unnecessary lines in the code automatically generated by 3.5. So maybe if you are using a 4.0 mono and it expects 4.0 code, it is breaking on some of our older forms that also break in the designer when you open them in 4.0. My intention is to fix those, but I haven't gotten to them all yet. Mostly it is just lines in the automatic code that don't do anything useful and can safely be removed.

When you save in 4.0, it will automatically update resource files to reference 4.0.0.0 libraries instead of the 2.0.0.0 libraries that 3.5 builds depend on. You may be looking at a temporary situation where a build is created that doesn't necessarily work with 3.5, and so depending on your version of mono, may not work for you. From what I understood, however, Mono now supports the 4.0 framework but it may require you to get the latest version of mono. This may have been somewhat of an overstatement on their part, since as usually what that means is "They support the 4.0 framework except...". That being the case, I'm sure that there are simply a few lines here and there that need to be tweaked to ensure mono will work which I haven't been very good about tracking down lately as we have had some colossal changes made to the architecture lately. I certainly am not aware of calling the specified method directly, so it is almost certainly automatically generated code, and we can probably get away with removing it. I will see about trying to run in mono tonight and try to nix the exception that you are getting.

Ted

Read the full discussion online.

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

To start a new discussion for this project, email DotSpatial@discussions.codeplex.com@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




--
Daniel P. Ames, Ph.D. PE
Associate Professor, Geosciences
Idaho State University - Idaho Falls
amesdani@isu.edu
geology.isu.edu
www.mapwindow.org


Nov 21, 2010 at 11:31 PM

I've examined the code of DotSpatial.Controls recently. The code of the Ribbon controls in DotSpatial.Controls.dll (ported from ribbon.codeplex.com) still contains some unmanaged WinApi calls which are probably incompatible with Mono. These WinApi calls are not really necessary for running the Ribbon and should be removed. I have done testing of the ribbon used by HydroDesktop (with WinApi references replaced by managed code) in August and most of the ribbon items worked fine in Mono after removing the WinApi calls.

Now that our application (HydroDesktop) uses the built-in DotSpatial ribbon control, I'd like to merge my mono-compatible version of the Ribbon with the DotSpatial Ribbon.

Nov 22, 2010 at 12:12 AM
Yes, I think that's a good move Jiri. Just be careful since I added some useful new functionality as far as using the user interface in design mode to add buttons that may be lost if you are too violent with the merge. I think the unmanaged api calls would only do something on vista or better versions as well. I don't think they did anything at all on xp or earlier.

Ted


On Sun, Nov 21, 2010 at 3:31 PM, jirikadlec2 <notifications@codeplex.com> wrote:

From: jirikadlec2

I've examined the code of DotSpatial.Controls recently. The code of the Ribbon controls in DotSpatial.Controls.dll (ported from ribbon.codeplex.com) still contains some unmanaged WinApi calls which are probably incompatible with Mono. These WinApi calls are not really necessary for running the Ribbon and should be removed. I have done testing of the ribbon used by HydroDesktop (with WinApi references replaced by managed code) in August and most of the ribbon items worked fine in Mono after removing the WinApi calls.

Now that our application (HydroDesktop) uses the built-in DotSpatial ribbon control, I'd like to merge my mono-compatible version of the Ribbon with the DotSpatial Ribbon.

Read the full discussion online.

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

To start a new discussion for this project, email DotSpatial@discussions.codeplex.com@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


Nov 22, 2010 at 12:02 PM

Hello Dan, hello Ted,

yes certainly I would like to do some linux-testing though I'm quite new to c#, after 15 years of c, perl and vba.

One thing I thought about yesterday is whether you think it could be possible to replace the gui-part with gtk#. As far as I read into the documentation you stated that one developement-aim is to keep the functional and the gui portions apart. At the moment I think I'm not up to this task but as time moves on and my employer wants me to get into c#...

If you think this could be possible, what are the portions of code I should look into first and is there some kind of "map", which describes the code?

regards Helmut

Nov 22, 2010 at 2:05 PM

Hello again,

I've just ran the MonoMigration-Analyzer (http://mono-project.com/MoMA) over the project, and it gave me a few messages. It seems they are mostly connected to .Net 4.0 issues.

regards Helmut

Nov 22, 2010 at 4:26 PM
As far as I know right now, DotSpatial.Positioning is almost entirely unmanaged driver based and won't work. The main DotSpatial projects, Jiri will be updating the Ribbon control, which has some unmanaged API calls. If you are having 4.0 issues, I have posted 3.5 release versions on the download page which should be compatible with Mono 2.8.1 except for the ribbon and Positioning.

Ted


On Mon, Nov 22, 2010 at 6:05 AM, dimpflmoser <notifications@codeplex.com> wrote:

From: dimpflmoser

Hello again,

I've just ran the MonoMigration-Analyzer (http://mono-project.com/MoMA) over the project, and it gave me a few messages. It seems they are mostly connected to .Net 4.0 issues.

regards Helmut

Read the full discussion online.

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

To start a new discussion for this project, email DotSpatial@discussions.codeplex.com@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


Nov 22, 2010 at 4:51 PM

Hello Ted,

I've just tried the 3.5 Version you posted (thanks for that). On starting it on my fedora-machine it crashes:

[helmut@netb-helmut x86Framework3.5]$ mono DemoMap.exe
WARNING: The runtime version supported by this application is unavailable.
Using default runtime: v1.1.4322

** (DemoMap.exe:2976): WARNING **: Missing method System.Windows.Forms.Application::SetCompatibleTextRenderingDefault(bool) in assembly /usr/lib/mono/gac/System.Windows.Forms/1.0.5000.0__b77a5c561934e089/System.Windows.Forms.dll, referenced in assembly /home/helmut/Downloads/x86Framework3.5/DemoMap.exe

Unhandled Exception: System.MissingMethodException: Method not found: 'System.Windows.Forms.Application.SetCompatibleTextRenderingDefault'.

Could you supply a link to the source-code, so I could try to load it in Monodevelop ...

Thanks and regards

Helmut

Nov 22, 2010 at 5:10 PM
It's the same source code. You just change the target version of all projects using a macro that you can download from the web. It changes all projects in a solution to the target framework so you can build and test more easily. In practice, I just use MSBuild with the target framework specified to produce the zip files, but I use the macro to test in 3.5 routinely since opening an element in the designer in 4.0 corrupts the resource file with 4.0.0.0 refrences everywhere that have to be set back to 2.0.0.0.

I don't think the bug you are getting this is a 3.5 issue per say. I ran DemoMap.exe on mono 2.8.1 on my windows box and it ran, so this is either an issue related to your specific version of mono, or else specifically to the linux implementation. I think the method is probably added to support compatible text rendering between 3.5 and 4.0. The old method was something like "AutoScaleMode = ScaleMode.Font" or something, but that breaks in 4.0. The question is, will removing the specified line of code break anything or will it still run without it. If it runs without it, and that lets you run in linux, then I think we have a solution, and I'd be happy to commit that modification. Just be aware that it sounds like this is generated in automatic code areas, so if you can fix with a newer version of mono, that might be the better solution since there is nothing on my end that will flag this as an error.

Ted


On Mon, Nov 22, 2010 at 8:52 AM, dimpflmoser <notifications@codeplex.com> wrote:

From: dimpflmoser

Hello Ted,

I've just tried the 3.5 Version you posted (thanks for that). On starting it on my fedora-machine it crashes:

[helmut@netb-helmut x86Framework3.5]$ mono DemoMap.exe
WARNING: The runtime version supported by this application is unavailable.
Using default runtime: v1.1.4322

** (DemoMap.exe:2976): WARNING **: Missing method System.Windows.Forms.Application::SetCompatibleTextRenderingDefault(bool) in assembly /usr/lib/mono/gac/System.Windows.Forms/1.0.5000.0__b77a5c561934e089/System.Windows.Forms.dll, referenced in assembly /home/helmut/Downloads/x86Framework3.5/DemoMap.exe

Unhandled Exception: System.MissingMethodException: Method not found: 'System.Windows.Forms.Application.SetCompatibleTextRenderingDefault'.

Could you supply a link to the source-code, so I could try to load it in Monodevelop ...

Thanks and regards

Helmut

Read the full discussion online.

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

To start a new discussion for this project, email DotSpatial@discussions.codeplex.com@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


Nov 22, 2010 at 7:03 PM

Hello Ted,

you're right - it runs well onWindows with mono 2.8.1, but on my linux-machine is only 2.67 which is the most current binary version available. So I think I'll have to wait a while ...

Thanks again

Helmut

Nov 23, 2010 at 7:48 PM
I've been working on a mono build. The XBuild in teamcity not
working, so I will need to see about creating an nant script. (xbuild
is the mono equivalent of msbuild)

The better part is the unit testing, and the redirection of the
compiling to use Mono native dll's rather than windows dll's


On Mon, Nov 22, 2010 at 11:03 AM, dimpflmoser
<notifications@codeplex.com> wrote:
> From: dimpflmoser
>
> Hello Ted,
>
> you're right - it runs well onWindows with mono 2.8.1, but on my
> linux-machine is only 2.67 which is the most current binary version
> available. So I think I'll have to wait a while ...
>
> Thanks again
>
> Helmut
>
> Read the full discussion online.
>
> To add a post to this discussion, reply to this email
> ([email removed]@discussions.codeplex.com)
>
> To start a new discussion for this project, email
> [email removed]@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