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 <[email protected]>: > 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 > > > > On Mon, Dec 21, 2009 at 9:08 PM, John Simons <[email protected]> > wrote: >> 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 <[email protected]> wrote: >>> Inline >>> >>> On Mon, Dec 21, 2009 at 11:52 AM, John Simons >>> <[email protected]>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 >> >> -- >> >> 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 [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/castle-project-devel?hl=en. >> >> >> > > -- > > 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/castle-project-devel?hl=en. > > > -- 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.
