What is the best practice for setting up a Microsoft development environment
I just joined a small development team and there doesn't seem to be any rhyme or reason why each developer sets up their development environment or how they use version control (currently Source Safe).
I made a "mistake" asking about their standard practices. In short, it made me come up with a plan to standardize everything that we reasonably can, since there is currently no NO standard and this causes unnecessary delays and headaches. So I hope some of you can give me some advice or point out some good resources in this regard.
A bit of background. Our team consists of 10 developers working on .NET projects ranging from DotNetNuke Portals and Modules, to Webservices, to WPF projects. Most developers work offline (hence the difference in settings for each), but we should all have access (currently via Source Safe) to all projects to support, find and improve bugs.
I'm looking for suggestions as simple as how we should standardize the places for 3rd party DLLs in each of our boxes, or use a network location for them so that all references are consistent - to the point that the best way to organize the project folder structure is to come up with a plan to reorganize everything step by step (i.e. leave it where it is until you need to work on it, then migrate it to the new system).
Any help would be greatly appreciated.
a source to share
Use project-based references where possible. For third party DLLs, make sure you have a separate folder named Lib or something, and each third party DLL group is in their respective vendor folders.
eg
Lib\ Lib\Infragistics Lib\Telerik
This structure can sometimes be outside of all of your projects if multiple projects reference them.
Then you can easily set the path to these dlls from your project. Also, a lot depends on whether you change the source code of these third-party vendors, then you might have to really think through, as every team in your group might want to make some changes and have their own instance regardless of dependencies or bugs caused by changes to other commands.
You can find more information on the following topics online to help you set up a standard process.
- Continuous integration
- Cruise Control.NeT
- Nant
Also note that you should not over-emphasize the organization of the structure of the solution. The real focus should be continuous integration, a good build process, and automating as many materials as possible. It will give you a good impression if you create an optimized release process for all your patches, app dropdowns, etc.
a source to share
Workstations I work on:
- Intel Q6600
- RAM 4 GB
- 3 LCD displays 22 "
- Vista Business 64-bit w / SP1 (ibstupidhate)
- Visual Studio 2008 Service Pack 1 (SP1)
- Before .Net 3.5
- Visual Source Safe client (ugh)
- SQL Server Management Studio
- Chrome / FF 3 / IE7 / Opera / Safari
My system also has CodeSmith Studio Professional as I deal with the entire generation of netTiers in the office.
Vista gave me no problems, I just need to run VS2008 in administrative mode when I test the WCF hosts. Hate as much as you want, but Vista has been solid for me since February 2007.
a source to share
1) Operating system: use Windows XP before Windows 7 is released Install service packs and all updates. 2) Install .NET Framework 2.0 and service packs for it
3) Install .Net Framework 3.0
4) Install .Net Framework 3.5
5) Install Visual Studio 2008 and SP1 for it
6) Install SVN Server (from Collabnet) and TortoiseSVN (from Tiger) for version control
7) If you are building very custom WPF frontends install MS Expression Studio
8) Install Chrome, Firefox 3 (with FireBug), IE 8 (it can emulate 7) and Opera for testing
9) Install SQL Server Management Studio
This will get you started developing WPF, Asp.net and WinForms applications.
a source to share