Short answer: look into mine sources. It solve #1, #2 and even #3. You are welcomed to make changes and polishing, of couse.
Agreed #1 is trivial. But you'll (or atleast I did) soon discover that you need inter-project dependency analysis which MSBuild do _not_ solve. There are some MS blogs about it. btw: <msbuild-solution> could be bad name. And btw, it do not use msbuild to parse .sln files. Only .*proj files are processed with msbuild. I suggest this as temporary name, to prove its worth (in nantcontrib) and later be merged into official <solution>, so I didnt think about name too much. Good luck, Martin Aliger > -----Original Message----- > From: Mike Edenfield [mailto:[EMAIL PROTECTED] > Sent: Friday, January 20, 2006 4:56 PM > To: Martin Aliger > Cc: nant-developers@lists.sourceforge.net; > [EMAIL PROTECTED] > Subject: Re: [nant-dev] Ongoing work on MSBuild project file > formats... > > Martin Aliger wrote: > > > I dont know how much is mine work "official". Hard to > determine in > open-source projects :-) > > Mostly, I was trying to find out of there is a consensus on > how such a new task should work, before I spend any time on > it. My company is more than willing to pay me to work on the > NAnt tasks we need and submit them back to the project, but I > don't want to waste their time on work that won't meet the > project's goals. At the same time, if they're going to give > me time to do it, I'd rather spend more time doing it right > than skimp on the solution. > > I came up with three basic approaches, with varying degrees > of complexity and benefits. I've already partly implemented > #1, as apparently have a number of other people, but it seems > like a sub-optimal solution. > > 1. Create completely separate <msbuildproject> and > <solution2005> tasks that can process generic MSBuild scripts > and the new VS2005 solution format. VS2005 users could use > <msbuild file="whatever.csproj" /> or > <solution2005 file="whatever.sln" />. > > 2. Create a separate <msbuild> task that can be used for and > type of MSBuild project; add support to <solution> to > recognize the new solution format and shunt it off to > <msbuild>. Scripts currently using <solution> on a solution > file would run as-is; scripts using <solution> without a > solution file, but using a list of project files, would just not work. > > 3. Add a new ManagedProjectBase descendant, MSBuildProject, > and support for SolutionTask to recognize and create this new > type of project. > Current scripts using <solution> either way would work as-is. > > Also, if we do end up with new tasks, would those properly go > into nantcontrib first, even though they are closely related > to the existing VSNet core tasks? > > > Which link is dead? > > > > http://maliger.webpark.cz/binaries.zip. This should work. (try to > > copy/paste into yout browser if you find link broken). You'll find > > modified <solution> task and new <msbuild-solution> there, > which knows > > how to compile new vs2005 projects. Also there are 2 > implementations > > of <msbuild> (as a wrapper around msbuild.exe and via > msbuild api). Both for direct call to msbuild. > > No, this wasn't the URL I found online. This one works. > However, it turned out that writing an <msbuild> task using > the MSBuild API was so straightfoward I just went ahead and did it. > > One very nitpicky comment I would make, is that having an > <msbuild-solution> task is probably an inappropriate name. > The solution files in VS2005 aren't MSBuild files. Reading > through some of the blogs from MS's dev team indicates that > the next version of VS will use true MSBuild file formats for > their solution files, and the current solution format is > merely a stopgap measure. It might be better to reserve the > name <msbuild-solution> for a true msbuild-based solution > file, and use something else for the current format. > > >> files, but which contained dead links. There's also an > uncommitted > >> patch in the nant CVS with a similar task. > > > > What is it? uncommitted patch? (you meant not-in-distro?) > > There is one patch in the nant "patches" database that > appears to work similar to yours; submitted by B. Heath > Robinson, #1246149. I only glanced at the contents of the > ZIP file long enough to note that it's a completely new task, > not a patch to the existing SolutionTask. > > > ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
