Re: [nant-dev] In case you haven't seen this yet

[Scott Hernandez]

Title: In case you haven't seen this yet

Alex,   Yeah, sounds like a good break-down.   1 and 2 sound pretty easy. It would be nice to do this in the managed world but I expect we will need to run each others binaries as external processes. We have a stub console loader that does everything an external program would need to do to in order to run a build file, from the managed world. As we are still in pre-1.0 release mode now is good time to make changes that need to.   As for a transformation between our file formats, this gets a little more hairy. We support a config file format that supplements a lot of what *could* be explicitly set in the build file via a config section of the app.config. I think we may need more than just a xslt to make it work well. There are also issues of mapping task params, and tasks themselves, from one framework to the other. This seems reasonable, but like a fairly large task. It might make sense to setup a website where this type of mapping information can be collected by the user base and a xslt file can be dynamically created based on the version of our two frameworks you are converting from/to. As NAnt is an open source project, and we will probably be releasing more often than MSBuild, it would make sense that anything MSBuild ships (or NAnt for that matter) will be stale by the time it hits the street. That is why a website that generates a build transformation is probably more useful than a static file shipped in a release. Will MSBuild provide XSDs for all types of tasks?   I expect the format of tasks will stay relatively static (in NAnt), and there are probably some simple places where we can interact and provide examples, and guidelines (for what to do, and not to do) in order to build tasks that work in both frameworks. But there will always be differences in the services that our frameworks offer to task developer. Logging, property access (build file variables), our _expression_ languages, exception propagation, and utility classes are all things that will differ from build framework to framework. It will be good to put together guideline as to what should work across our frameworks.   I'd be more than happy to (as I'm sure other active devs will be also) work on these issues, but I really need to know that legally we are not stepping into the sh*T in doing so.   Moving forward this is a clear place where we can work together and build a solution for our users that is seamless and empowering. Every step we take we keep in mind the ability and flexibility of our users. With that in mind, working together seems like a great idea.   Alex, would you be willing to have a sit-down meeting in the next few weeks to work on some of these ideas? It would be good to keep fostering these ideas of communication between the NAnt and MSBuild teams.   ----- Original Message ----- From: Alex Kipman To: Scott Hernandez ; [EMAIL PROTECTED] Sent: Monday, November 24, 2003 2:10 PM Subject: RE: [nant-dev] In case you haven't seen this yet As the MSBuild PM, do you know if the team has considered any interop scenarios with NAnt tasks or the NAnt framework. Is this something that would be in the scope of the work you would consider? If not, can you comment on the technical challenges in doing in working either way (nant->msbuild; msbuild->nant, task interop)? >>> Great question.  This is totally in the scope of the work we are considering.  I believe very strongly that we will need nant<---->msbuild interop.  In my mind this work segments into four nice manageable chunks:   ·                     An MSBuild task needs to exist in the NAnt library.  This way you can build MSBuild projects from within NAnt projects ·                     A NAnt task needs to exist in the MSBuild library.  This way you can build NAnt projects from within MSBuild projects ·                     A file format conversion tool (ala xslt) which will convert both syntaxes back and forth.   ·                     Being able to author a task such that it will run on either NAnt or MSBuild.     That's at least how we have been breaking up the problem.     Thanks, Alex Kipman ([EMAIL PROTECTED]) Program Manager Visual Studio Core Team This posting is provided "AS IS" with no warranties, and confers no rights.     From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Hernandez Sent: Wednesday, November 19, 2003 10:23 AM To: [EMAIL PROTECTED] Subject: Re: [nant-dev] In case you haven't seen this yet   Thanks for the update Alex. I didn't read the original article, but this seems like a pretty short synopsis. I'm looking forward to seeing msbuild when it gets closer to release.   As the MSBuild PM, do you know if the team has considered any interop scenarios with NAnt tasks or the NAnt framework. Is this something that would be in the scope of the work you would consider? If not, can you comment on the technical challenges in doing in working either way (nant->msbuild; msbuild->nant, task interop)? ----- Original Message ----- From: Alex Kipman To: [EMAIL PROTECTED] Sent: Tuesday, November 18, 2003 9:24 PM Subject: [nant-dev] In case you haven't seen this yet   Hello everyone, At the risk of reliving a very painful subject, I wanted to point the community to the published "chapter 2" of Brent Rectors book entitled Introducing Longhorn for Developers.  The link is here: http://msdn.microsoft.com/Longhorn/understanding/books/rector/default.aspx?pull=/library/en-us/dnintlong/html/longhornch02.asp#longhornch02_topic1 You will note Brent re-wrote the entire section about "Why not Ant/NAnt", and what you see on this link is what you will see printed on the book when it hits your local bookstore.  In other words what was printed in the PDC copy of the book will no longer be printed.  I hope you find the current text to be more precise and especially less adversarial.  Just thought you should know,    Alex Kipman ([EMAIL PROTECTED])    Program Manager    MSBuild Team This posting is provided "AS IS" with no warranties, and confers no rights.