|
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=""> 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/ /bin/website01.moduleA1.dll /moduleA1/
http://website02/ /bin/website02.dll / http://website02/moduleA2/ /bin/website02.moduleA2.dll /moduleA2/ http://website02/moduleB1/ /bin/website02.moduleB1.dll /moduleB1/
http://website03/ /bin/website03.dll / http://website03/moduleA3/ /bin/website03.moduleA3.dll /moduleA3/ http://website03/moduleC1/ /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-----
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 |
Title: Message
