ASP.NET, source safe and promotion levels

[Jon Paul Jones]

For some time now, I have been looking for a build system for ASP.NET that
will merge the file based ease of deployment of classic ASP with the type
saftey and prebuilt nature of ASP.NET with codebehind. The team that I work
on manages several web sites and we have many different projects (not VS
projects) going on in each site simultaneously. Each of these projects may
have different deployment schedules. In a classis ASP world this was
(mostly) not a problem because you could work on one file and push out the
changes to that one file only, not affecting other parts of the site. In the
ASP.NET world with codebehind, changes can not be put out individual as
easily due to having to build the system as a whole.

Has anyone found a solution for this type of scenario? What I had been
thinking about doing was to use labels in source safe to "promote" files.
When a file was ready to move to the next level (like from development to
testing) the individual files that needed to be moved to this new
environment would be labeled as "test". Then, a customized build process
(probably using NANT) would get the files with the "test" label and build
the system. There might be more than one set of changes (i.e. project (again
not VS project)) that had a label of "test" at any given time. When a
particualr set of changes has finished the testing phase, the files that are
part of the change set would be labeled "stage" and then another build
process would take the "stage" files and build the system to go to the
staging server. These changes would then be retested on the staging server
and then copied to production at night. After the copy, all files with a
"stage" label would be labeled with a "prod xx/xx/xxx" label to give a
unique label for that production build.

Does anyone do anything like this? Is there any reason this would not work?
Is there a better way?

The only problem I can think of with this is that it might not be pratical
to use NANT's "solution" tag to read in the VS.NET solution and project
files. This is because you would need to be able to promote the solution and
project files and these would be in contention and might have changes that
did not need to be promoted with your change set. I have not looked in to
this fully yet, but I'm guessing that a NANT build script would need to be
created and maintained for both test and staging environments. These scripts
would need to include references, default imports and other settings to
support the current files being built for that environment.

If someone knows of a better way or has some insight, please let me know.

Thanks...

[Scott Allen]

Hi Jon:

So if I read this correctly - you'll be deploying only the changed ASPX files
between builds?

I prefer to have the entire ASP.NET application built and deployed as a whole.
I have a build engine that will apply a label to all the files in the source
repository needed for the project, then pull files by the newly applied label
(the label is typically just a product name and build number, like FOO.4567).
The projects are built and then everything is packaged up for easy deployment
to a test server.

The advantage is I can look at a build that is deployed in test or production
and easily recreate the exact set of files used to put the software together.
All of this was put together before the rise of Nant. I've thought of moving
to Nant but I think at this point I'll wait for MSBuild to arrive this year.

--
Scott
http://www.OdeToCode.com/blogs/scott/

For some time now, I have been looking for a build system for ASP.NET
that will merge the file based ease of deployment of classic ASP with
the type saftey and prebuilt nature of ASP.NET with codebehind. The
team that I work on manages several web sites and we have many
different projects (not VS projects) going on in each site
simultaneously. Each of these projects may have different deployment
schedules. In a classis ASP world this was (mostly) not a problem
because you could work on one file and push out the changes to that
one file only, not affecting other parts of the site. In the ASP.NET
world with codebehind, changes can not be put out individual as easily
due to having to build the system as a whole.

Has anyone found a solution for this type of scenario? What I had been
thinking about doing was to use labels in source safe to "promote"
files. When a file was ready to move to the next level (like from
development to testing) the individual files that needed to be moved
to this new environment would be labeled as "test". Then, a customized
build process (probably using NANT) would get the files with the
"test" label and build the system. There might be more than one set of
changes (i.e. project (again not VS project)) that had a label of
"test" at any given time. When a particualr set of changes has
finished the testing phase, the files that are part of the change set
would be labeled "stage" and then another build process would take the
"stage" files and build the system to go to the staging server. These
changes would then be retested on the staging server and then copied
to production at night. After the copy, all files with a "stage" label
would be labeled with a "prod xx/xx/xxx" label to give a unique label
for that production build.

Does anyone do anything like this? Is there any reason this would not
work? Is there a better way?

The only problem I can think of with this is that it might not be
pratical to use NANT's "solution" tag to read in the VS.NET solution
and project files. This is because you would need to be able to
promote the solution and project files and these would be in
contention and might have changes that did not need to be promoted
with your change set. I have not looked in to this fully yet, but I'm
guessing that a NANT build script would need to be created and
maintained for both test and staging environments. These scripts would
need to include references, default imports and other settings to
support the current files being built for that environment.

If someone knows of a better way or has some insight, please let me
know.

Thanks...

[Jon Paul Jones]

No, I was thinking that the web project would always be deployed as a whole,
but that individual files (.aspx, .vb, .cs) could be promoted individually
to be included in the next build. I was probably going to label all the
sources that were at a particualr build level with a unique build number
like you are talking about. Like I would label everything that currently
has a "test" label with a new "test some_build_numb er" label then get these
files and do the build.

The main thing I am trying to acomplish with this is to be able to build the
files that are ready to be built for a particular point in the application
development lifecycle. If there are files in testing but are not ready for
production, I do not want them built in the production (or in our case
"staging") build. If two files have changed and have been promoted to
(labeled as) "test", I want to then be able to promote maybe just one of
these files to be built in the "staging" build. Does that make since?

If your build script does this type of build, could you possibly post it or
email it to me? If you can't I understand but I would like to see how
someone else does this. I'm not wanting to wait for MSBuild since that is
several months off. Plus, I'm not sure that MSBuild by itself will be able
to do what I want. Team System might be able to handle this though.
"Scott Allen" <sc***@nospam.O deToCode.com> wrote in message
news:53******** *************@m snews.microsoft .com...

Hi Jon:

So if I read this correctly - you'll be deploying only the changed ASPX files between builds?

I prefer to have the entire ASP.NET application built and deployed as a whole. I have a build engine that will apply a label to all the files in the source repository needed for the project, then pull files by the newly applied label (the label is typically just a product name and build number, like FOO.4567). The projects are built and then everything is packaged up for easy deployment to a test server.

The advantage is I can look at a build that is deployed in test or production and easily recreate the exact set of files used to put the software together. All of this was put together before the rise of Nant. I've thought of moving to Nant but I think at this point I'll wait for MSBuild to arrive this year.
--
Scott
http://www.OdeToCode.com/blogs/scott/

For some time now, I have been looking for a build system for ASP.NET
that will merge the file based ease of deployment of classic ASP with
the type saftey and prebuilt nature of ASP.NET with codebehind. The
team that I work on manages several web sites and we have many
different projects (not VS projects) going on in each site
simultaneously. Each of these projects may have different deployment
schedules. In a classis ASP world this was (mostly) not a problem
because you could work on one file and push out the changes to that
one file only, not affecting other parts of the site. In the ASP.NET
world with codebehind, changes can not be put out individual as easily
due to having to build the system as a whole.

Has anyone found a solution for this type of scenario? What I had been
thinking about doing was to use labels in source safe to "promote"
files. When a file was ready to move to the next level (like from
development to testing) the individual files that needed to be moved
to this new environment would be labeled as "test". Then, a customized
build process (probably using NANT) would get the files with the
"test" label and build the system. There might be more than one set of
changes (i.e. project (again not VS project)) that had a label of
"test" at any given time. When a particualr set of changes has
finished the testing phase, the files that are part of the change set
would be labeled "stage" and then another build process would take the
"stage" files and build the system to go to the staging server. These
changes would then be retested on the staging server and then copied
to production at night. After the copy, all files with a "stage" label
would be labeled with a "prod xx/xx/xxx" label to give a unique label
for that production build.

Does anyone do anything like this? Is there any reason this would not
work? Is there a better way?

The only problem I can think of with this is that it might not be
pratical to use NANT's "solution" tag to read in the VS.NET solution
and project files. This is because you would need to be able to
promote the solution and project files and these would be in
contention and might have changes that did not need to be promoted
with your change set. I have not looked in to this fully yet, but I'm
guessing that a NANT build script would need to be created and
maintained for both test and staging environments. These scripts would
need to include references, default imports and other settings to
support the current files being built for that environment.

If someone knows of a better way or has some insight, please let me
know.

Thanks...

[Scott Allen]

I might be able to take some relavent pieces and share them.

Another place to look, if you use Source Safe, is at this article:
http://msdn.microsoft.com/library/de...ml/tdlg_rm.asp
There are some script snippets to drive VSS.

--
Scott
http://www.OdeToCode.com/blogs/scott/

No, I was thinking that the web project would always be deployed as a
whole, but that individual files (.aspx, .vb, .cs) could be promoted
individually to be included in the next build. I was probably going
to label all the sources that were at a particualr build level with a
unique build number like you are talking about. Like I would label
everything that currently has a "test" label with a new "test
some_build_numb er" label then get these files and do the build.

The main thing I am trying to acomplish with this is to be able to
build the files that are ready to be built for a particular point in
the application development lifecycle. If there are files in testing
but are not ready for production, I do not want them built in the
production (or in our case "staging") build. If two files have
changed and have been promoted to (labeled as) "test", I want to then
be able to promote maybe just one of these files to be built in the
"staging" build. Does that make since?

If your build script does this type of build, could you possibly post
it or email it to me? If you can't I understand but I would like to
see how someone else does this. I'm not wanting to wait for MSBuild
since that is several months off. Plus, I'm not sure that MSBuild by
itself will be able to do what I want. Team System might be able to
handle this though.

"Scott Allen" <sc***@nospam.O deToCode.com> wrote in message
news:53******** *************@m snews.microsoft .com...

Hi Jon:

So if I read this correctly - you'll be deploying only the changed
ASPX

files

between builds?

I prefer to have the entire ASP.NET application built and deployed as
a

whole.

I have a build engine that will apply a label to all the files in the

source

repository needed for the project, then pull files by the newly
applied

label

(the label is typically just a product name and build number, like

FOO.4567).

The projects are built and then everything is packaged up for easy

deployment

to a test server.

The advantage is I can look at a build that is deployed in test or

production

and easily recreate the exact set of files used to put the software

together.

All of this was put together before the rise of Nant. I've thought of

moving

to Nant but I think at this point I'll wait for MSBuild to arrive
this

year.

--
Scott
http://www.OdeToCode.com/blogs/scott/

For some time now, I have been looking for a build system for
ASP.NET that will merge the file based ease of deployment of classic
ASP with the type saftey and prebuilt nature of ASP.NET with
codebehind. The team that I work on manages several web sites and we
have many different projects (not VS projects) going on in each site
simultaneously. Each of these projects may have different deployment
schedules. In a classis ASP world this was (mostly) not a problem
because you could work on one file and push out the changes to that
one file only, not affecting other parts of the site. In the ASP.NET
world with codebehind, changes can not be put out individual as
easily due to having to build the system as a whole.

Has anyone found a solution for this type of scenario? What I had
been thinking about doing was to use labels in source safe to
"promote" files. When a file was ready to move to the next level
(like from development to testing) the individual files that needed
to be moved to this new environment would be labeled as "test".
Then, a customized build process (probably using NANT) would get the
files with the "test" label and build the system. There might be
more than one set of changes (i.e. project (again not VS project))
that had a label of "test" at any given time. When a particualr set
of changes has finished the testing phase, the files that are part
of the change set would be labeled "stage" and then another build
process would take the "stage" files and build the system to go to
the staging server. These changes would then be retested on the
staging server and then copied to production at night. After the
copy, all files with a "stage" label would be labeled with a "prod
xx/xx/xxx" label to give a unique label for that production build.

Does anyone do anything like this? Is there any reason this would
not work? Is there a better way?

The only problem I can think of with this is that it might not be
pratical to use NANT's "solution" tag to read in the VS.NET solution
and project files. This is because you would need to be able to
promote the solution and project files and these would be in
contention and might have changes that did not need to be promoted
with your change set. I have not looked in to this fully yet, but
I'm guessing that a NANT build script would need to be created and
maintained for both test and staging environments. These scripts
would need to include references, default imports and other settings
to support the current files being built for that environment.

If someone knows of a better way or has some insight, please let me
know.

Thanks...

[Jon Paul Jones]

I have studied the team development guide several times in the past and I do
not think that it solves my problem. I think it is suited towards
development teams that work on release schedules. For these people, all
code has to be ready for testing (or staging or production) or something has
to be backed out before the build. The team I work on can needs more
granularity than that. The BuildIt system also uses VS to build based on
solution/project files and this would also be a problem since the files that
are at a particular promotion level may or may not be in the current VS
project file. This would happen in cases of additions or deletion of files
from the project. Promoting the correct version of the project file might
be difficult to do so either having seperate solution/project files for each
build environment or just not using the solution/project files at all might
be a solution.

"Scott Allen" <sc***@nospam.O deToCode.com> wrote in message
news:53******** *************@m snews.microsoft .com...

I might be able to take some relavent pieces and share them.

Another place to look, if you use Source Safe, is at this article:
http://msdn.microsoft.com/library/de...ml/tdlg_rm.asp There are some script snippets to drive VSS.

--
Scott
http://www.OdeToCode.com/blogs/scott/

No, I was thinking that the web project would always be deployed as a
whole, but that individual files (.aspx, .vb, .cs) could be promoted
individually to be included in the next build. I was probably going
to label all the sources that were at a particualr build level with a
unique build number like you are talking about. Like I would label
everything that currently has a "test" label with a new "test
some_build_numb er" label then get these files and do the build.

The main thing I am trying to acomplish with this is to be able to
build the files that are ready to be built for a particular point in
the application development lifecycle. If there are files in testing
but are not ready for production, I do not want them built in the
production (or in our case "staging") build. If two files have
changed and have been promoted to (labeled as) "test", I want to then
be able to promote maybe just one of these files to be built in the
"staging" build. Does that make since?

If your build script does this type of build, could you possibly post
it or email it to me? If you can't I understand but I would like to
see how someone else does this. I'm not wanting to wait for MSBuild
since that is several months off. Plus, I'm not sure that MSBuild by
itself will be able to do what I want. Team System might be able to
handle this though.

"Scott Allen" <sc***@nospam.O deToCode.com> wrote in message
news:53******** *************@m snews.microsoft .com...

Hi Jon:

So if I read this correctly - you'll be deploying only the changed
ASPX

files

between builds?

I prefer to have the entire ASP.NET application built and deployed as
a

whole.

I have a build engine that will apply a label to all the files in the

source

repository needed for the project, then pull files by the newly
applied

label

(the label is typically just a product name and build number, like

FOO.4567).

The projects are built and then everything is packaged up for easy

deployment

to a test server.

The advantage is I can look at a build that is deployed in test or

production

and easily recreate the exact set of files used to put the software

together.

All of this was put together before the rise of Nant. I've thought of

moving

to Nant but I think at this point I'll wait for MSBuild to arrive
this

year.

--
Scott
http://www.OdeToCode.com/blogs/scott/
For some time now, I have been looking for a build system for
ASP.NET that will merge the file based ease of deployment of classic
ASP with the type saftey and prebuilt nature of ASP.NET with
codebehind. The team that I work on manages several web sites and we
have many different projects (not VS projects) going on in each site
simultaneously. Each of these projects may have different deployment
schedules. In a classis ASP world this was (mostly) not a problem
because you could work on one file and push out the changes to that
one file only, not affecting other parts of the site. In the ASP.NET
world with codebehind, changes can not be put out individual as
easily due to having to build the system as a whole.

Has anyone found a solution for this type of scenario? What I had
been thinking about doing was to use labels in source safe to
"promote" files. When a file was ready to move to the next level
(like from development to testing) the individual files that needed
to be moved to this new environment would be labeled as "test".
Then, a customized build process (probably using NANT) would get the
files with the "test" label and build the system. There might be
more than one set of changes (i.e. project (again not VS project))
that had a label of "test" at any given time. When a particualr set
of changes has finished the testing phase, the files that are part
of the change set would be labeled "stage" and then another build
process would take the "stage" files and build the system to go to
the staging server. These changes would then be retested on the
staging server and then copied to production at night. After the
copy, all files with a "stage" label would be labeled with a "prod
xx/xx/xxx" label to give a unique label for that production build.

Does anyone do anything like this? Is there any reason this would
not work? Is there a better way?

The only problem I can think of with this is that it might not be
pratical to use NANT's "solution" tag to read in the VS.NET solution
and project files. This is because you would need to be able to
promote the solution and project files and these would be in
contention and might have changes that did not need to be promoted
with your change set. I have not looked in to this fully yet, but
I'm guessing that a NANT build script would need to be created and
maintained for both test and staging environments. These scripts
would need to include references, default imports and other settings
to support the current files being built for that environment.

If someone knows of a better way or has some insight, please let me
know.

Thanks...

[Patrice]

When archiving files are copied to a "shadow" directory. The web application
is compiled on this server using the command line compiler allowing to
create multiple DLLs. We can then deploy the needed single DLLs without
updating other DLLs...

Patrice
--

"Jon Paul Jones" <jo******@swbel l.net> a écrit dans le message de
news:uP******** ******@TK2MSFTN GP14.phx.gbl...

For some time now, I have been looking for a build system for ASP.NET that
will merge the file based ease of deployment of classic ASP with the type
saftey and prebuilt nature of ASP.NET with codebehind. The team that I work on manages several web sites and we have many different projects (not VS
projects) going on in each site simultaneously. Each of these projects may
have different deployment schedules. In a classis ASP world this was
(mostly) not a problem because you could work on one file and push out the
changes to that one file only, not affecting other parts of the site. In the ASP.NET world with codebehind, changes can not be put out individual as
easily due to having to build the system as a whole.

Has anyone found a solution for this type of scenario? What I had been
thinking about doing was to use labels in source safe to "promote" files.
When a file was ready to move to the next level (like from development to
testing) the individual files that needed to be moved to this new
environment would be labeled as "test". Then, a customized build process
(probably using NANT) would get the files with the "test" label and build
the system. There might be more than one set of changes (i.e. project (again not VS project)) that had a label of "test" at any given time. When a
particualr set of changes has finished the testing phase, the files that are part of the change set would be labeled "stage" and then another build
process would take the "stage" files and build the system to go to the
staging server. These changes would then be retested on the staging server
and then copied to production at night. After the copy, all files with a
"stage" label would be labeled with a "prod xx/xx/xxx" label to give a
unique label for that production build.

Does anyone do anything like this? Is there any reason this would not work? Is there a better way?

The only problem I can think of with this is that it might not be pratical
to use NANT's "solution" tag to read in the VS.NET solution and project
files. This is because you would need to be able to promote the solution and project files and these would be in contention and might have changes that
did not need to be promoted with your change set. I have not looked in to
this fully yet, but I'm guessing that a NANT build script would need to be
created and maintained for both test and staging environments. These scripts would need to include references, default imports and other settings to
support the current files being built for that environment.

If someone knows of a better way or has some insight, please let me know.

Thanks...

[Jon Paul Jones]

I'm sorry, I do not quite understand what you mean here. What do these
multiple DLLs contain?

"Patrice" <no****@nowhere .com> wrote in message
news:un******** ******@TK2MSFTN GP09.phx.gbl...

When archiving files are copied to a "shadow" directory. The web application is compiled on this server using the command line compiler allowing to
create multiple DLLs. We can then deploy the needed single DLLs without
updating other DLLs...

Patrice
--

"Jon Paul Jones" <jo******@swbel l.net> a écrit dans le message de
news:uP******** ******@TK2MSFTN GP14.phx.gbl...

For some time now, I have been looking for a build system for ASP.NET that will merge the file based ease of deployment of classic ASP with the type saftey and prebuilt nature of ASP.NET with codebehind. The team that I

work

on manages several web sites and we have many different projects (not VS
projects) going on in each site simultaneously. Each of these projects may have different deployment schedules. In a classis ASP world this was
(mostly) not a problem because you could work on one file and push out the changes to that one file only, not affecting other parts of the site. In

the

ASP.NET world with codebehind, changes can not be put out individual as
easily due to having to build the system as a whole.

Has anyone found a solution for this type of scenario? What I had been
thinking about doing was to use labels in source safe to "promote" files. When a file was ready to move to the next level (like from development to testing) the individual files that needed to be moved to this new
environment would be labeled as "test". Then, a customized build process
(probably using NANT) would get the files with the "test" label and build the system. There might be more than one set of changes (i.e. project

(again

not VS project)) that had a label of "test" at any given time. When a
particualr set of changes has finished the testing phase, the files that

are

part of the change set would be labeled "stage" and then another build
process would take the "stage" files and build the system to go to the
staging server. These changes would then be retested on the staging server and then copied to production at night. After the copy, all files with a
"stage" label would be labeled with a "prod xx/xx/xxx" label to give a
unique label for that production build.

Does anyone do anything like this? Is there any reason this would not

work?

Is there a better way?

The only problem I can think of with this is that it might not be pratical to use NANT's "solution" tag to read in the VS.NET solution and project
files. This is because you would need to be able to promote the solution

and

project files and these would be in contention and might have changes that did not need to be promoted with your change set. I have not looked in to this fully yet, but I'm guessing that a NANT build script would need to be created and maintained for both test and staging environments. These

scripts

would need to include references, default imports and other settings to
support the current files being built for that environment.

If someone knows of a better way or has some insight, please let me know.
Thanks...

[Patrice]

Each DLL contains a subset of our web application. The "trick" is that
compiling a web site into a single DLL is just how VS.NET works (for now).
You can use directly the compiler to compile a web site into multiple DLLs.

This way you can pick from those DLL the one you want to deploy on your
production server while leaving other DLLs unchanged...

From the begining of your post I thought this could be another way to
achieve what you are looking for (i.e. deploy a particular "module" for now
by looking at building a single DLL with all the latest "ready for
production" files for all modules ?)

Patrice
--

"Jon Paul Jones" <jo******@swbel l.net> a écrit dans le message de
news:eu******** *****@TK2MSFTNG P10.phx.gbl...

I'm sorry, I do not quite understand what you mean here. What do these
multiple DLLs contain?

"Patrice" <no****@nowhere .com> wrote in message
news:un******** ******@TK2MSFTN GP09.phx.gbl...

When archiving files are copied to a "shadow" directory. The web application

is compiled on this server using the command line compiler allowing to
create multiple DLLs. We can then deploy the needed single DLLs without
updating other DLLs...

Patrice
--

"Jon Paul Jones" <jo******@swbel l.net> a écrit dans le message de
news:uP******** ******@TK2MSFTN GP14.phx.gbl...

For some time now, I have been looking for a build system for ASP.NET that will merge the file based ease of deployment of classic ASP with the type saftey and prebuilt nature of ASP.NET with codebehind. The team that I

work

on manages several web sites and we have many different projects (not VS projects) going on in each site simultaneously. Each of these projects may have different deployment schedules. In a classis ASP world this was
(mostly) not a problem because you could work on one file and push out the changes to that one file only, not affecting other parts of the site. In

the

ASP.NET world with codebehind, changes can not be put out individual

as easily due to having to build the system as a whole.

Has anyone found a solution for this type of scenario? What I had been
thinking about doing was to use labels in source safe to "promote" files. When a file was ready to move to the next level (like from development to testing) the individual files that needed to be moved to this new
environment would be labeled as "test". Then, a customized build process (probably using NANT) would get the files with the "test" label and build the system. There might be more than one set of changes (i.e. project

(again

not VS project)) that had a label of "test" at any given time. When a
particualr set of changes has finished the testing phase, the files that are

part of the change set would be labeled "stage" and then another build
process would take the "stage" files and build the system to go to the
staging server. These changes would then be retested on the staging server and then copied to production at night. After the copy, all files with

a "stage" label would be labeled with a "prod xx/xx/xxx" label to give a
unique label for that production build.

Does anyone do anything like this? Is there any reason this would not

work?

Is there a better way?

The only problem I can think of with this is that it might not be pratical to use NANT's "solution" tag to read in the VS.NET solution and project files. This is because you would need to be able to promote the solution and

project files and these would be in contention and might have changes that did not need to be promoted with your change set. I have not looked in to this fully yet, but I'm guessing that a NANT build script would need

to be created and maintained for both test and staging environments. These

scripts

would need to include references, default imports and other settings

to support the current files being built for that environment.

If someone knows of a better way or has some insight, please let me

know.
Thanks...

[Rusty Zarse]

You are absolutely on the right track! We implement a very similar methodolgy in my development group.

Files ready for integration (promotion) are labeled with the version number of the project for which the change is intended. Make sure to prefix your label so it can never look like a date or VSS will get confused and fail (we are eager for team services). We use Bx.xx.xx (B1.03.01). B stands for Build. A version is tied to an intended release. So B1.03.xx may go out this month but B1.04.xx is slated for next month while B2.01.xx is going out sometime next quarter. Every build for QA increments the build number on a particular minor version until it is passed and deployed. Then, the minor version is incremented.

When a file has multiple releases for which it is being changed, developers must coordinate their changes so that modifications for future releases don't get picked up by intermediate builds. However, this is no different than we were used to with classic asp files. If you see a label, that means the changes are intended for that version. If you see no label, that means the changes are still in progress or the developer forgot to promote. Either way, it requires further action to resolve.

The build system is a home grown windows app that integrated vss with nant. I found alot of bugs in vss that required some programatic work arounds (mostly getting by label) so the application was necessary for us. I think these bugs are resolved with a patch from microsoft on VSS but I do not have admin rights on vss and was unable to get this update applied in my shop.

The application manages dependencies in an xml file very similar to the vs solution file. I decided that any .cs file labeled for promotion should be included so the vs project file is not used.

Builds are incremental. Therefore, the previous build's source code is necessary before labeled files can be built on top of them. All Source code is duplicated in a release vss tree. The compiled build is checked in parellel with its source.

The application performs the following steps:
1) check out the entire release tree to a local working directory for all projects to be built.
2) get latest for all projects from the development source tree.
3) using nAnt, follow the dependency chain to the bottom and build the first level projects. (if a project has a dependency that must be built, control is transfered to build that project). Moving through the config document, build each project.
3) if the builds were all successful, check all project release trees back in. Otherwise, uncheck the checkouts.
4) if the builds were successful, label them with the build version label plus a timestamp
5) email the build report to an email list (also in the xml config file)

Every solution can be represented by an independent config file.
I found that managing many project dependencies became a burdon because the label retrieval takes longer and longer as the depth of history increases in vss. The builds take 20 minutes. this isn't really that bad considering how long it takes a developer to set up a new environment (a different topic) but it is annoying if a build fails due to one missed label. Consider versioning your internal assemblies as if you were shipping them to clients and managing dependencies that way. You'll find you change the same 2 or three projects very frequently and the rest very infrequently.

I hope that helps.

I think this entire process could be managed using nAnt if the get by label thing were fixed. I am not sure. You may want to try that first.

If you have any quick questions: rusty.net -at- vitaminzrecords -dot- com
Posted via DevelopmentNow Groups
www.developmentnow.com/g
www.developmentnow.com