Multiple developers, single solution

[Tim Mulholland]

My company is about to begin working on an ASP.NET application. There are
going to be two primary developers working on this project. It will be a
fairly deep project (lots of lines of code) but not a very wide project
(pretty much limited to a few purposes, not many ways to split it up).
I've done alot of ASP.NET development before by myself so writing the
application shouldn't be an issue, but my question is this:

How do multiple developers work on the same solution at once? Or can they?
Do you have to split it up (data layer, presentation layer or something like
that)? Or does VS.NET do some sort of good checking if both people have the
solution open at once?

I basically just wanted to see whats possible for this type of scenario and
what others are doing in their companies.

Thans in advance!

Tim

[Jon Paugh]

You want to use a version control tool - VSS, CVS, etc.
This tool will keep a copy of the code in a common place.
It will also provide a mechanism for your developers to
share the code - developers checkout the files and when
they are done they check it in. When they add new files,
they let the source control tool know about the files.

Otherwise, when one developer changes one file and
another developer changes another file, you will have to
somehow figure out yourself how to integrate the two sets
of code!

Both VSS or CVS and probably any other version control
tool will keep track of changes to files. You can either
setup your version control tool to only allow one person
to checkout a file at a time, or you can allow multiple
checkouts, but the tool will warn a developer if he tries
to overwrite someone elses changes (merge tool).

Jon Paugh

[Tim Mulholland]

We've got VSS that we plan to use.
I guess more of my question was something along the lines of the
compilation.

I come from an ASP world originally, where everyone could be editing files
and replacing them and making changes and testing, and (with the exception
of global.asa and things like that) what you changed probably wouldn't
affect another user working on the same project as you, because it wasn't
compiled into a common DLL file, each .asp page was run separately.

But now, if we both open the solution at the same time, and make changes, we
can't both be compiling whenever we need to because the other developer will
likely be injecting errors from time to time, as will i. And if i leave for
the night with errors in my code that keep it from compiling, and he kept
working on it, he'd either have to fix my errors or make them not happen (by
commenting things out) or something along those lines before he could test
his changes.

Does that explain better what i was getting at?

We're a fairly small company and before now we've been working on apps
developed primarily by a single developer, with the exception of a few that
had components in DLLs written by one and the actual app written by another.
Is the latter approach something i should look into for this situation?

Thanks for your comments,

Tim

"Jon Paugh" <an*******@disc ussions.microso ft.com> wrote in message
news:12******** *************** ******@phx.gbl. ..

You want to use a version control tool - VSS, CVS, etc.
This tool will keep a copy of the code in a common place.
It will also provide a mechanism for your developers to
share the code - developers checkout the files and when
they are done they check it in. When they add new files,
they let the source control tool know about the files.

Otherwise, when one developer changes one file and
another developer changes another file, you will have to
somehow figure out yourself how to integrate the two sets
of code!

Both VSS or CVS and probably any other version control
tool will keep track of changes to files. You can either
setup your version control tool to only allow one person
to checkout a file at a time, or you can allow multiple
checkouts, but the tool will warn a developer if he tries
to overwrite someone elses changes (merge tool).

Jon Paugh

[Patrice Scribe]

Seee
http://msdn.microsoft.com/library/de...l/tdlg_ch2.asp
and the isolated mode.

The big picture is that each developer gets a copy of the project he can run
on localhost. He can checkout files to edit them at will and test changes
locally avoiding global problems. When changes are ok they are stored back
at the central location.

Each developer can get a refresh at will by getting the last version. It
works pretty well for us with just a little disscipline (avoiding checking
in changes that won't compile).

Patrice
--

"Tim Mulholland" <Ti***********@ nospamaddress.c om> a écrit dans le message
de news:Oz******** ******@TK2MSFTN GP12.phx.gbl...

We've got VSS that we plan to use.
I guess more of my question was something along the lines of the
compilation.

I come from an ASP world originally, where everyone could be editing files
and replacing them and making changes and testing, and (with the exception
of global.asa and things like that) what you changed probably wouldn't
affect another user working on the same project as you, because it wasn't
compiled into a common DLL file, each .asp page was run separately.

But now, if we both open the solution at the same time, and make changes, we can't both be compiling whenever we need to because the other developer will likely be injecting errors from time to time, as will i. And if i leave for the night with errors in my code that keep it from compiling, and he kept
working on it, he'd either have to fix my errors or make them not happen (by commenting things out) or something along those lines before he could test
his changes.

Does that explain better what i was getting at?

We're a fairly small company and before now we've been working on apps
developed primarily by a single developer, with the exception of a few that had components in DLLs written by one and the actual app written by another. Is the latter approach something i should look into for this situation?

Thanks for your comments,

Tim

"Jon Paugh" <an*******@disc ussions.microso ft.com> wrote in message
news:12******** *************** ******@phx.gbl. ..

You want to use a version control tool - VSS, CVS, etc.
This tool will keep a copy of the code in a common place.
It will also provide a mechanism for your developers to
share the code - developers checkout the files and when
they are done they check it in. When they add new files,
they let the source control tool know about the files.

Otherwise, when one developer changes one file and
another developer changes another file, you will have to
somehow figure out yourself how to integrate the two sets
of code!

Both VSS or CVS and probably any other version control
tool will keep track of changes to files. You can either
setup your version control tool to only allow one person
to checkout a file at a time, or you can allow multiple
checkouts, but the tool will warn a developer if he tries
to overwrite someone elses changes (merge tool).

Jon Paugh

[Reza]

Just to add to the last respond you got. In our case, every developer had their own project but with the same layers and logically worked on different parts.
Then had a machine to central all the code, which the solution was put in the vss
Beside this, there has to be a good communication between developers and some standard set so everybody won't be flying in opposite directions

Hope this helps
Reza

[Tim Mulholland]

I followed through that solution on the link you gave me (and through a
bunch of the other links contained therein, and i swear i must be missing
something.
We've got a development server we want the whole project on before we copy
it to the webserver when its finalized.
I created the ASP.NET web application on that, and then went into the
Internset Services Manager and turned on Version Control to be external (and
then chose the location in VSS to save it).
I then (on my development machine) used VSS to get a working copy and i can
then edit/run/debug that working copy just fine.
If i then check my changes back into VSS, the changes are not propogated
back to the development machine.
I know i'm just missing a step or something, do you see what i did wrong
(sorry if its something stupid, its my first attempt at multi-developer
work)

Tim

"Patrice Scribe" <no****@nowhere .com> wrote in message
news:Oe******** ********@TK2MSF TNGP12.phx.gbl. ..

Seee
http://msdn.microsoft.com/library/de...l/tdlg_ch2.asp and the isolated mode.

The big picture is that each developer gets a copy of the project he can run on localhost. He can checkout files to edit them at will and test changes
locally avoiding global problems. When changes are ok they are stored back
at the central location.

Each developer can get a refresh at will by getting the last version. It
works pretty well for us with just a little disscipline (avoiding checking
in changes that won't compile).

Patrice
--

"Tim Mulholland" <Ti***********@ nospamaddress.c om> a écrit dans le message
de news:Oz******** ******@TK2MSFTN GP12.phx.gbl...

We've got VSS that we plan to use.
I guess more of my question was something along the lines of the
compilation.

I come from an ASP world originally, where everyone could be editing files and replacing them and making changes and testing, and (with the exception of global.asa and things like that) what you changed probably wouldn't
affect another user working on the same project as you, because it wasn't compiled into a common DLL file, each .asp page was run separately.

But now, if we both open the solution at the same time, and make changes,

we

can't both be compiling whenever we need to because the other developer

will

likely be injecting errors from time to time, as will i. And if i leave

for

the night with errors in my code that keep it from compiling, and he

kept working on it, he'd either have to fix my errors or make them not happen

(by

commenting things out) or something along those lines before he could test his changes.

Does that explain better what i was getting at?

We're a fairly small company and before now we've been working on apps
developed primarily by a single developer, with the exception of a few

that

had components in DLLs written by one and the actual app written by

another.

Is the latter approach something i should look into for this situation?

Thanks for your comments,

Tim

"Jon Paugh" <an*******@disc ussions.microso ft.com> wrote in message
news:12******** *************** ******@phx.gbl. ..

You want to use a version control tool - VSS, CVS, etc.
This tool will keep a copy of the code in a common place.
It will also provide a mechanism for your developers to
share the code - developers checkout the files and when
they are done they check it in. When they add new files,
they let the source control tool know about the files.

Otherwise, when one developer changes one file and
another developer changes another file, you will have to
somehow figure out yourself how to integrate the two sets
of code!

Both VSS or CVS and probably any other version control
tool will keep track of changes to files. You can either
setup your version control tool to only allow one person
to checkout a file at a time, or you can allow multiple
checkouts, but the tool will warn a developer if he tries
to overwrite someone elses changes (merge tool).

Jon Paugh

[Bryan Donaldson]

You can get where you want by using the Isolated model discussed above.
Just treat your development server as another development workstation - get
the source from VSS and build the project there. When ready, copy the
project to the production server.

"Tim Mulholland" <Ti***********@ nospamaddress.c om> wrote in message
news:ex******** *****@TK2MSFTNG P11.phx.gbl...

I followed through that solution on the link you gave me (and through a
bunch of the other links contained therein, and i swear i must be missing
something.
We've got a development server we want the whole project on before we copy
it to the webserver when its finalized.
I created the ASP.NET web application on that, and then went into the
Internset Services Manager and turned on Version Control to be external (and then chose the location in VSS to save it).
I then (on my development machine) used VSS to get a working copy and i can then edit/run/debug that working copy just fine.
If i then check my changes back into VSS, the changes are not propogated
back to the development machine.
I know i'm just missing a step or something, do you see what i did wrong
(sorry if its something stupid, its my first attempt at multi-developer
work)

Tim

"Patrice Scribe" <no****@nowhere .com> wrote in message
news:Oe******** ********@TK2MSF TNGP12.phx.gbl. ..

Seee

http://msdn.microsoft.com/library/de...l/tdlg_ch2.asp

and the isolated mode.

The big picture is that each developer gets a copy of the project he can

run

on localhost. He can checkout files to edit them at will and test changes

locally avoiding global problems. When changes are ok they are stored back at the central location.

Each developer can get a refresh at will by getting the last version. It
works pretty well for us with just a little disscipline (avoiding checking in changes that won't compile).

Patrice
--

"Tim Mulholland" <Ti***********@ nospamaddress.c om> a écrit dans le message de news:Oz******** ******@TK2MSFTN GP12.phx.gbl...

We've got VSS that we plan to use.
I guess more of my question was something along the lines of the
compilation.

I come from an ASP world originally, where everyone could be editing files and replacing them and making changes and testing, and (with the exception of global.asa and things like that) what you changed probably wouldn't
affect another user working on the same project as you, because it wasn't compiled into a common DLL file, each .asp page was run separately.

But now, if we both open the solution at the same time, and make changes,

we

can't both be compiling whenever we need to because the other developer will

likely be injecting errors from time to time, as will i. And if i

leave for

the night with errors in my code that keep it from compiling, and he kept working on it, he'd either have to fix my errors or make them not

happen (by

commenting things out) or something along those lines before he could

test his changes.

Does that explain better what i was getting at?

We're a fairly small company and before now we've been working on apps
developed primarily by a single developer, with the exception of a few

that

had components in DLLs written by one and the actual app written by

another.

Is the latter approach something i should look into for this

situation?
Thanks for your comments,

Tim

"Jon Paugh" <an*******@disc ussions.microso ft.com> wrote in message
news:12******** *************** ******@phx.gbl. ..
> You want to use a version control tool - VSS, CVS, etc.
> This tool will keep a copy of the code in a common place.
> It will also provide a mechanism for your developers to
> share the code - developers checkout the files and when
> they are done they check it in. When they add new files,
> they let the source control tool know about the files.
>
> Otherwise, when one developer changes one file and
> another developer changes another file, you will have to
> somehow figure out yourself how to integrate the two sets
> of code!
>
> Both VSS or CVS and probably any other version control
> tool will keep track of changes to files. You can either
> setup your version control tool to only allow one person
> to checkout a file at a time, or you can allow multiple
> checkouts, but the tool will warn a developer if he tries
> to overwrite someone elses changes (merge tool).
>
> Jon Paugh

[Tim Mulholland]

But the development server is the only one that has all the files on it, so
it is the one with frontpage extensions configured to use VSS right?
(production server will only have .aspx and .dll files)
And then the rest of the workstations just have to get a local copy of it
from VSS, correct?
WHen i do that, and open the project from the development server, the
changes i made on one of the development machines and then checked in to VSS
are not in the solution. Did i just miss a step?

Maybe i'm just tired and need to go home and try this again in the morning,
but i'm not following very well what i'm doing wrong.

Thanks for your help so far guys.

Tim

"Bryan Donaldson" <br************ **********@REMO VETHISmindsprin g.com> wrote
in message news:%2******** ********@TK2MSF TNGP09.phx.gbl. ..

You can get where you want by using the Isolated model discussed above.
Just treat your development server as another development workstation - get the source from VSS and build the project there. When ready, copy the
project to the production server.

"Tim Mulholland" <Ti***********@ nospamaddress.c om> wrote in message
news:ex******** *****@TK2MSFTNG P11.phx.gbl...

I followed through that solution on the link you gave me (and through a
bunch of the other links contained therein, and i swear i must be missing

something.
We've got a development server we want the whole project on before we copy it to the webserver when its finalized.
I created the ASP.NET web application on that, and then went into the
Internset Services Manager and turned on Version Control to be external

(and

then chose the location in VSS to save it).
I then (on my development machine) used VSS to get a working copy and i

can

then edit/run/debug that working copy just fine.
If i then check my changes back into VSS, the changes are not propogated
back to the development machine.
I know i'm just missing a step or something, do you see what i did wrong
(sorry if its something stupid, its my first attempt at multi-developer
work)

Tim

"Patrice Scribe" <no****@nowhere .com> wrote in message
news:Oe******** ********@TK2MSF TNGP12.phx.gbl. ..

Seee

http://msdn.microsoft.com/library/de...l/tdlg_ch2.asp

and the isolated mode.

The big picture is that each developer gets a copy of the project he can

run

on localhost. He can checkout files to edit them at will and test changes locally avoiding global problems. When changes are ok they are stored back at the central location.

Each developer can get a refresh at will by getting the last version.

It works pretty well for us with just a little disscipline (avoiding checking in changes that won't compile).

Patrice
--

"Tim Mulholland" <Ti***********@ nospamaddress.c om> a écrit dans le message de news:Oz******** ******@TK2MSFTN GP12.phx.gbl...
> We've got VSS that we plan to use.
> I guess more of my question was something along the lines of the
> compilation.
>
> I come from an ASP world originally, where everyone could be editing

files

> and replacing them and making changes and testing, and (with the

exception

> of global.asa and things like that) what you changed probably wouldn't > affect another user working on the same project as you, because it

wasn't

> compiled into a common DLL file, each .asp page was run separately.
>
> But now, if we both open the solution at the same time, and make

changes,

we
> can't both be compiling whenever we need to because the other developer will
> likely be injecting errors from time to time, as will i. And if i leave for
> the night with errors in my code that keep it from compiling, and he

kept

> working on it, he'd either have to fix my errors or make them not happen (by
> commenting things out) or something along those lines before he could test

> his changes.
>
> Does that explain better what i was getting at?
>
> We're a fairly small company and before now we've been working on

apps > developed primarily by a single developer, with the exception of a few that
> had components in DLLs written by one and the actual app written by
another.
> Is the latter approach something i should look into for this

situation? >
> Thanks for your comments,
>
> Tim
>
> "Jon Paugh" <an*******@disc ussions.microso ft.com> wrote in message
> news:12******** *************** ******@phx.gbl. ..
> > You want to use a version control tool - VSS, CVS, etc.
> > This tool will keep a copy of the code in a common place.
> > It will also provide a mechanism for your developers to
> > share the code - developers checkout the files and when
> > they are done they check it in. When they add new files,
> > they let the source control tool know about the files.
> >
> > Otherwise, when one developer changes one file and
> > another developer changes another file, you will have to
> > somehow figure out yourself how to integrate the two sets
> > of code!
> >
> > Both VSS or CVS and probably any other version control
> > tool will keep track of changes to files. You can either
> > setup your version control tool to only allow one person
> > to checkout a file at a time, or you can allow multiple
> > checkouts, but the tool will warn a developer if he tries
> > to overwrite someone elses changes (merge tool).
> >
> > Jon Paugh
>
>

[Tim Mulholland]

I just realized somehting else.
When i try to check out one of the files using the development server (or,
more appropriately, using a workstation and opening the project directly on
the development server) i get the error:

"Unable to check out file 'default.aspx.c s'. Server error: There is a
problem with source control integration on your server. Contact your web
server Administrator."

Thoughts?

"Bryan Donaldson" <br************ **********@REMO VETHISmindsprin g.com> wrote
in message news:%2******** ********@TK2MSF TNGP09.phx.gbl. ..

You can get where you want by using the Isolated model discussed above.
Just treat your development server as another development workstation - get the source from VSS and build the project there. When ready, copy the
project to the production server.

"Tim Mulholland" <Ti***********@ nospamaddress.c om> wrote in message
news:ex******** *****@TK2MSFTNG P11.phx.gbl...

I followed through that solution on the link you gave me (and through a
bunch of the other links contained therein, and i swear i must be missing

something.
We've got a development server we want the whole project on before we copy it to the webserver when its finalized.
I created the ASP.NET web application on that, and then went into the
Internset Services Manager and turned on Version Control to be external

(and

then chose the location in VSS to save it).
I then (on my development machine) used VSS to get a working copy and i

can

then edit/run/debug that working copy just fine.
If i then check my changes back into VSS, the changes are not propogated
back to the development machine.
I know i'm just missing a step or something, do you see what i did wrong
(sorry if its something stupid, its my first attempt at multi-developer
work)

Tim

"Patrice Scribe" <no****@nowhere .com> wrote in message
news:Oe******** ********@TK2MSF TNGP12.phx.gbl. ..

Seee

http://msdn.microsoft.com/library/de...l/tdlg_ch2.asp

and the isolated mode.

The big picture is that each developer gets a copy of the project he can

run

on localhost. He can checkout files to edit them at will and test changes locally avoiding global problems. When changes are ok they are stored back at the central location.

Each developer can get a refresh at will by getting the last version.

It works pretty well for us with just a little disscipline (avoiding checking in changes that won't compile).

Patrice
--

"Tim Mulholland" <Ti***********@ nospamaddress.c om> a écrit dans le message de news:Oz******** ******@TK2MSFTN GP12.phx.gbl...
> We've got VSS that we plan to use.
> I guess more of my question was something along the lines of the
> compilation.
>
> I come from an ASP world originally, where everyone could be editing

files

> and replacing them and making changes and testing, and (with the

exception

> of global.asa and things like that) what you changed probably wouldn't > affect another user working on the same project as you, because it

wasn't

> compiled into a common DLL file, each .asp page was run separately.
>
> But now, if we both open the solution at the same time, and make

changes,

we
> can't both be compiling whenever we need to because the other developer will
> likely be injecting errors from time to time, as will i. And if i leave for
> the night with errors in my code that keep it from compiling, and he

kept

> working on it, he'd either have to fix my errors or make them not happen (by
> commenting things out) or something along those lines before he could test

> his changes.
>
> Does that explain better what i was getting at?
>
> We're a fairly small company and before now we've been working on

apps > developed primarily by a single developer, with the exception of a few that
> had components in DLLs written by one and the actual app written by
another.
> Is the latter approach something i should look into for this

situation? >
> Thanks for your comments,
>
> Tim
>
> "Jon Paugh" <an*******@disc ussions.microso ft.com> wrote in message
> news:12******** *************** ******@phx.gbl. ..
> > You want to use a version control tool - VSS, CVS, etc.
> > This tool will keep a copy of the code in a common place.
> > It will also provide a mechanism for your developers to
> > share the code - developers checkout the files and when
> > they are done they check it in. When they add new files,
> > they let the source control tool know about the files.
> >
> > Otherwise, when one developer changes one file and
> > another developer changes another file, you will have to
> > somehow figure out yourself how to integrate the two sets
> > of code!
> >
> > Both VSS or CVS and probably any other version control
> > tool will keep track of changes to files. You can either
> > setup your version control tool to only allow one person
> > to checkout a file at a time, or you can allow multiple
> > checkouts, but the tool will warn a developer if he tries
> > to overwrite someone elses changes (merge tool).
> >
> > Jon Paugh
>
>

[Kevin Yu [MSFT]]

Thank you all for your responses!

Hi Tim,

First of all, I would like to confirm my understanding of your issue. Based
on the discussion, I understand that you need to know how VSS works. If
there is any misunderstandin g, please feel free to let me know.

Just as Patrice said, the VSS server keeps all files on it. You can use
File/Source Control/Add Solution to Source Control in the VS.NET menu to
add the current solution to VSS server. Each of developers can have a copy
of all the files or part of the files on their machine by using Get Latest
Version. When developers are making changes to the code, they are actually
modifying the copy of code on their machine. And they are also building and
debugging on their own machine. If the any of the developer has made his
code result in errors, the other developers and the VSS server will not be
affected by him before he has checked in his code with errors. So we
needn't worry about this.

From the error description you have provided, it seems that VSS wasn't
properly installed on your machine. Each developer has to install VSS on
their machine. It is recommended to use Visual Sourcesafe 6.0d, as it works
well with Visual Studio .NET 2003. Please try to reinstall VSS. It will be
better to install VSS after installing VS.NET.

Does this answer your question? If anything is unclear, please feel free to
reply to the post.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."