We are developing an application in ASP.NET (Ms visual studio 2008 -
.net framework 2.0). There are 4 developers involved in this project
and they will work separate nodes. The application source code will be
stored one server (Web Server). There no problem while open the
solution in multiple nodes, and all of them can modify. We are facing
the problem while running the solution in other then server node. This
solution is running in only on the server (where we've maintained the
source code). In all other nodes showing security related errors.
The proper way to handle development with multiple developers is NOT to
store the source on a web server and have the developers all develop
directly off the server. The fact you have to compromise security should
be a red flag, even if it is a development server.
You really should do the following:
1. Set up some form of source control. If money is an issue, try CVS or
Subversion. Other choices are SourceSafe (yuck, personally, but it can
work for small teams), Team Foundation Server, Vault/Fortress, or the
Rational Suite of products (TFS and Rational are the expensive options).
2. Download a continuous integration product, like Cruise Control .NET.
Set up your project to build when checked in. You can set up Cruise
Control .NET to use MSBuild or nAnt or similar. This is an optional
step, but gives instant feedback when a build is broken.
3. Have the developers get source on their local box and check out from
source control. The development is in isolation, but the optional
continuous integration is a step that can alleviate the problems with
this route.
IMO, the "lets destroy security so we can all work on the same box" is
an ill-conceived idea. You can solve the security issue easily enough,
but you still have problems with debugging. Since only one person can
really debug at a time, his debugging can be poluted by the efforts of
other developers. Generally, this shows up as a bug you chase that may
or may not be there (especially with Shared/static bits - things stored
in application, for example). Sometimes, however, things appear to work
when they really are not. Not a wise direction to go.
If you don't want to heed this advice, Alexy gave you a means of
neutering the warnings and errors. ;-)
Peace and Grace,
Greg
--
Vote for Miranda's Christmas Story
http://tinyurl.com/mirandabelieve
Twitter: @gbworld
Blog:
http://gregorybeamer.spaces.live.com
*******************************************
| Think outside the box! |
*******************************************
