473,326 Members | 2,114 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

ASP.NET, source safe and promotion levels

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...
Nov 19 '05 #1
8 1314
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...

Nov 19 '05 #2
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_number" 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.OdeToCode.com> wrote in message
news:53*********************@msnews.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...


Nov 19 '05 #3
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_number" 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.OdeToCode.com> wrote in message
news:53*********************@msnews.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...

Nov 19 '05 #4
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.OdeToCode.com> wrote in message
news:53*********************@msnews.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_number" 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.OdeToCode.com> wrote in message
news:53*********************@msnews.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...


Nov 19 '05 #5
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******@swbell.net> a écrit dans le message de
news:uP**************@TK2MSFTNGP14.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...

Nov 19 '05 #6
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**************@TK2MSFTNGP09.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******@swbell.net> a écrit dans le message de
news:uP**************@TK2MSFTNGP14.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...


Nov 19 '05 #7
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******@swbell.net> a écrit dans le message de
news:eu*************@TK2MSFTNGP10.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**************@TK2MSFTNGP09.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******@swbell.net> a écrit dans le message de
news:uP**************@TK2MSFTNGP14.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...



Nov 19 '05 #8
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
Nov 19 '05 #9

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
by: Job Lot | last post by:
I am having loads of problem using vb.net project under visual source safe. I’ll start with How can I exclude source safe information from the project when I take a copy of project home? I...
2
by: Lou | last post by:
Ok, I added my prject to source safe. It worked good for a week, then, one time I couldn't get to source safe and VB propmted to work offline, no I can't get any of my files back into source safe....
2
by: Darren Clark | last post by:
HOw do i get source safe working with .net? I have source safe the server setup on our server... however on my machine when i go File > Source Control > All options are always greyed out. ...
0
by: gm | last post by:
Immediately after generating the Access application from the Source Safe project I get: "-2147467259 Could not use ''; file already in use." If Access database closed and then reopened I get:...
8
by: olrt | last post by:
Hello, I plan to install Visual C# 2005 Express. I need a source code control system. It seems that there's no express version of Visual Source Safe. What should I do ? Is Visual C# 2005 Express...
2
by: clintonb | last post by:
Using Visual Studio 2005, I created a new website: File->New->Web Site and chose the ASP.Net Web Site template. Saved it in location c:\Projects\GCSLRMS_DotNet\WS\WebSite1. It created the...
0
by: WebSnozz | last post by:
I would like to add my binaries from the Release directory of several projects to source safe. My hope is that I can get latest, build the project, and then check-in so that the binaries are...
1
by: johnlim20088 | last post by:
Hi, Currently I have 6 web projects located in Visual Source Safe 6.0, as usual, everytime I will open solution file located in my local computer, connected to source safe, then check out/check in...
1
by: bharathreddy | last post by:
This Article gives an introduction to VSTS Team Foundation & fundamental difference between Visual Source Safe (VSS) and VSTS Team Foundation. Team Foundation is a set of tools and technologies...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.