Cool! Looking forward to that being in a stable release. Or is it something that snuck into 0.8.3 that I missed?
(I've been awol from paying attention to the cvs list, did my file comparison patch for <if /> make it? (I rely on it quite heavily at the moment.) > -----Original Message----- > From: Gert Driesen [mailto:[EMAIL PROTECTED] > Sent: Friday, November 14, 2003 2:13 AM > To: David Reed; [EMAIL PROTECTED] > Subject: Re: [Nant-users] Question: Build compiling web project that is > referenced as virtu al directory. > > Just a small hint : the <solution> task no longer requires IIS to build > ASP.NET projects as you can now use a <webmap> to map project url's to > file > paths : > > <solution solutionfile="test.sln" configuration="release"> > <webmap> > <map url="http://localhost/A/A.csproj" > path="c:\inetpub\wwwroot\A\A.csproj" /> > </webmap> > </solution> > > Gert > > ----- Original Message ----- > From: "David Reed" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, November 14, 2003 5:43 AM > Subject: RE: [Nant-users] Question: Build compiling web project that is > referenced as virtu al directory. > > > Eric, > > > > Best practices? Dunno. How about working practices instead? :) I > don't know how complex your environment is, but I've got 102 different > projects/assemblies for three different production websites in VSS > monitored by Draco on a single build server and built by NAnt scripts. > And it's only going to get worse in the next six weeks... We really > didn't have any choice but to adopt what M$ calls the "Multi-Solution > Model" for team development. See > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/h > tml/tdlg_rm.asp for details. > > > > I have *not* been able to make the <solution/> task (or devenv.exe from > the command line) work for me because it requires IIS to be setup for > each website differently -- and when Draco's threads began to step on > each other while trying to build different websites' projects > concurrently on the same IIS server, it got oogly. Really, really > oogly. > > > > I can't imagine why IIS is necessary to build an assembly from source > for any reason (even for an ASP.NET project), so the utility of even > messing around with trying to rewire IIS for each "virtual directory" > eludes me. Hence we're using the CSC task to compile the assembly for > each module and then copy the resulting binaries to the proper locations > on the integration server. [The only irritation is that some "similar" > namespaces clash because CSC doesn't have the same compiler hints > available to it that devenv.exe does, which occasionally breaks a build > until the full class path from the root namespace is typed out for the > offending reference.] This also has the added benefit of *not* > requiring that VS.NET be installed on the build server -- just the .NET > SDK for NAnt to be happy. > > > > I'll skip the eight stored procedure projects that repop the integration > dbs, four content projects and the 34 library assembly projects to focus > on the web application modules. The web modules are organized into > three different websites, sort of like this (only a lot more of them): > > > > URL Assembly Path > ASPX Path > > http://website01/ /bin/website01.dll > / > > http://website01/moduleA1/ <http://website01/moduleA/> > /bin/website01.moduleA1.dll /moduleA1/ > > > > http://website02/ /bin/website02.dll > / > > http://website02/moduleA2/ <http://website02/moduleA/> > /bin/website02.moduleA2.dll /moduleA2/ > > http://website02/moduleB1/ <http://website02/moduleB/> > /bin/website02.moduleB1.dll /moduleB1/ > > > > http://website03/ /bin/website03.dll > / > > http://website03/moduleA3/ <http://website03/moduleA/> > /bin/website03.moduleA3.dll /moduleA3/ > > http://website03/moduleC1/ <http://website03/moduleC/> > /bin/website03.moduleC1.dll /moduleC1/ > > > > The modules aren't "virtual directories" (aka separate applications in > IIS)... the assemblies for each website are installed in the root /bin/ > folder, because the each share one web.config, one application cache > space and the security for each module of the website is managed by one > global.asax (and it's easier that way for xcopy deployment -- one place > to drop binaries for all modules). > > > > This organization gives us the ability to deploy one module at a time > without having to rebuild any others unless absolutely necessary, and > still segment the ASPX content logically in folders the way projects are > developed in a sandbox environment --> each module is stored in VSS as a > separate solution and a BuildEvents macro in VS.NET copies the > assemblies up-level into the root /bin/ folder and grabs the appropriate > ocpy of the unit-test config file from a central location at build time > (before the NUnitAddin runs the tests) on the developer's workstation. > > > > I have one master build script that *all* the web applications share; > Draco just passes in the various parameters that define the differences > between them at build time and NAnt does its magic using <csc /> and > <copy />. > > > > My spidey sense tells me that I've wandered off-topic, so I'll stop now > and summarize my opinion --> Avoid doing anything that requires IIS > configuration to be involved in your continuous integration build > process. That's only way to keep your hair and blood pressure both > down. > > > > > > > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of COTTER Eric > F > Sent: Thursday, November 13, 2003 6:40 PM > To: '[EMAIL PROTECTED]' > Subject: [Nant-users] Question: Build compiling web project that is > referenced as virtu al directory. > > > > I'm looking for best practices here. > > > > I have a web application that currently is checked out from source > control "VSS" and is integrated into IIS 6.0. > > > > I have been poking around at the builds files for Nant....CruiseControl > and Draco. And it appears that the majority are compiling web files > from a folder as opposed to the live instance running on IIS. I can > further qualify that as to saying that the solution file points to a > folder and not a virtual directory. > > > > I can't get my virtual directory code to compile. I'm assuming it's the > cached pages or the worker process has a handle on the assemblies. > > > > So what I'm asking is what is the best way to do this.... > > > > Thanks > > > > Eric ------------------------------------------------------- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ Nant-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-users