Retiring NAnt

[Roelof Blom]

Hi,

Isn't it time to retire NAnt and just simply build projects with MSBuild? The benefits being:

• having one build technology,
• sln/csproj (references and sources) are 'automatically' in sync with what's on the disk,
• just open a sln and it compiles without running NAnt first(we create a little exe that creates/updates AssemblyInfo on the PreBuildEvent).

SharpDevelop, being a pretty big project, is entirely being build by MSBuild so it should be possible for us also, especially now that the projects are split up.

On Mono there's xbuild, and from what I read here it's very much up to the task on Mono 2.6.

I am currently investigating, but want to check if there's anything I am grossly overlooking i.e. what NAnt does and MSBuild can't. For extending MSBuild I am using http://msbuildtasks.tigris.org/

-- Roelof.

[Krzysztof Koźmic]

how about ditching XML altogether and using PSake instead?

--

You received this message because you are subscribed to the Google Groups "Castle Project Development List" group.
To post to this group, send email to castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.

[Daniel Hölbling]

+1 for psake.
I'm using it on .less and it works perfectly.

20.12.2009 15:24 schrieb am "Krzysztof Koźmic" <krzyszto...@gmail.com>:

how about ditching XML altogether and using PSake instead?

On 2009-12-20 15:17, Roelof Blom wrote: > > Hi, > > Isn't it time to retire NAnt and just simply b...

-- You received this message because you are subscribed to the Google Groups "Castle Project Develo...

[Ken Egozi]

psake require install on every client machine, and will defeat our "checkout and click to build" policy

There are lots of other options, that do not require install, but a checkout-able dlls, such as the BOO, or IronRuby based builders

If anyone is going to invest time in this, these would be better alternatives.

and on that notion, basically it should be up to every project, right? assuming a common convention of the ClickToBuild and the output folders are kept across

2009/12/20 Krzysztof Koźmic <krzyszto...@gmail.com>

--
Ken Egozi.
http://www.kenegozi.com/blog
http://www.delver.com
http://www.musicglue.com
http://www.castleproject.org
http://www.idcc.co.il - הכנס הקהילתי הראשון למפתחי דוטנט - בואו בהמוניכם

[Krzysztof Koźmic]

IIRC PSake itself does not require install.

You're right though - it requires PowerShell to be installed, and there are quirks with permissions and script signing.

Perhaps Bake would be better alternative, although IIRC it was pretty much abandoned.
IF I had time thought, I'd be interested in getting it up to date with Boo development. It would be a perfect occasion
also for me to play with the language, which I like more and more as I read Ayende's book.

[Ken Egozi]

require PS, that was my point. It's not default on most machines yet, especially not on the people who has the problems with Checkout-And-Build

2009/12/20 Krzysztof Koźmic <krzyszto...@gmail.com>

[Daniel Hölbling]

We could also just go with Rake. I've seen people packing Ruby with their repo to make it runnable without prereqs. 

greetings Daniel

[Ken Egozi]

two orthogonal question:

1. would the same packed ruby work on Mono? and on OSX/Linux? or maybe the audience is small enough to have them use a local installation of rake?

2. would it be better to pack IRuby instead? we'd get all of Rake's goodness, with added benefit of executing .NET code for custom steps (migrating from Nant would be easier that way). and 

[G. Richard Bellamy]

Whatever we do needs to work with horn as well, correct?

[Roelof Blom]

Hi,

Before you all shoot off in different directions, I was just testing the water. Seems it's pretty cold :-) But given all the replies it's a pretty hot subject.

I fail to see the clear advantages of introducing yet another build system, even one being as elegant as psake. All our projects use sln/csproj and it's easiest to build upon that with MSBuild, IMHO. I agree that if we need scripting psake would be a very nice tool for it.

About all the other fancy alternatives: what will they bring us, besides being "not-XML", that NAnt doesn't? Isn't that just porting the current scripts to another platform?

Rake IMO, is a pretty alien thing on .NET and all the scripts for .NET that I've seen delegate building to MSBuild by simply shelling out. Uncool.

Bake is dead. Ayende's not even using it for his own projects.

IronRuby based builders - ???

One of the key points is ClickToBuild (or DX as Krzysztof put it nicely), so not requiring anything besides VS is something to strive for.

My objective was to simplify the current build, bringing everything to one build technology. And that technology is MSBuild on .NET, like it or not.

-- Roelof.

[Krzysztof Koźmic]

Roelof

well put, and I can't say I don't agree with most of what you said.
With the nice advantage of MsBuild, being - it's part of .NET, my
suggestion about considering alternatives was driven by concern, that
XML based solutions are pretty heavyweight.
That being said, the total effort to migrate, and then extend and
maintain the build to MsBuild may be higher than for alternatives like
Bake, or PSake.

I agree with Ken about PSake. I forgot for a moment that PowerShell is
not standard part of just any box, and with quirks it brings, I'm now
rather against using it.
About Bake - I haven't used it, but knowing what Boo can do, it feels it
could be pretty good choice actually. It's bin deployable, so we're
still good for ClickToBuild solution.
It's not maintained anymore - well -is that really a problem? So isn't
NAnt AFAIC? PSake itself is like 200LOC. If it does provide what we need
I'm good with using it. And we can always fork it.
All in all, this might prove to be easier to work with than MsBuild, and
all I want is for us to consider all viable options and to make an
informed choice.

cheers,

Krzysztof

[G. Richard Bellamy]

And what about mono?

One of the driving factors behind using NAnt was that it was cross-platform.

-rb

[Symon Rottem]

xbuild works for mono on Linux, but only for projects, not solutions and has some other limitations.  It is possible to construct an MSBuild script that compiles projects which can make it easier to work with dependency registration through VS, however.

Cheers,

Symon.


Symon Rottem
http://blog.symbiotic-development.com

[Roelof Blom]

On Mono 2.6 xbuild is advertised to support solution files.

What do you mean with your last sentence?

[hammett]

That would be a great improvement! +1

Also consider the fact that dev10 brings several improvements for msbuild, an improved object model and they also aimed to have everything that make files have. I have a friend in that team, so let me know if he needs bashing :-)

[John Simons]

+1 for a msbuild only solution
If we are changing the build I think we should aim for a build that
does not require a "How to Build.txt" or "ClickToBuild.cmd".

Also, in regards to updating the AssemblyInfo automatically, do we
really need to worry about doing this on the clients machines?
The reason I'm asking is because TeamCity v5.1 has plan to do this as
part of the build - http://youtrack.jetbrains.net/issue/TW-6637

This way we would not have to add any customisation to the msbuild at
all :)

Cheers
John

On Dec 21, 7:50 am, hammett <hamm...@gmail.com> wrote:
> That would be a great improvement! +1
>
> Also consider the fact that dev10 brings several improvements for msbuild,
> an improved object model and they also aimed to have everything that make
> files have. I have a friend in that team, so let me know if he needs bashing
> :-)
>

[Mauricio Scheffer]

There's also Phantom, a new Boo build system, also DSL-based:
http://github.com/JeremySkinner/Phantom

About xbuild, I had problems last time I wanted to use it (2 months
ago, for GitSharp), it was kind of unreliable. In the end I went with
nant. Granted, this was before the 2.6 release and I haven't used it
ever since, it seems to have improved lately.

Abut msbuild 2010 new features, we wouldn't be able to use them until
xbuild caught up with it.

IronRuby + irake is another possibility. Actually Krzysztof asked
about this a couple of months ago (
http://stackoverflow.com/questions/1443792/bin-deploy-rake-and-ironruby
), Bracket seems to simplify xcopy deployment of IronRuby.

Cheers,
Mauricio

On Dec 20, 5:59 pm, John Simons <johnsimons...@yahoo.com.au> wrote:
> +1 for a msbuild only solution
> If we are changing the build I think we should aim for a build that
> does not require a "How to Build.txt" or "ClickToBuild.cmd".
>
> Also, in regards to updating the AssemblyInfo automatically, do we
> really need to worry about doing this on the clients machines?
> The reason I'm asking is because TeamCity v5.1 has plan to do this as

> part of the build -http://youtrack.jetbrains.net/issue/TW-6637

[Simon Cropp]

+1 for MSBuild

more people understand how it works and VS is our primary dev tool.

[John Simons]

Here are a few things that the current NAnt script does:
1. Pulls version from svn and autogens AssemblyInfos
2. Runs tests via nunit
3. Compiles + packages files into a zip file to be ready to be
uploaded to sf.net
4. Runs NCover and NDepend
5. Supports passing of parameters to configure tests (eg database
tests are passed NHibernate settings like string connection)

How to handle these in MSBuild:
1. TeamCity 5.1 or custom msbuild task
2. Use Resharper locally, and use TeamCity on the build server
3. Can be done in TC
4. TC v5 now supports NCover out of the box and NDepends can be set to
run after a build in TC
5. I was thinking of setting up "Environment Variables" in TC.

Cheers
John

On Dec 21, 1:17 am, Roelof Blom <roelof.b...@gmail.com> wrote:
> Hi,
>
> Isn't it time to retire NAnt and just simply build projects with MSBuild?
> The benefits being:
>

>    - having one build technology,
>    - sln/csproj (references and sources) are 'automatically' in sync with

>    what's on the disk,

>    - just open a sln and it compiles without running NAnt first(we create a

>    little exe that creates/updates AssemblyInfo on the PreBuildEvent).
>
> SharpDevelop, being a pretty big project, is entirely being build by MSBuild
> so it should be possible for us also, especially now that the projects are
> split up.
>

> On Mono there's xbuild <http://www.mono-project.com/Microsoft.Build>, and
> from what I read
> here<http://ankitjain.org/blog/2009/10/02/xbuild-and-mono-2-6p1/>it's

[Ken Egozi]

Lets separate *compilation* from *build*

whichever build tool we choose, the  compilation part should work through the csproj files, probably by calling MSBuild/xBuild on them.

The rest of the things, scriptable things, ( run tests, tun NCover/NDepend, package to zip) should be a *lot* easier to bring from nant and then maintain, to any script-based build system (be it PSake, Rake or whatever) than in custom MSBuild files.

>
> -- Roelof.

--

You received this message because you are subscribed to the Google Groups "Castle Project Development List" group.
To post to this group, send email to castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.

[Julian Birch]

My 2 pence:

• I've never seen a csproj-based open source solution that didn't have reference issues.
• But I may have a solution to that... ;-)
• Not only do we not want to assume PS, we don't want to assume Visual Studio/Resharper. 

Personally, I really like rake, but setting up ruby on windows is a pain in the neck.  If (big if) we could package it on IronRuby, it might be workable.  Even if it's no longer under active development, it's not like it's missing features we need.

 

J

 

2009/12/21 Ken Egozi <ego...@gmail.com>

[John Simons]

Roelof initial post was about replacing nant with msbuild, now we have
suggestions to use psake, rake, ironruby, phantom, my question is why.
What is wrong with nant? It seems to be doing the job, or am I missing
something?

I know it is not perfect, and is not a dsl or no xml, but it does the
job.

>sln/csproj (references and sources) are 'automatically' in sync with
> what's on the disk,

Yes that is true, but does it really take that long to keep them in
sync? And in my case I use VS to do updates to the source code so
everything is in sync anyway.

> just open a sln and it compiles without running NAnt first(we create a
> little exe that creates/updates AssemblyInfo on the PreBuildEvent).

Most of the projects if not all are now able to be opened from VS and
built by pressing F5 without having to run any prior nant scripts, if
you know of any project that is broken please either fix it or let us
know and I'll fix it.

I do like the idea of being able to build everything with msbuild.
I do think it is reasonable to assume that 90% of our user base is
using VS and they much rather build our projects from inside VS than
any other way.

All the build solutions that have been mentioned so far sound pretty
good, but what is the benefit to the end user? Any solution that is
not double click the sln file and press F5, in my opinion is not worth
the effort.

Cheers
John

On Dec 21, 8:45 pm, Julian Birch <julian.bi...@gmail.com> wrote:
> My 2 pence:
>
>    - I've never seen a csproj-based open source solution that didn't have
>    reference issues.
>    - But I may have a solution to that... ;-)
>    - Not only do we not want to assume PS, we don't want to assume Visual

>    Studio/Resharper.
>
> Personally, I really like rake, but setting up ruby on windows is a pain in
> the neck.  If (big if) we could package it on IronRuby, it might be
> workable.  Even if it's no longer under active development, it's not like
> it's missing features we need.
>
> J
>

> 2009/12/21 Ken Egozi <egoz...@gmail.com>

>
> > Lets separate *compilation* from *build*
>
> > whichever build tool we choose, the  compilation part should work through
> > the csproj files, probably by calling MSBuild/xBuild on them.
>
> > The rest of the things, scriptable things, ( run tests, tun NCover/NDepend,
> > package to zip) should be a *lot* easier to bring from nant and then
> > maintain, to any script-based build system (be it PSake, Rake or whatever)
> > than in custom MSBuild files.
>

> >> castle-project-d...@googlegroups.com<castle-project-devel%2Bunsu...@googlegroups.com>

> >> .
> >> For more options, visit this group at
> >>http://groups.google.com/group/castle-project-devel?hl=en.
>
> > --
> > Ken Egozi.
> >http://www.kenegozi.com/blog
> >http://www.delver.com
> >http://www.musicglue.com
> >http://www.castleproject.org

> >http://www.idcc.co.il- הכנס הקהילתי הראשון למפתחי דוטנט - בואו בהמוניכם

>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Castle Project Development List" group.
>
> > To post to this group, send email to castle-pro...@googlegroups.com
> > .

> > To unsubscribe from this group, send email to

> > castle-project-d...@googlegroups.com<castle-project-devel%2Bunsu...@googlegroups.com>

[Markus Ewald]

On 20.12.2009 18:03, Krzysztof Koźmic wrote:

It's not maintained anymore - well -is that really a problem? So isn't 
NAnt AFAIC?

NAnt continues to be actively developed. They make a new release every other month on average (okay, the latest is six months old now :P)

Their problem is that they haven't made a /stable/ release for like two years now. This doesn't give people the confidence that the project is well and healthy, even if the nightly builds appear rock-stable.

On 21.12.2009 10:45, Julian Birch wrote:
My 2 pence:

• I've never seen a csproj-based open source solution that didn't have reference issues.

What put me off MSBuild was that Microsoft's build scripts always go down all referenced projects.

Imagine you had this:

    Utility.csproj
    FooLibrary.csproj (uses Utility)
    BarLibrary.csproj (uses Bar)

Now go into each csproj's directory and type msbuild <project> /t:Rebuild /p:Configuration=Release
What happens?

    - Utility will be cleaned and built
    - Utility will be cleaned and built again, then FooLibrary
    - Utility will be cleaned and build yet again, then BarLibrary

Not only was Utility built three times, if you have any kind of automatic build version incrementing going on, FooLibrary and BarLibrary will now be compiled with different versions of the Utility project. So /t:Rebuild is completely useless. With /t:Build, it only checks each referenced project recursively on whether it's up to date a few dozen times.

There sure is some way around it (Visual Studio can to a "Rebuild All" just fine), but MSBuild wasn't exactly easy to understand so personally I just used NAnt. I'm following this discussion with interest, maybe I should take a look at Bake, too :)

-Markus-

[Simon Cropp]

I know. We can do it in perl. Oh wait its not 1995.

But seriously there are many options for compiling and building a
project but perhaps a wiki of some kind would be a better place to
capture requirements and detail what solutions meet those
requirements.

And a few points on choices (and sorry if i am stating the obvious)
-avoid choosing a dying technology
-avoid absorbing a project and customising it. I think the castle
project already has a large enough scope
-choose something that is a balance of simplicity for the consumer and
simplicity for the castle developer. And on this point i err on the
side of the consumer.
-no matter what your choose ensure that there is a VS sln and you can
hit F5 to run it. VS is the one common denominator. User who want to
evaluate, debug or contribute to castle (or part there of) will first
try to do so with VS. The wont read the README.txt they wont run the
"ClickToBuild.cmd" they will find the first file that ends with ".sln"
and double click it.
-VS on its own will never be the only part of the solution. It is
simply not mature enough and does not have the feature required to
build a complex project.

Hope i have helped and keep up the great work :)

[Roelof Blom]

Inline

On Mon, Dec 21, 2009 at 11:52 AM, John Simons <johnsi...@yahoo.com.au> wrote:

Roelof initial post was about replacing nant with msbuild, now we have
suggestions to use psake, rake, ironruby, phantom, my question is why.
What is wrong with nant? It seems to be doing the job, or am I missing
something?

I know it is not perfect, and is not a dsl or no xml, but it does the
job.

>sln/csproj (references and sources) are 'automatically' in sync with
>  what's on the disk,

Yes that is true, but does it really take that long to keep them in
sync? And in my case I use VS to do updates to the source code so
everything is in sync anyway.

It's not hard, it's just friction.

One more drawback of the current build system is that it picks up every .cs file.

By using .csproj you can more easily partition the build for .NET and Silverlight,

by creating a .csproj for the platform you want to build on.

 

> just open a sln and it compiles without running NAnt first(we create a
>   little exe that creates/updates AssemblyInfo on the PreBuildEvent).

Most of the projects if not all are now able to be opened from VS and
built by pressing F5 without having to run any prior nant scripts, if
you know of any project that is broken please either fix it or let us
know and I'll fix it.

Just did a fresh checkout of DP, opened the sln and it did not compile because AssemblyInfo.cs is missing.

Same goes for IOC, and I suspect the same is true for all other projects.

I do like the idea of being able to build everything with msbuild.
I do think it is reasonable to  assume that 90% of our user base is
using VS and they much rather build our projects from inside VS than
any other way.

And I like to extend this to the command line.

 

All the build solutions that have been mentioned so far sound pretty
good, but what is the benefit to the end user? Any solution that is
not double click the sln file and press F5, in my opinion is not worth
the effort.

Exactly. 

Cheers
John

[Julian Birch]

2009/12/21 Roelof Blom roelo...@gmail.com

>sln/csproj (references and sources) are 'automatically' in sync with
>  what's on the disk,

Yes that is true, but does it really take that long to keep them in
sync? And in my case I use VS to do updates to the source code so
everything is in sync anyway.

It's not hard, it's just friction.

One more drawback of the current build system is that it picks up every .cs file.

By using .csproj you can more easily partition the build for .NET and Silverlight,

by creating a .csproj for the platform you want to build on.

 

I'd actually say this was an advantage of the current build system.  Personally, I dislike the fact that I need a separate csproj file for silverlight at all.  In any event, the #if !SILVERLIGHT directive is pretty explicit and arguably more workable.

 

J

[Roelof Blom]

You don't *have* to use different .csprojs, it's just a possibility. I happen to like the fact that this allows you to customize the build for that platform inside VS.

--

You received this message because you are subscribed to the Google Groups "Castle Project Development List" group.
To post to this group, send email to castle-pro...@googlegroups.com.

To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.

[Markus Ewald]

On 21.12.2009 12:47, Roelof Blom wrote:

On Mon, Dec 21, 2009 at 12:28 PM, Julian Birch <julian...@gmail.com> wrote:

2009/12/21 Roelof Blom roelo...@gmail.com

>sln/csproj (references and sources) are 'automatically' in sync with
>  what's on the disk,

Yes that is true, but does it really take that long to keep them in
sync? And in my case I use VS to do updates to the source code so
everything is in sync anyway.

It's not hard, it's just friction.

One more drawback of the current build system is that it picks up every .cs file.

By using .csproj you can more easily partition the build for .NET and Silverlight,

by creating a .csproj for the platform you want to build on.

 

I'd actually say this was an advantage of the current build system.  Personally, I dislike the fact that I need a separate csproj file for silverlight at all.  In any event, the #if !SILVERLIGHT directive is pretty explicit and arguably more workable.

 

You don't *have* to use different .csprojs, it's just a possibility. I happen to like the fact that this allows you to customize the build for that platform inside VS.

I've made the same experience as Julian. It doesn't work out so well to cherry-pick files in VS depending on the target platform.

Always using all files and having #if !SILVERLIGHT and so on was much easier and you can update different .csprojs simply by including all files in the project's directory.

-Markus-

[John Simons]

Fixed Core, DP and IOC, these should now be able to be opened and
built in VS.

On Dec 21, 10:19 pm, Roelof Blom <roelof.b...@gmail.com> wrote:
> Inline
>

[Rafael Teixeira]

Still migrating myself some projects with hundreds of csprojs+vcprojs,
from nant to msbuild, my conclusions so far are:

1) unless you can live with "monster" solution files (and being
really/really slow to load those) that build all the VS projects, (I
couldn't) you may instead need to have a slim master solution, with
just a fake csproj that recurse through the solutions that already
exist, and lose any niceties VS presents for project types it natively
knows. I didn't check if VS2010, have improved the situation.
2) in the other side, it is really quite simple to tweak build files
(csproj) to do many other steps, currently done on the Nant. The
problem is getting used to the non-sequentially-imperative model it
exposes (as it tries to solve dependencies as automatically as
possible).
3) Even creating custom tasks is quite easy and can make the build
files a lot more concise and understandable.

So I'm +1 for MSBuild

PS.: To avoid multiple rebuilds of partial projects referenced many
times, the only formula I could find IS to have the Monster Solution,
but just to use it via msbuild that loads it and builds its a lot
faster than VS. The only problem I could not solve it to call VS
(devenv.exe) in recursive fashion to build sub-solutions that contain
some vcprojs (native C), as those aren't well supported by msbuild up
to VS2008/msbuild 3.5.

my two cents

Rafael "Monoman" Teixeira
---------------------------------------
"To be creative means to be in love with life. You can be creative
only if you love life enough that you want to enhance its beauty, you
want to bring a little more music to it, a little more poetry to it, a
little more dance to it."
Osho

> --
>
> You received this message because you are subscribed to the Google Groups "Castle Project Development List" group.
> To post to this group, send email to castle-pro...@googlegroups.com.

> To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.

[Markus Zywitza]

Looking at all those problems presented with MSBuild here, I'm asking
myself why we should make this extra work. In this discussion I read
about the following problems with the current solution:

-You can't open a solution and hit F5 to build it. Instead you have to
click "ClickToBuild.bat".

The ClickToBuild.bat shows that we have a build system that works. If
I get a source without any build files or "howtobuild.txt", just a
simple sln, I'm getting suspicious whether this is really a competent
developer's project. Its simply not professional as it places the
friction on the users' side of the equation. For an example, look at
the Lucene.Net build instructions here:
https://svn.apache.org/repos/asf/incubator/lucene.net/tags/Lucene.Net_2_4_0/src/BUILD.txt

-You can't build in VS before you run a NAnt script.

We could add empty AssemblyInfo.cs files and replace them by NAnt when
building. We would have to handle ignoring those changes in
committing, though. Perhaps NAnt can make a backup copy before and
restore the original file after the build

-Both the .build and .csproj files need to be maintained.

That's right, but it only requires work when adding references to a
project, not when only files are added, updated or removed. If it is a
problem, we could considers compiling using MSBuild with .csproj files
and doing the other work in NAnt

On the plus side of NAnt, there is the following:
-Loading projects in VS isn't delayed.
-Works on both NET and MONO on Windows and Linux.
-Has an XML schema that supports editing with VS. I still can't
understand why MS created an unschemaable XML language for MSBuild.

All in all, for me it is -1 for retiring NAnt.

-Markus

2009/12/23 Rafael Teixeira <mon...@gmail.com>:

[Roelof Blom]

On Sun, Dec 27, 2009 at 3:01 PM, Markus Zywitza <markus....@gmail.com> wrote:

Looking at all those problems presented with MSBuild here, I'm asking
myself why we should make this extra work. In this discussion I read
about the following problems with the current solution:

Up untill now everybody seems to present only problems with MSBuild. Perhaps because it doesn't have very good rep, or perhaps it's because we're too locked in to look at what it has to offer, especially where it's headed in v4.

Please read 'What's New in MSBuild 4.0' at http://msdn.microsoft.com/en-us/library/ee240939(VS.100).aspx, especially the ability to create inline tasks and multi-targeting are very welcome.

 

-You can't open a solution and hit F5 to build it. Instead you have to
click "ClickToBuild.bat".

The ClickToBuild.bat shows that we have a build system that works. If
I get a source without any build files or "howtobuild.txt", just a
simple sln, I'm getting suspicious whether this is really a competent
developer's project. Its simply not professional as it places the
friction on the users' side of the equation. For an example, look at
the Lucene.Net build instructions here:
https://svn.apache.org/repos/asf/incubator/lucene.net/tags/Lucene.Net_2_4_0/src/BUILD.txt

ClickToBuild.cmd can very easily kick off MSBuild.

 

-You can't build in VS before you run a NAnt script.

We could add empty AssemblyInfo.cs files and replace them by NAnt when
building. We would have to handle ignoring those changes in
committing, though. Perhaps NAnt can make a backup copy before and
restore the original file after the build

Sounds complicated.

 

-Both the .build and .csproj files need to be maintained.

That's right, but it only requires work when adding references to a
project, not when only files are added, updated or removed. If it is a
problem, we could considers compiling using MSBuild with .csproj files
and doing the other work in NAnt

This is what we use at work, and I dislike it more and more. Personally I find using two different build tools a bit cumbersome.

 

On the plus side of NAnt, there is the following:
-Loading projects in VS isn't delayed.

?

 

-Works on both NET and MONO on Windows and Linux.

True. But that's why xbuild was created by the Mono project.

 

-Has an XML schema that supports editing with VS. I still can't
understand why MS created an unschemaable XML language for MSBuild.

FWIW, you'll get full schema support for MSBuild and NAnt with ReSharper.

All in all, for me it is -1 for retiring NAnt.

-1 is not really helping things, is it? And this thread wasn't even [meant as a] a vote.

I would like to give at least a try, before we start shooting -1's at it.

Cheers,

Roelof.

[John Simons]

Inline

On Dec 28, 3:15 am, Roelof Blom <roelof.b...@gmail.com> wrote:

> On Sun, Dec 27, 2009 at 3:01 PM, Markus Zywitza <markus.zywi...@gmail.com>wrote:
>
> > Looking at all those problems presented with MSBuild here, I'm asking
> > myself why we should make this extra work. In this discussion I read
> > about the following problems with the current solution:
>
> Up untill now everybody seems to present only problems with MSBuild. Perhaps
> because it doesn't have very good rep, or perhaps it's because we're too
> locked in to look at what it has to offer, especially where it's headed in
> v4.
>

> Please read 'What's New in MSBuild 4.0' athttp://msdn.microsoft.com/en-us/library/ee240939(VS.100).aspx, especially

> the ability to create inline tasks and multi-targeting are very welcome.
>
>

The new stuff for v4 sounds good :)

>
> > -You can't open a solution and hit F5 to build it. Instead you have to
> > click "ClickToBuild.bat".
>
> > The ClickToBuild.bat shows that we have a build system that works. If
> > I get a source without any build files or "howtobuild.txt", just a
> > simple sln, I'm getting suspicious whether this is really a competent
> > developer's project. Its simply not professional as it places the
> > friction on the users' side of the equation. For an example, look at
> > the Lucene.Net build instructions here:
>

> >https://svn.apache.org/repos/asf/incubator/lucene.net/tags/Lucene.Net...

>
> ClickToBuild.cmd can very easily kick off MSBuild.
>

I actually disagree, if I see a project with "howtobuild.txt" and
ClickToBuild.cmd I see a complex build system that forces me to build
their way, not the way I want.

>
>
> > -You can't build in VS before you run a NAnt script.
>
> > We could add empty AssemblyInfo.cs files and replace them by NAnt when
> > building. We would have to handle ignoring those changes in
> > committing, though. Perhaps NAnt can make a backup copy before and
> > restore the original file after the build
>
> Sounds complicated.
>

I've said this before and I stress it again, you can build without
running NAnt first. To fix problems like this just do not check in
AssemblyInfos, and voila the project now builds fine in VS. Have a
look at Core, DP2, Windsor, EmailSender, TemplateEngine, ....

>
>
> > -Both the .build and .csproj files need to be maintained.
>
> > That's right, but it only requires work when adding references to a
> > project, not when only files are added, updated or removed. If it is a
> > problem, we could considers compiling using MSBuild with .csproj files
> > and doing the other work in NAnt
>
> This is what we use at work, and I dislike it more and more. Personally I
> find using two different build tools a bit cumbersome.
>

Not if we complete get rid of Nant, then we only have one file to
maintain (csproj ) and that is done through VS anyway.

>
>
> > On the plus side of NAnt, there is the following:
> > -Loading projects in VS isn't delayed.
>
> ?

Why would I load a project in either VS or Nant if all I want is to
compile? For that I go to the build server and get the binaries from
there. And if I'm working on the project 9 out of 10 I already have VS
opened so it is a lot simpler to just press F5.

>
> > -Works on both NET and MONO on Windows and Linux.
>
> True. But that's why xbuild was created by the Mono project.

>
> > -Has an XML schema that supports editing with VS. I still can't
> > understand why MS created an unschemaable XML language for MSBuild.
>
> FWIW, you'll get full schema support for MSBuild and NAnt with ReSharper.

csproj + sln files are also maintained via VS without any extra tools
or xsds.

>
> > All in all, for me it is -1 for retiring NAnt.
>
> -1 is not really helping things, is it? And this thread wasn't even [meant
> as a] a vote.
>
> I would like to give at least a try, before we start shooting -1's at it.

Ok, so start with a small project, how about ActiveRecordIntegration
facility, at the moment doesn't have anyone as the leader.

>
> Cheers,
> Roelof.

[Roelof Blom]

Sorry for the late reaction, I was being held up by other things.

I will start (some time this week) with the ARIntegration facility, as you suggested. It's nice and small and has enough dependencies as too not make it trivial.

-- Roelof.

[Roelof Blom]

Committed first cut. Check it out and let me know what you like/not like about it.

[Jonathon Rossi]

Roelof you are committing without a user name, I thought Henry plugged this hole?

--
Jono

[John Simons]

-Now when I open the sln file I get a security warning dialog (see attachment), this could be confusing for users.

-Opened the solution and no clean compile from VS, because AssemblyInfo.cs is included in the project but doesn't exist on disk!

-Removed AssemblyInfo.cs from proj file, I now have 2 errors:
Error    1    The "AllowPartiallyTrustedCallers" parameter is not supported by the "AssemblyInfo" task. Verify the parameter exists on the task, and it is a settable public instance property.    Castle.Facilities.ActiveRecordIntegration-vs2008
Error    2    The "AssemblyInfo" task could not be initialized with its input parameters.     Castle.Facilities.ActiveRecordIntegration-vs2008

-Double clicked "ClicktoBuild.cmd" got Build Failed:
This script builds the project in Release configuration

C:\Projects\Castle\Facilities\ActiveRecordIntegration\trunk>C:\Windows\microsoft
.net\framework\v3.5\msbuild /m "C:\Projects\Castle\Facilities\ActiveRecordIntegr
ation\trunk\buildscripts\Build.proj" /t:CleanAll;BuildProject /p:Configuration=R
elease /p:Platform=AnyCPU
Microsoft (R) Build Engine Version 3.5.30729.4926
[Microsoft .NET Framework, Version 2.0.50727.4927]
Copyright (C) Microsoft Corporation 2007. All rights reserved.

Build started 6/01/2010 7:18:21 AM.
     1>Project "C:\Projects\Castle\Facilities\ActiveRecordIntegration\trunk\bui
       ldscripts\Build.proj" on node 0 (CleanAll;BuildProject target(s)).
     1>C:\Projects\Castle\Facilities\ActiveRecordIntegration\trunk\buildscripts
       \Build.proj(338,3): error : Solution file "*Undefined*" not found.
     1>Done Building Project "C:\Projects\Castle\Facilities\ActiveRecordIntegra
       tion\trunk\buildscripts\Build.proj" (CleanAll;BuildProject target(s)) --
        FAILED.

Build FAILED.

       "C:\Projects\Castle\Facilities\ActiveRecordIntegration\trunk\buildscript
       s\Build.proj" (CleanAll;BuildProject target) (1) ->
       (_GetProjectsFromSolution target) ->
         C:\Projects\Castle\Facilities\ActiveRecordIntegration\trunk\buildscrip
       ts\Build.proj(338,3): error : Solution file "*Undefined*" not found.

    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:00.24
**************************************************************
The binaries can be found in the build folder.
**************************************************************
Press any key to continue . . .

-Tried "Package.cmd", it also failed :(

Cheers
John

---

From: Roelof Blom <roelo...@gmail.com>
To: castle-pro...@googlegroups.com
Sent: Tue, 5 January, 2010 11:49:45 PM
Subject: Re: Retiring NAnt

---

See what's on at the movies in your area. Find out now.

[Roelof Blom]

Thanks for trying John.

Your problems were caused by the fact that I committed an incorrect version of MSBuild.Community.Tasks.dll, this is now corrected in svn. Can you svn up (or clean checkout) and try again?

About the (annoying) security warning: you'll get this because the .csproj is modified. See also this article in the MSBuild docs: http://msdn.microsoft.com/en-us/library/ms228217.aspx

ATM I don't see a way around this. Perhaps you noticed but if you click 'Load project normally' and uncheck the checkbox you will not be asked again (for this project).

There's some info floating on the web, for instance http://blogs.microsoft.co.il/blogs/davids/archive/2009/05/18/security-warning-for-lt-project-name-gt-dialog-box.aspx

-- Roelof.

[hammett]

You get the same warning for several MS samples released through different channels. I dont think this is something new to users.

On Tue, Jan 5, 2010 at 12:53 PM, Roelof Blom <roelo...@gmail.com> wrote:

ATM I don't see a way around this. Perhaps you noticed but if you click 'Load project normally' and uncheck the checkbox you will not be asked again (for this project).

--
Cheers,
hammett
http://hammett.castleproject.org/

[John Simons]

Done a clean checkout and...

-Now when I open the sln file I get a security warning dialog (see
attachment), this could be confusing for users.

This may need to be documented on the website with why it appears
and how to get rid of it, for our junior users.

-Opened the solution and no clean compile from VS, because
AssemblyInfo.cs is included in the project but doesn't exist on disk!

To solve this problem just exclude AssemblyInfo.cs from project.

-Removed AssemblyInfo.cs from proj file, I now have 1 error and 1
warning:
Warning 1 The "SvnVersion" task failed unexpectedly.
System.Exception: Could not find svn.exe. Looked in PATH locations
and various common folders inside Program Files.
at MSBuild.Community.Tasks.Subversion.SvnClient.FindToolPath(String
toolName)
at
MSBuild.Community.Tasks.Subversion.SvnVersion.GenerateFullPathToTool()
at Microsoft.Build.Utilities.ToolTask.ComputePathToTool()
at Microsoft.Build.Utilities.ToolTask.Execute()
at MSBuild.Community.Tasks.Subversion.SvnVersion.Execute()
at Microsoft.Build.BuildEngine.TaskEngine.ExecuteInstantiatedTask
(EngineProxy engineProxy, ItemBucket bucket, TaskExecutionMode
howToExecuteTask, ITask task, Boolean& taskResult)
Castle.Facilities.ActiveRecordIntegration-vs2008
Error 2 "!" is an invalid value for the "UseLastCommittedRevision"
parameter of the "SvnVersion" task. The "UseLastCommittedRevision"
parameter is of type "System.Boolean".
Castle.Facilities.ActiveRecordIntegration-vs2008

-Double clicked "ClicktoBuild.cmd"
same error as before

Cheers
John

On Jan 6, 9:18 am, hammett <hamm...@gmail.com> wrote:
> You get the same warning for several MS samples released through different
> channels. I dont think this is something new to users.
>

[Roelof Blom]

Can you please try again, on a fresh checkout?

[John Simons]

Same as before :(
Where is MSBuild.Community.Tasks.Subversion looking for svn.exe? I use
TortoiseSVN!

On Jan 6, 10:11 am, Roelof Blom <roelof.b...@gmail.com> wrote:
> Can you please try again, on a fresh checkout?
>

> > castle-project-d...@googlegroups.com<castle-project-devel%2Bunsu...@googlegroups.com>

[Courtney Shrock]

tortoisesvn doesn't include svn.exe last time I checked -- you need a
separate install. I have Slik Subversion.

[John Simons]

It is all working now, well mostly :)

A few observations:
- The build folder, I was expecting it to create a "build" folder
under "trunk", but instead it created a "bin" folder under "src"
- I ran the "package.cmd" and it mostly worked except the unit tests,
I think the reason the unittests failed is because I didn't specify
where my database is, how do I do that? In nant I could pass the
following params:
-D:ar.connection.connection_string.1="server=mysqlt;User
ID=blah;Password=password;database=castle_test1;" -
D:ar.dialect=NHibernate.Dialect.MsSql2000Dialect -
D:ar.connection.driver_class=NHibernate.Driver.SqlClientDriver

Apart from that is looking good, very good.
You should try it against TC.

Cheers
John

[Roelof Blom]

Thanks for your feedback, John.

It now creates the binaries in the build folder, for package and ClickToBuild.

There is no support yet for specifying which database to use (so it defaults to what is set in App.config).

You can run package without running the tests like this: package /p:TestRunner_Enabled=false. See Castle.Common.Targets for all properties that control the build.

On a different note regarding running database tests: how about changing the defaults to run them against an in-memory SQLite database?

-- Roelof.

To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.

[Markus Zywitza]

2010/1/6 Roelof Blom <roelo...@gmail.com>:

> On a different note regarding running database tests: how about changing the
> defaults to run them against an in-memory SQLite database?
> -- Roelof.

All new tests in AR use InMemoryTesting. But this requires more than
simply setting a new configuration because in this case, the database
is destroyed directly after commiting the DDL.

A possible solutuion is to use a filebased SQLite DB located in a
temporary directory. I'll have a look at this the next days.

-Markus

[Roelof Blom]

Mind if I port that new stuff from AR to the facility?

[SimoneB]

I'm a bit late to the discussion, and sorry if I throw in yet another
tool, but has anyone thought about a mature tool like Maven? I though
about it because of the new structure of the projects and the binary
dependencies stuff, which as far ad I know Maven handles extremely
well.

On Jan 6, 1:31 pm, Roelof Blom <roelof.b...@gmail.com> wrote:
> Mind if I port that new stuff from AR to the facility?
>

> On Wed, Jan 6, 2010 at 1:08 PM, Markus Zywitza <markus.zywi...@gmail.com>wrote:
>
>
>
> > 2010/1/6 Roelof Blom <roelof.b...@gmail.com>:

> > > On a different note regarding running database tests: how about changing
> > the
> > > defaults to run them against an in-memory SQLite database?
> > > -- Roelof.
>
> > All new tests in AR use InMemoryTesting. But this requires more than
> > simply setting a new configuration because in this case, the database
> > is destroyed directly after commiting the DDL.
>
> > A possible solutuion is to use a filebased SQLite DB located in a
> > temporary directory. I'll have a look at this the next days.
>
> > -Markus
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Castle Project Development List" group.
> > To post to this group, send email to castle-pro...@googlegroups.com
> > .
> > To unsubscribe from this group, send email to

> > castle-project-d...@googlegroups.com<castle-project-devel%2Bun subs...@googlegroups.com>

[Roelof Blom]

I've worked with Maven (on a Java project) for the past 2 months, and liked what it can do.

But how would it work in a .NET environment? Apart from the fact there are no Maven .NET repositories for resolving dependencies, how would it know how to build .NET or Silverlight sources?

My guess is that the hornget project is meant to be .NET's maven.

-- Roelof.

To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.

[SimoneB]

I personally never used Maven but are you sure it can handle Java
projects only? And how hard would it be to set up a dependencies
repository for Castle?
Although hornget is a step forward it's probably not able to be
considered the .NET Maven.

> > > > castle-project-d...@googlegroups.com<castle-project-devel%2Bun subs...@googlegroups.com><castle-project-devel%2Bun

[Markus Zywitza]

Only in the respect of being thankful ;-)

-Markus

2010/1/6 Roelof Blom <roelo...@gmail.com>:

[Roelof Blom]

You're welcome.

[Roelof Blom]

It's building on TC now :-)

http://www.castleproject.org:8090/viewType.html?tab=buildTypeStatusDiv&buildTypeId=bt87

To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.

[John Simons]

Markus and Roelof,

Regarding using sqlite in-memory, have tried it before about 1.5
months ago. I actually think that is the way to go, no dependencies on
a physical database server.

I converted AR and NHFaclitity, I didn't actually tried ARFacility,
anyway, the results were good except for distributed transactions
across 2 dbs, those tests didn't work.
I had to use a temp sqllite db to run all the tests, the in-memory one
has too many limitations.
The NHFaclitity I got it to run with 2 tests failing, the AR can't
really remember but pretty much anything to do with distributed
transactions across 2 dbs failed.
Didn't tried to run it against linux mono.
So my conclusion was, it can be done as long we don't run distributed
transactions unittests.

Cheers
John

On Jan 6, 11:31 pm, Roelof Blom <roelof.b...@gmail.com> wrote:
> Mind if I port that new stuff from AR to the facility?
>

> On Wed, Jan 6, 2010 at 1:08 PM, Markus Zywitza <markus.zywi...@gmail.com>wrote:
>
> > 2010/1/6 Roelof Blom <roelof.b...@gmail.com>:

> > > On a different note regarding running database tests: how about changing
> > the
> > > defaults to run them against an in-memory SQLite database?
> > > -- Roelof.
>
> > All new tests in AR use InMemoryTesting. But this requires more than
> > simply setting a new configuration because in this case, the database
> > is destroyed directly after commiting the DDL.
>
> > A possible solutuion is to use a filebased SQLite DB located in a
> > temporary directory. I'll have a look at this the next days.
>
> > -Markus
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Castle Project Development List" group.
> > To post to this group, send email to castle-pro...@googlegroups.com
> > .
> > To unsubscribe from this group, send email to

> > castle-project-d...@googlegroups.com<castle-project-devel%2Bunsu...@googlegroups.com>

[James Curran]

On Wed, Jan 6, 2010 at 3:31 PM, John Simons <johnsi...@yahoo.com.au> wrote:
> Regarding using sqlite in-memory, have tried it before about 1.5
> months ago. I actually think that is the way to go, no dependencies on
> a physical database server.
>

If we can convert the AR unittests to that, that would be great
news. The current DB requirements are what is preventing me from
adding two (and possible three) machines to the build farm.

--
Truth,
James

[Roelof Blom]

Latest ARIntegration is building with in-memory tests, no problems at all there.

To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.

[John Simons]

That's good news.

In regards to have conditional references in csproj to reference
either System.Data.SQLite.DLL x86 vs System.Data.SQLite.DLL x64, you
don't need to do it.
All you need is to set the platform setting of the Test project to be
"x86" (change it from default "Any CPU") you then can reference the
x86 version of System.Data.SQLite.DLL on a 64bit OS and compile + run
the tests without any problems.
See http://www.brianpeek.com/blog/archive/2007/11/13/x64-development-with-net.aspx

Cheers
John

On Jan 7, 7:59 am, Roelof Blom <roelof.b...@gmail.com> wrote:
> Latest ARIntegration is building with in-memory tests, no problems at all
> there.
>

> > <castle-project-devel%2Bunsu...@googlegroups.com<castle-project-devel%252Buns...@googlegroups.com>

[John Simons]

I've just opened the ARFacility solution in VS and the Test project
references is showing 2 System.Data.SQLite.DLL!
And if I try to run the unit tests via resharper it complains that it
can't find System.Data.SQLite.DLL.

On Jan 7, 9:27 am, John Simons <johnsimons...@yahoo.com.au> wrote:
> That's good news.
>
> In regards to have conditional references in csproj to reference
> either System.Data.SQLite.DLL x86 vs System.Data.SQLite.DLL x64, you
> don't need to do it.
> All you need is to set the platform setting of the Test project to be
> "x86" (change it from default "Any CPU") you then can reference the
> x86 version of System.Data.SQLite.DLL on a 64bit OS and compile + run
> the tests without any problems.

> Seehttp://www.brianpeek.com/blog/archive/2007/11/13/x64-development-with...

[Daniel Hölbling]

SqlLite in-memory databases have this nasty habit of only existing for exactly one session.

I ran into some problems when testing stuff that spanned across two sessions so I had to even regenerate the schema for every session.

Sure there are no tests that depend on more than one session for schema creation + test execution?

greetings Daniel

To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.

[John Simons]

That is the reason when I had a go at making AR + NHFacility run
unittest only on sqllite I used a temp sqlite db file.

On Jan 7, 10:26 am, Daniel Hölbling <hoelblin...@gmail.com> wrote:
> SqlLite in-memory databases have this nasty habit of only existing for
> exactly one session.
> I ran into some problems when testing stuff that spanned across two sessions
> so I had to even regenerate the schema for every session.
> Sure there are no tests that depend on more than one session for schema
> creation + test execution?
>
> greetings Daniel
>

> > > > > <castle-project-devel%2Bunsu...@googlegroups.com<castle-project-devel%252Buns...@googlegroups.com>
> > <castle-project-devel%252Buns...@googlegroups.com<castle-project-devel%25252Bun...@googlegroups.com>

[Roelof Blom]

Thanks for the tip, works like a charm!

To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.

[John Simons]

@Roelof,
Users have found your new scripts!
See http://groups.google.com/group/castle-project-users/browse_thread/thread/89136075c84e18e2

Cheers
John

On Jan 8, 2:19 am, Roelof Blom <roelof.b...@gmail.com> wrote:
> Thanks for the tip, works like a charm!
>

> On Wed, Jan 6, 2010 at 11:27 PM, John Simons <johnsimons...@yahoo.com.au>wrote:
>
> > That's good news.
>
> > In regards to have conditional references in csproj to reference
> > either System.Data.SQLite.DLL x86 vs System.Data.SQLite.DLL x64, you
> > don't need to do it.
> > All you need is to set the platform setting of the Test project to be
> > "x86" (change it from default "Any CPU") you then can reference the
> > x86 version of System.Data.SQLite.DLL on a 64bit OS and compile + run
> > the tests without any problems.
> > See

> >http://www.brianpeek.com/blog/archive/2007/11/13/x64-development-with...

> > > > <castle-project-devel%2Bunsu...@googlegroups.com<castle-project-devel%252Buns...@googlegroups.com>
> > <castle-project-devel%252Buns...@googlegroups.com<castle-project-devel%25252Bun...@googlegroups.com>

[Roelof Blom]

Great! People trying to build the project themselves better read the dev list ;-)

To unsubscribe from this group, send email to castle-project-d...@googlegroups.com.