Using xbuild With DoL

[Xangis]

xbuild is a newish project intended to be the the Mono equivalent of msbuild and is supposed to let you build .csproj and .sln files natively on Linux/MacOS/UNIX.

I tried building Dawn of Light with version 0.1 of xbuild (the Mono 2.4.2.3 version) and some things would build and some wouldn't. I haven't tried anything from the mono betas (2.6.x) yet, but xbuild is supposed to be a lot better there.

I did have to make some changes to .csproj files in order to make it not complain about missing files. Here's what I had to do:

1. Changed the post-build step in DOLConfig.csproj so that there are separate copy commands for Windows and non-Windows systems.
2. Changed DOLDatabase.csproj so that the case of the included ID Generator code file matched the case of the file on disk (IDGenerator.cs --> IdGenerator.cs) .
3. Changed about 150 filenames where the case of the directory/file didn't match the actual directory/file name (i.e. PlayerCommands --> playercommands).

I've attached the patches to this message. I tested them on Windows and they had no impact on the build process. It would be great if someone would be willing to include them in the trunk.

Here are the results I get with xbuild 0.1 and mono 2.4.2.3:

DOLDatabase: Builds fine (with patch).
DOLBase: Builds fine (no changes needed).
DOLServer: Does not build ("Target named 'Build' not found in the project.") I'm pretty sure this is a bug/shortcoming of the current version of xbuild.
DOLConfig: Builds fine (with patch).
GameServerScripts: Builds fine (no changes needed).
GameServer: Builds fine (with patch).

* Note: For GameServer.csproj I did have to comment out the code in realmabilities/effects/rr5/SelflessDevotionEffect.cs due to this error that I don't know DoL well enough to resolve (I didn't include that change in the patches):

Code: Select all

realmabilities/effects/rr5/SelflessDevotionEffect.cs(51,111):   error CS1502:  The best overloaded method match for `System.Collections.Generic.Dictionary<DOL.GS.eProperty,int>.Dictionary(System.Collections.Generic.IEqualityComparer<DOL.GS.eProperty>)' has some invalid arguments
realmabilities/effects/rr5/SelflessDevotionEffect.cs(51,111):   error CS1503:  Argument `#1' cannot convert `DOL.GS.eProperty' expression to type `System.Collections.Generic.IEqualityComparer<DOL.GS.eProperty>'

Building the 'Dawn of Light.sln' directly turned up a lot more errors (missing references, etc.), but as I understand it, xbuild support for solution files isn't as far along as .csproj file support.

[Tolakram]

We do NOT support mono. It's missing many of the .net 3.X features we use.

[Graveen]

Can you run MoMa against Dawn of Light project, please ?

Although i'm not against creating a branch in SVN for mono compatibility patchs - if someone is really interested in maintaining this - , as Tola mentionned, we use some features that are not in the mono implementation. I don't see them in 2.6.4.

So i think it is really prematurate to spend time in converting msbuild xml files to xbuild

Good luck !

[Xangis]

Actually this patch doesn't affect the Windows build, so it'd do no harm in trunk.

As far as I knew the only thing missing in Mono was ReaderWriterLockSlim, which could be worked around... then I looked up this MoMa you mentioned.

I submitted a report to the Mono team. Here's a screenshot of everything it found. Obviously DOLConfig.exe isn't important for running a server, but there are other things that it found:

http://basternae.org/images/DOL_MoMa_05_27_2010.png

DoL shouldn't have to support Mono. Mono should support DoL. It doesn't look like they're too far off though...

[Graveen]

yes, ReaderWriterSlimLock(), and a Platform invoke in DOLBase.

RWSL() was an huge improvement, that could anyway easily be preprocessed with #if mono (or similar command).

The key point to understand is exactly what you mention and notice : we don't really want to be stuck to a special version of the framework due to mono support; but of course if some code allows both windows and linux platform, we 'll be happy to include it even if we don't officially support it !

[Xangis]

I tried using the version of xbuild that comes with mono 2.6.x and it does build the whole solution once the filename case and post-build copy command changes (if windows xcopy else cp) are made.

Of course, it dies at runtime with NotImplementedExceptions. I think I'll try copying the build over to a Windows box and see if it runs. (normally I build with Visual Studio then copy over to a Linux box to run because any IDE that isn't Visual Studio just isn't worth it)

[Tolakram]

any IDE that isn't Visual Studio just isn't worth it

Don't get him started ....

[Graveen]

SharpDevelop largely worths a visual Studio express edition.

Seems you are lucky because i don't have time to demonstrate you this fact, but everyone agrees with me here !

[Graveen]

well i'm forced to do it -

pros, compared to VC# express
- subversion direct integration
- like not express VS versions, vb, vc#, iron python, in the same ide
- embedded code converters from/to VB.NET C# IRONPYTHON etc...
- entirely in wpf
- native fxcop, stylecop support
- like real VS versions, multi target and multi project options (not limited to debug, release)
- WiX support
- Native code profiler
- Native unit tests support
- Native code coverage
-excellent debugguer
- db browser with report addin - bah it's not crystal report but you have a working reporting tool
- extensible via addins
- bindings availables for c++ (experimental), php (never used tbh)
- open source project - feel free to re-use the framework to your own projects !
- xml visual explorer
- localized in many languages
- DEFAULT TAB SUPPORT
- powerful refactoring, code metrics
- powerful code generator (accessors, properties, class designer...)
- object browser allowing you to instance objects on the fly for tests
- integrated documentation
- and standard VS interfaces: winform designer, wpf designer, document outline, class explorer project explorer, property pad etc etc etc...
- and more - SD4 is one more time in GSoC and this project is really boosted by it

cons, related to VC# express
- Do not support Ado.net wizard - kids, get out of this software !
- no edit and continue - kids, get out of this software !
- no click once support

[Xangis]

Sure SharpDevelop has its advantages, but not entirely a fair comparison, because, well, does anyone actually use the Express version of Visual Studio?

[rdsandersjr]

All of the legit people who cannot afford the pro version of Visual Studio (aka people who don't download illegal software). Then the majority of them use SharpDevelop =)

[Graveen]

Sure SharpDevelop has its advantages, but not entirely a fair comparison, because, well, does anyone actually use the Express version of Visual Studio?

Visual Studio basic does not include the necessary plugin to unit tests, code coverage, SVC integration, profiling tool, code helpers, P/Invoke wizard, Reflector / StyleCop / FxCop integrated, etc... Basically SD is focused on a less "corporate" scope of tools, meaning you can have features than need you to buy an expensive (but often far better) add-on - in example resharper.
This is exactly where i find it better than VS - it allows the access to modern tools directly into the IDE.

But i agree, this is not Visual Studio which is a top level ide. Another very important part for me is the licensing. SD is opensource and it is important for me yay, finally gimp vs photoshop debate is not so far.

To answer your last point, i think there are far more users of express edition than classic visual studio. Not really in the scope of experienced devs/students, which could benefits of VS from their job or via students/msdnaa but on theses forums, most are downloading express because we recommend it.

hehe

[Xangis]

OK, fair enough. If I had to take the free route I'd go with SharpDevelop.

My original comment was actually because I run Ubuntu Server with no GUI and as powerful as the GNU toolset is, editing code with commandline tools (vi/pico) isn't very fun compared to a modern IDE.