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
