You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Steve Loughran <st...@iseran.com> on 2003/11/03 21:14:06 UTC

Msbuild

Stefan Bodewig wrote:
> On Fri, 31 Oct 2003, Steve Loughran <st...@iseran.com> wrote:
> 
>>Stefan Bodewig wrote:
>>
>>
>>>MSBuild uses $() for its properties and @() for something else -
>>>probably Item references at first glance.
>>
>>-where is the docs for that?
> 
> 
> Follow the "official information" link in
> <http://stefanbodewig.blogger.de/stories/9155/>.
> 
> Judging from you blog, you've found it by now.  The nant-dev list is
> very interesting right now. 8-)
> 
> I've had a closer look into the docs last weekend and will talk about the
> Item and task input/output stuff later.

yes, I even have the PDC DVD set a few metres away, should I chose to 
dedicate some time to bringing it up in a vmware installation.

I must say it is the first time any project I've worked on has been 
cloned by microsoft to become a strategic offering of theirs. I also 
think they may have a better list/set model than Ant's, which doesn't 
really have anything consistent at all, just FileList, FileSet, and many 
other task-specific lists.

I do think a bit of credit to the ant and nant teams would have been 
polite -from a colleague who was at the MSBuild session, we didnt merit 
a mention. Sigh.


-Steve


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: Brent Rector on Msbuild vs Ant

Posted by Steve Loughran <st...@iseran.com>.
Stefan Bodewig wrote:
> On Wed, 05 Nov 2003, Steve Loughran <st...@iseran.com> wrote:
> 
>>Stefan Bodewig wrote:

> Oh, Latin is my third language (and I never had the opportunity to
> tell girls I was interested in what they had to say in Latin 8-).

I believe there are still some parts of switzerland and a bit of the 
Dolomites near Cortina that still speak a derivative of latin, if you 
feel like trying your luck.

>>now, they dont have to care what I say, but we do have the option of
>>pulling all .NET support from ant1.6...
> 
> 
> I don't think there is such a significant user base for them, is
> there?  You and me, but most .NET developers who are not doing
> heterogeneous builds will pick NAnt today (or VS.NET).

I probably would too, and when vs.net shipped would use that, simply 
because integration with the IDE and code you are working on makes 
sense. I encountered a fair bit of resistance in getting everyone on the 
team here to install a modern JRE so they could run Ant to build the C++ 
stuff. Some people still have issues with CppUnit too.

and that is going to be one of the hard things to change with VS.net. 
Its very-excellent debugger does bias people towards debug-based 
development, rather than writing the tests and tracking down problems by 
writing new tests. In a way, the limitations of the Java IDEs -no 
dominant tool, historically weak debuggers (better now), made us use Ant 
and JUnit because there was no way to get things working otherwise. .NET 
does have a single IDE with good debugging, so people have been able to 
struggle along with a non-scalable, non-automated process. Or as I call, 
it "edit-and-continue" programming.

If I ever get the time, I plan to use the .NET tasks with Axis to do 
better client side interop testing. This is why the <wsdlToDotnet> task 
is there. I may need <nunit> and <al> shortly too.

-steve


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: Brent Rector on Msbuild vs Ant

Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 05 Nov 2003, Steve Loughran <st...@iseran.com> wrote:
> Stefan Bodewig wrote:
>> On Tue, 04 Nov 2003, Steve Loughran <st...@iseran.com> wrote:

> Stefan. I am disappointed.

Well, I knew that DD would read my mail and simply waited for him to
wake up.  I didn't expect you to do such a great job, thanks.

> I thought it was us british citizens that were meant to be brought
> up not speaking the languages of our neighbours :(.

My closest neighbors speak Dutch and I do understand it, but wouldn't
try to speak or even write in dutch.  This is certainly not due to our
school system, I simply watched Dutch television a lot in the 70s and
80s.  And then there are those ritual shopping trips to Venlo or
Roermond, you know.

> Still, I guess English does make more sense as a second language
> than, say, Russian, to name one of the languages I was nominally
> taught.

Depending on which part of Germany you've been born in, you would have
been taught either English or Russian as your second language.  By now
English is the default, but there are schools that will let you chose
a different language.  Florian (our son who's just started school)
will be taught English starting with his third year in school - we
didn't get our second language before the fifth year when I was in
school.

Oh, Latin is my third language (and I never had the opportunity to
tell girls I was interested in what they had to say in Latin 8-).

> I think that is why they arent going to do C++ support; if you have
> to list dependencies by hand, stick to automake.

listing dependencies by hand is the biggest shortcomming of file based
dependencies IMHO.  And just think of <copy>'s overwite attribute.

>  >>What are we going to do now. I am feeling ruthless.
>
>  > Wait until it apperas in MSDN to address it?  Address it right
>  > now?

> no, we are going to our retaliation in early, as they say in
> rugby. I will send some emails to the relevant authorities.

OK, let's see.

I should use the time in which my blog is ranked first by Google when
searching for Ant and MSBuild, I guess.  I'm even on the first page
for MSBuild as the only query parameter 8-)

> now, they dont have to care what I say, but we do have the option of
> pulling all .NET support from ant1.6...

I don't think there is such a significant user base for them, is
there?  You and me, but most .NET developers who are not doing
heterogeneous builds will pick NAnt today (or VS.NET).

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: Brent Rector on Msbuild vs Ant

Posted by Gus Heck <gu...@cognition.olin.edu>.
> now, they dont have to care what I say, but we do have the option of 
> pulling all .NET support from ant1.6...we will just have to see if 
> that matters to them. It'll be an interesting test of conflict of the 
> tactical 'get .net developers today' over the strategic 'own the 
> developers forever'.
>
I think they would cheer if we took out .net support. It would give them 
another selling point for msbuild. The thing they hate most is 
competition. Leave it in and they will be more annoyed :).

-Gus



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: Brent Rector on Msbuild vs Ant

Posted by Steve Loughran <st...@iseran.com>.
Stefan Bodewig wrote:
> On Tue, 04 Nov 2003, Steve Loughran <st...@iseran.com> wrote:
> 
>>Here is the offending page from Brent's book.
> 
> 
> I stumbled over it yesterday[1] - the snippet you post - here
> <http://www.dotnetguru.org/articles/pdc2003/pdc2003v2.htm>.
> 
> As I don't speak french I've been unable to understand the context - I
> was planing to ask the author of that article to translate it for me
> and then answer it as well.

Stefan. I am disappointed. I thought it was us british citizens that 
were meant to be brought up not speaking the languages of our neighbours 
:(. Still, I guess English does make more sense as a second language 
than, say, Russian, to name one of the languages I was nominally taught.

Here goes then, bearing in mind I havent spoken french since '99 and my 
language skills there were mainly focused around safety warnings to do 
with antimatter and radiation "Danger, risque de radiation", bicicyle 
parts and telling french girls that I am very interested in what they 
have to say...


The author says that it was a 1h15 presentation about Ant. It was 
clearly apparent that MS build is a good copy of Ant and also Nant.
If the two speakers had started their talk by acknowledging that they 
supported the efforts of the NAnt community and that they participated 
in the development of the framework, they could still [equally] have 
justified their decision to completely rewrite it for the reasons listed 
below.

concerning the techicanl details, the notion of Target is the same. 
Tasks are an equally integral part of the project. The plagiarism (sorry 
to use the term, but it is clearly the case) goes up to the API in the 
naming of the tasks, and the manner of using the properties [maybe 
attributes] is absolutely identical. But where are the differences, you 
ask me? Well, the developers had the idea to add functionality that is 
not in Ant to date. This is all explained the book "Introducing 
Longhorn" that was distributed free to participants during the conference

[the bogus claims reprinted]
We leave you to form  your own opinion on the subject. The positive side 
is that an Ant developer [user?] will not be really, but also really, 
not lost with MsBuild.

[I havent been able to really translate that last sentence. I would 
guess it means that an ant user will feel at home with MSBuild]

> 
> Let me add to your comments.
> 
> 
>>1. Ant does not provide built-in target dependency analysis -a
>>requirement for a scalable build system
> 
> 
> <http://stefanbodewig.blogger.de/stories/10575/>
> 
> And your case where name mangling is more difficult than the current
> engine knows is a good point as well.  We have a similar case in
> <rmic>, where the Weblogic compiler adapter produces a different
> result from Sun's.
> 
> And then there is the case of dependencies between classes.  If
> superclass and subclass end up in different assemblies and you change
> the superclass, the naive target dependency analysis will not
> recompile the subclass.  And people will never think of doing
> something like the <depend> task as this is done by MSBuild.

no. I think that is why they arent going to do C++ support; if you have 
to list dependencies by hand, stick to automake. Oh, wait, they dont 
support that, do they.

> 
> 
>>3. Ant does not have a normalized concept of task inputs and
>>outputs; a necessity for a build system to support intra-task
>>communication.
> 
> 
> We do have references, we just don't use them as much as we could
> <http://stefanbodewig.blogger.de/stories/10636/>.
> 
> I'm trying to get my thoughts on this into a better shape and will
> have a proposal for the 1.7 timeframe.

This sounds interesting.

> 
> 
>>4. Unlike Ant, MSbuild is a secure build engine. MSBuild introduces
>>the notion of partially trusted builds, project level sandboxing and
>>task level sandboxing.
> 
> 
> I couldn't find anything about this in the public docs about MSBuild.

me neither. Which is why this smacks of a briefing rather than brent 
doing his own research.

 >>5. MSbuild has a richer extensibility model than ant.
 >
 >
 > I was laughing out loud on reading this.

yes, I thought maybe it was a typo. You dont get more extensible than 
having no schema and the complete source to play with.

 >
 >
 >>6. Ant does not have the ability to import (macro insert) parts of
 >>the project file
 >
 >
 > It is fair to say that this is true for all released versions of Ant
 > (so let's get 1.6 out of door quickly ;-).  And only if you deny
 > entities, of course.

yes, but MSBuild is a year from shipping. They should really be 
comparing msbuild to Ant1.7 release; for now 1.6 vs MSBuild beta is the 
best comparision.

 >>What are we going to do now. I am feeling ruthless.
 >
 >
 > Wait until it apperas in MSDN to address it?  Address it right now?
 > Judging from my blog's referers, people are searching for infomation
 > on MSBuild a lot ATM, so we may as well set the record straight right
 > from the beginning.

no, we are going to our retaliation in early, as they say in rugby. I 
will send some emails to the relevant authorities. One nice thing about 
MS compared to Sun is that they are very easily contacted, and usually 
pretty responsive. If they dont respond, that is when you have to worry. 
  It usually means they dont want to tell you something bad.

now, they dont have to care what I say, but we do have the option of 
pulling all .NET support from ant1.6...we will just have to see if that 
matters to them. It'll be an interesting test of conflict of the 
tactical 'get .net developers today' over the strategic 'own the 
developers forever'.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: Brent Rector on Msbuild vs Ant

Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 04 Nov 2003, Steve Loughran <st...@iseran.com> wrote:
> Here is the offending page from Brent's book.

I stumbled over it yesterday[1] - the snippet you post - here
<http://www.dotnetguru.org/articles/pdc2003/pdc2003v2.htm>.

As I don't speak french I've been unable to understand the context - I
was planing to ask the author of that article to translate it for me
and then answer it as well.

Let me add to your comments.

> 1. Ant does not provide built-in target dependency analysis -a
> requirement for a scalable build system

<http://stefanbodewig.blogger.de/stories/10575/>

And your case where name mangling is more difficult than the current
engine knows is a good point as well.  We have a similar case in
<rmic>, where the Weblogic compiler adapter produces a different
result from Sun's.

And then there is the case of dependencies between classes.  If
superclass and subclass end up in different assemblies and you change
the superclass, the naive target dependency analysis will not
recompile the subclass.  And people will never think of doing
something like the <depend> task as this is done by MSBuild.

> 3. Ant does not have a normalized concept of task inputs and
> outputs; a necessity for a build system to support intra-task
> communication.

We do have references, we just don't use them as much as we could
<http://stefanbodewig.blogger.de/stories/10636/>.

I'm trying to get my thoughts on this into a better shape and will
have a proposal for the 1.7 timeframe.

> 4. Unlike Ant, MSbuild is a secure build engine. MSBuild introduces
> the notion of partially trusted builds, project level sandboxing and
> task level sandboxing.

I couldn't find anything about this in the public docs about MSBuild.

> 5. MSbuild has a richer extensibility model than ant.

I was laughing out loud on reading this.

> 6. Ant does not have the ability to import (macro insert) parts of
> the project file

It is fair to say that this is true for all released versions of Ant
(so let's get 1.6 out of door quickly ;-).  And only if you deny
entities, of course.

> What are we going to do now. I am feeling ruthless.

Wait until it apperas in MSDN to address it?  Address it right now?
Judging from my blog's referers, people are searching for infomation
on MSBuild a lot ATM, so we may as well set the record straight right
from the beginning.

Stefan

Footnotes: 
[1]  While googling for msbuild and ant - I wanted to see why my blog
     gets so many hits 8-)


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Brent Rector on Msbuild vs Ant

Posted by Steve Loughran <st...@iseran.com>.
Here is the offending page from Brent's book. I think it will be on the 
MSDN web site before long, as it is the chapter promised this month -
http://msdn.microsoft.com/Longhorn/understanding/books/rector/default.aspx


I have added my commentary. This is the last paragraph on chapter 2, 
just after a critique of make. My comments are in brackets.

MSBuild vs Ant
===============

A similar frequently asked question is why develop a new XML-based build
system when there's an existing system called Ant? Ant is a Java, open
source build system from Apache.org that uses XML-based configuration
files. There's a .NET port called Nant from nant.sourceforge.net as
well. On the surface, MSBuild and Ant/Nant seem similar. Both tools use
XML as their project serialization format, and both tools use tasks as
their atomic unit of build operation. However, a deeper look reveals
differences in the two tools, some of which I describe here:

1. Ant does not provide built-in target dependency analysis -a
requirement for a scalable build system

[This has no impact on build files, merely effort to write new tasks. We
do leave it to tasks, but they get to implement their own logic. Having
to implement it yourself adds work to the task developers, but they get
to write task specific rules. Like, for example, <jspc> knows the name
mangling rules to go from .jsp files to valid java source files, and ftp
knows about ftp sites and time zones.]

2. Ant does not have a clear concept of a project manifest -a necessity
to develop additional tools to process the output of a build system

[Ant has a clear concept of a project manifest: the build file. This is
well-formed XML, and none of the many IDEs that use Ant have complained
yet. What Ant does not do is provide a schema as that would destroy its
extensibility model.]

3. Ant does not have a normalized concept of task inputs and outputs; a
necessity for a build system to support intra-task communication.

[we do have common data structures, like fileset, but to do piping we
may need to introduce more concepts.]

4. Unlike Ant, MSbuild is a secure build engine. MSBuild introduces the
notion of partially trusted builds, project level sandboxing and task
level sandboxing.

[Ant is a secure build engine. Most people never do this, but when Ant
runs inside Tomcat, it is sandbox mode. Other embedded uses of Ant would
be expected to use the appropriate security model. Note also that Ant
permits one to set the security permissions on code when using the
<java> task, so one can run code in a sandbox from inside Ant.]

5. MSbuild has a richer extensibility model than ant. MSBuild uses
constructs not available in Java. Examples range from the ability to
batch tasks intelligently, or to allowing custom tasks to specify
attributes as optional or required.

[Ant has a richer extensibility model than MSBuild. Ant lets third
parties add new conditions, selectors and datatypes as well as tasks.
Ant allows custom tasks to support arbitrary XML elements inside the
task. Finally, being open source (BSD license), Ant can be extended in
ways that we cannot imagine. Any part of it can be reused or changed to
meet developer needs.]

6. Ant does not have the ability to import (macro insert) parts of the
project file -a necessity to factor the build system into maintainable
reusable pieces and a fundamental requirement for enterprise build
systems.

[Ant has the ability to import (macro insert) parts of the build file
using the <import> task, which even handles target name conflicts. It
also lets you invoke ant builds in other files using <ant> and <subant>.
We also support XML entity inclusion for inserting arbitrary text]

---

There is something deeply misguided about faulting Ant for its lack of
scalability or extensiblity. Ant is intrinsically more extensible, being
open source, and its scalability is something learned over time from
being used in big projects. I can only conclude that Mr Rector's deep
look at ant didn't go beyond asking some MS marketing weasel why MSBuild
was better than [N]Ant.

If you are going to criticise ant, criticise it where it is weak, like
having inconsistent naming of attributes, no consistent failonerror
settings, and lots of list-like/set-like types with no underlying class
other than java.lang.Object. But dont pick on scalability or
extensibility, that is just picking an argument you intend to lose.

------------------

What are we going to do now. I am feeling ruthless.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: Msbuild

Posted by Steve Loughran <st...@iseran.com>.
Stefan Bodewig wrote:

> It's even worse than that.  NAnt gets some bad coverage in a Microsoft
> Press book they've distributed at PDC from what I hear.

I have this book in my hands.

It does not criticise NAnt. It criticises Ant. I will follow up with the 
details shortly.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: Msbuild

Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 04 Nov 2003, Steve Loughran <st...@iseran.com> wrote:

> Being in the depths of a C++ project, with some .NET on the fringes,
> I am deeply aware of how badly vs.net needs something like ant/nant,

NAnt's CVS version is supposed to be able to parse .sln files, don't
knoiw whether that would help with your C++ case, though.  Even
Whidbey won't use MSBuild for C++ (at least not MSBuild's format) from
what I understand from their docs.

> One thing I think they probably are very ignorant of are xUnit;

Have you picked up the TLS347.ppt as well?  In the seventh and eigth
slide (at least using OpenOffice 1.1, but who knows) they talk about
unit testing and adding unit tests to your build process.

Stefan

-- 
http://stefanbodewig.blogger.de/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: Msbuild

Posted by Steve Loughran <st...@iseran.com>.
Stefan Bodewig wrote:
> On Mon, 03 Nov 2003, Steve Loughran <st...@iseran.com> wrote:
> 
> 
>>I must say it is the first time any project I've worked on has been
>>cloned by microsoft to become a strategic offering of theirs.
> 
> 
> Yes, a very interesting experience.


Well, as David Patterson says, the hard part of CS research is getting 
your ideas adopted.

>>I also think they may have a better list/set model than Ant's, which
>>doesn't really have anything consistent at all,
> 
> 
> At the same time they don't really support nested elements in a useful
> way at all AFAICT.  You can have array type attributes, but then
> MSBuild is going to convert lists into arrays for you from what I
> understand.

> 
> I 100% agree with you that Ant needs a better List/Set model.

hmmm. What we really need is a unified list/graph model so that you can 
pass lists/sets/whatever around; fileset and the like are just 
specialised lists.


> 
> 
>>I do think a bit of credit to the ant and nant teams would have been
>>polite
> 
> 
> It's even worse than that.  NAnt gets some bad coverage in a Microsoft
> Press book they've distributed at PDC from what I hear.

Didnt hear that. A colleague was at the MSBuild conf, but he doesnt use 
ant much himself, so didnt get in with any questions like 'why is this 
different'. but he didnt hear anyone critique nant, either.

I see from the mail link you posted that the book was by brent rector. 
I've met him; he spoke at Chris Sells' Web Services DevCon last year, so 
he should have caught my talk at the same conf on using ant to build, 
deploy and test web services.

> MSBuild is closer to NAnt than to Ant (as wittnessed by their use of
> conditions on everything).  If I was naive I could think they aren't
> aware of Ant.

I know a few people there who know of ant, mostly in the Web Services 
group or the Java evangelists:

Chris Sells, Don box (still has commit rights on Apache Soap), Tim 
Ewald, Doug Purdy (douglasp.com), Keith Ballinger, Becky Dias, Lee Fisher.

Lee and Becky have copies of my book; doug purdy has even written a J# 
task (not in our CVS).  But these are a few people whose focus on 
interop gives them more exposure to the outside. I expect the core 
engineering team are busy in their offices implementing what some 
program manager tells them to do.

I remember when I was up on the site listening to a talk by David Stuve 
(now ex-MS), talking about Rotor. One of the first steps in booting 
rotor is to cross compile MS NMAKE. Given that MS NMAKE sucks, I was 
somewhat surprised, and did ask 'why didnt you use ant'?  'because it is 
in Java' was the response.

So they do know of Ant, the just dont want to acknowledge it.


Being in the depths of a C++ project, with some .NET on the fringes, I 
am deeply aware of how badly vs.net needs something like ant/nant, and 
that means tight coupling with the studio. Any attempt we made to 
duplicate C++ build stages with <cpp> failed because the engineers would 
stick in the IDE, and then the automated build would get out of sync. So 
now the build process is


project1:
-xslt the error codes into .h, .idl, .html and .mc files

project2:
-<cpp> to MIDL all the idl into the .tlb that describes the com object

project3:
-big vs.net .sln to build about 10 different projects; some lib, some 
DLL, some exe, register libraries

project4:
  -big vs.net .sln to build the cppunit tests for every component

project5:
-ant to copy .pdb and .map files somewhere sensible

project6:
  -<tlbimport><ildasM<replaceregexp><ilasm> to import and then patch the tlb

project7:
  -<csc> to compile nunit tests, <exec> to run them.

Those .sln files are trouble. You want to change a compiler option 
across 14 projects? There goes a morning. You want to tune the 
debug/release configurations? There goes a week.


One thing I think they probably are very ignorant of are xUnit; MS have 
many many testers, but they have their own proprietary solutions (just 
like MS dont use sourcesafe internally). I'd be happier to see 
integrated xunit testing with VS.net than anything else. Imagine 
importing a COM typelib and having VS.net offering to create unit tests 
for every method? Or a WSDL definition of a SOAP service? Axis can do 
that, but .NET doesnt.

It good that they have  discovered automated build processes, but better 
if testing were in there too.




> 
> Another interesting bit from nant-dev.  When asked whether Microsoft
> was holding any patents on parts of MSBuild, Alex Kipman said[1]
> 
> ,----
> | >>> This is a tricky question but I'll do my best to answer it openly
> | and honestly :).  
> | 
> | 1) Microsoft has submitted and has some outstanding patents on
> | technologies included in the MSBuild engine (core platform stuff).  
> | 
> | 2) MSBuild is written 100% in managed code and will not be obfuscated by
> | us.  With this said, as of today there are no plans to release sources
> | for MSBuild Engine stuff.  Not even as shared source. We are currently
> | debating releasing sources for our tasks and loggers, but we haven't
> | discussed license issues yet.
> `----
> 
> I assume that "core platform stuff" applies to the .NET platform at
> large and don't think that could affect Ant in any way.

yup.


> Footnotes: 
> [1]  http://sourceforge.net/mailarchive/forum.php?thread_id=3399692&forum_id=863
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Re: Msbuild

Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 03 Nov 2003, Steve Loughran <st...@iseran.com> wrote:

> I must say it is the first time any project I've worked on has been
> cloned by microsoft to become a strategic offering of theirs.

Yes, a very interesting experience.

> I also think they may have a better list/set model than Ant's, which
> doesn't really have anything consistent at all,

At the same time they don't really support nested elements in a useful
way at all AFAICT.  You can have array type attributes, but then
MSBuild is going to convert lists into arrays for you from what I
understand.

I 100% agree with you that Ant needs a better List/Set model.

> I do think a bit of credit to the ant and nant teams would have been
> polite

It's even worse than that.  NAnt gets some bad coverage in a Microsoft
Press book they've distributed at PDC from what I hear.

Alex Kipman (Program Manager Visual Studio Core Team, according to his
sig) apologizes for this on nant-dev, but who's going to read it?

> -from a colleague who was at the MSBuild session, we didnt merit a
> mention. Sigh.

MSBuild is closer to NAnt than to Ant (as wittnessed by their use of
conditions on everything).  If I was naive I could think they aren't
aware of Ant.

Another interesting bit from nant-dev.  When asked whether Microsoft
was holding any patents on parts of MSBuild, Alex Kipman said[1]

,----
| >>> This is a tricky question but I'll do my best to answer it openly
| and honestly :).  
| 
| 1) Microsoft has submitted and has some outstanding patents on
| technologies included in the MSBuild engine (core platform stuff).  
| 
| 2) MSBuild is written 100% in managed code and will not be obfuscated by
| us.  With this said, as of today there are no plans to release sources
| for MSBuild Engine stuff.  Not even as shared source. We are currently
| debating releasing sources for our tasks and loggers, but we haven't
| discussed license issues yet.
`----

I assume that "core platform stuff" applies to the .NET platform at
large and don't think that could affect Ant in any way.

Stefan

Footnotes: 
[1]  http://sourceforge.net/mailarchive/forum.php?thread_id=3399692&forum_id=863


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org