"Perfect" .Net Dev Environment?

Question

I've been given an early Christmas Present:
Permission to step out of the development cycle to reorganize and document our application.
I have complete freedom to restructure, refactor, and set up any amount of infrastructure I see fit.

I'm hoping to draw on the collective StackOverflow wisdom wrought in greater experience and sweat. So my question to everyone is: If you had Carte Blanche, what's your "Perfect" .Net Dev Environment?

About the App:
VB.Net Client/Server Application. (Windows Forms front end, ASPX Webservices back)
Currently using Visual Studio & SQL Server 2003 and... VSS.

I'd like to have some combination of:
* Better versioning. (leaning towards SVN)
* Wiki or other system for bug tracking and documentation. (leaning towards Trac w/ SVN)
* Simplified build process & daily builds (Visual Build? CruiseControl.Net?)
* Version control for the SQL Server database
* Upgrade to Visual Studio 2005 (or 2008)?

... for Small team of 5 or so developers

thanks.

Answer 1

I think you are leaning all in the right direction.

Go with VS.Net 2008. It's very stable with SP1, and you can target both version 2 and verstion 3 of the .Net framework.

Answer 2

We use SourceGear's Vault for version control and it works well for us as a small team.

For project/bug/support tracking we use OnTime 2008 from AxoSoft.

We also use ScrewTurn Wiki to document procedures and sample code/best practices.

For our build process, we haven't fully automated into a daily process because we don't generally work that way. However, for the beta and release builds, I just use NAnt to do a complete build for me after I update version numbers manually (I do this for better looking version numbers for our support team).

And definitely use Visual Studio 2008. The 2005 version really had a lot of issues on large VB projects (at least for us).

Answer 3

My recommendation for IDE and source control:

• VS2008 with SP1
• SubVersion, with TortoiseSVN (for Windows Explorer) and AnkhSVN (for VS2008)

Answer 4

I would cast a vote for Team Foundation Server. Then you have source control, automated builds and (kind of) bug tracking all in one package, that integrates very nicely with VS 2008. It has a rather steep price, though.

Answer 5

I agree with VS2008 with SP1, SVN (with Ankh and Tortoise)

Look into sandcastle / docproject for generating documentation.

CruiseControl works well.

As for sourcecontrol for the databases, you can use the database project type in VS2008 and use SVN (or other source control solution of your choice) to keep that under sourcecontrol.

Answer 6

I recommend the following tools (mostly because it's what we're using):

• Visual Studio 2008
• Sql Server 2008
• VisualSVN
• CruiseControl.net
• MSBuild Community Tasks

We each work on our local machines and have a separate build server which monitors the SVN repository (using CruiseControl) and builds the latest revision on that server.

We use 'MSBuild Community Tasks' to embed the SVN revision number in the assembly so that we can display it to the user.

The biggest 'holes' we have in our setup at the moment are in the database and in our automated testing.

Currently we all run off a central database server. Ideally you should work towards having a script which re-creates your database under source control. From what I gather, every time the build server rebuilds the site, it should also rebuild the database. You should also have a script which will generate any test data you want in the database.

With database builds like this, you can all work on a local copy of the database, too.

You might want to take a look at the SQL Toolbelt (or parts of it) from Red Gate software - we use the SQL Compare tools to deploy schemas to live servers and I've been really impressed with them.

Good luck!

Answer 7

No matter how much time and thought you put into this, you'll probably never end up with a "Perfect" environment. Each tool has their own quarks and issues. Nevertheless, here is some food for thought:

Go to the latest and greatest version of Visual Studio, VS2008 SP1.

If you are an MSDN subscriber, and have purchased the Team System Version of Visual Studio, you can install Team Foundation Server (TFS). TFS is a pretty slick product that is integrated into Visual Studio. It uses Windows Sharepoint Services (WSS), which would give you the ability to have Wikis, Document repositories, etc (basically a stripped down version of Microsoft Office Sharepoint Server). TFS will also give you the newest version of Visual source safe, which I have had no problems with, and Microsoft talks about it being able to scale to hundreds of thousands of users. TFS Workgroup edition will allow you up to 5 developers to use without having to purchase a license. Above 5 users, and you'll have to purchase liceses. I'm also pretty sure you'd have to use SQL Server 2005 in order to run TFS, but I could be wrong. We have TFS installed on a single box (our developer box), and have had no issues.

  SO TFS Would give you:

• Collaboration
• Version Control
• Reporting on Project Status
• Issue Tracking
• Integration into Visual Studio
• A lot of other goodies

For your daily/continuous builds, I'd lean towards CruiseControl.NET (CC.NET). We tried to use the Build system build into TFS, but ran into many,many issues (I think mainly because of the way our projects are structured). CC.Net was a breeze to install and configure, and works like a champ. You can set it up for continuous building (each check-in triggers a build), and daily builds. You may have to find some cleaver ways to make CC.NET do some of the more difficult tasks (like stopping a service, etc), but it hasn't been able to do anything I've needed done. It is also pretty extensible, so you can write some code to make it do what you want which is a nice feature.

Not sure about versioning of the database, but I'd assume you can use TFS Source Safe to achieve this.

Good luck!

Answer 8

We are using SVN with Jira for bug tracking, project management,fisheye and crucible for source browsing and codereview and it works out very well. We are a team of 12 developers spread around. We are long time users of finalbuilder which we use to do all builds and automated deployment -a mix of VB and VS.NET 2008 projects and it is working out exceptionally well for us. We target SQL Server 2005/2008 databases and keep the database objects in the source control repository. We most of the time use VS 2008 Database Edition combined with tools from Redgate and it works out pretty well for us - especially managing the change scripts and other stuffs. For us TFS simply didn't work out - though your mileage might vary. We found it to be too cumbersome, difficult to customize workflow and rather than helping with the workflow had a bad tendency to get into the way.

Answer 9

I'm a recent convert to SourceGear Fortress. It's inexpensive, fast, and reliable.

I love TFS for larger teams (>20 developers). I'm just starting to get my feet wet with Subversion, so I don't have anything to share yet, except that it was pretty easy to set it up.

Trac, however, was very difficult to get running. That's a matter of documentation, though, not the product itself.

Answer 10

My preference goes to the VS2008 / SVN / Trac / Anck and Tortoise / CC.Net (TeamCity / Bitten) setup.

I'm not saying TFS isn't a great product but I think it is 'bulky'. I switched recently from a Trac / SVN solution to TFS and I prefer the first setup. It are details but they make it nice to work with. Example:

• TFS send mails for checkins and builds, in Trac there is an easy timeline feed. (There are workarounds for TFS...)
• when there is new checkin, click on the link (from the feed) and you are in the Trac environment. You see a nice diff with the previous chancgeset... (where in TFS?)
• The integrated wiki is a very nice environment for internal documentation...
• intellisense in the Tortoise client for your comments
• nice web interface to browse source, update documentation (was easy when I was at home)
• ...

The little details make it for me a much nicer tool.

I also say that the team was a small one (also 5 developers) and you need some time to setup. I agree that when you work with larger teams TFS is maybe preferable.

Answer 11

My choices would be:

Better versioning.

I'd pick SourceGear Vault - rock-solid, works like a charm, your source in stored in SQL Server databases --> can easily be backed up and is not flaky as VSS.

Wiki or other system for bug tracking and documentation.

From my personal experience: Fogbugz is your best bet - simple, easy, quick to grasp, gets the job done nicely, just works and everybody just "gets it" without lengthy and expensive adaptation / customization and without much training - just works :-)

Simplified build process & daily builds (Visual Build? CruiseControl.Net?)

CC.Net is a great free option - if you don't mind speding a bit of $$$, I'd also look at FinalBuilder - either as a desktop or a server app.

Version control for the SQL Server database

--> use Vault! Works the same way. Use a great tool like Apex SQL Scripter or something similar to create and maintain your SQL to create and update the database schema, and put those SQL scripts into Vault.

Upgrade to Visual Studio 2005 (or 2008)?

Go with VS 2008 SP1 on .NET 3.5 SP1 - solid and full of great new productivity features.

Just my $0.02 Marc

Answer 12

Any perfect .Net dev environment would have a copy of Resharper installed. I'm a recent convert, and I love it.

Answer 13

on dev. box

• Visual Studio 2008
• Sql Server 2008
• Red Gate SQL Compare
• Red Gate Ant Profiler

on server

• Sourcegear Vault
• Fogbugz (Wiki, releases, estimates, bug tracking)
• CruiseControl.Net

Answer 14

Very yes on VS 2008 with SP1. I'd also highly recommend:

• ReSharper
• SourceGear Vault (absolutely zero learning curve coming from VSS, with all the benefits of SVN)

Answer 15

I have heard a number of good things about TFS; however, there is also the cost factor. The tools you listed work very nicely with one another and are free.

One addition I would make is TortoiseSVN for the Subversion client. Purists don't like it, but the fact that it integrates with the Windows shell's context menus (right clicks) makes it very easy to use.

For SVN versions, go with the 1.6 release that came out recently. Branching and merging have been improved with this version.

Trac is a great tool. Make sure to read up on TracWiki and TracLinks formatting rules for your SVN commit messages. Trac parses these messages so if you're commiting a fix for Ticket 123, adding '#123' to the SVN message allows Trac to link that commit (and all files associated with it) to the corresponding Trac tickets. This becomes especially usefull if and when you decide to move to delta releases.