---
title: "Solving Team Development with web projects hell"
url: "https://osherove.com/blog/2004/10/15/solving-team-development-with-web-projects-hell.md"
canonical: "https://osherove.com/blog/2004/10/15/solving-team-development-with-web-projects-hell.html"
published: "2004-10-15T23:44:00"
updated: "2004-10-15T23:44:00"
tags: [".Net Original", "Cool Articles"]
author: "Roy Osherove"
description: "I've been inspired by this article to change the way one of the teams at work has been handling a large solution. We had a big problem with a large solution (over 100 projects) that had many web services and asp.net…"
usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)."
license: "https://creativecommons.org/licenses/by/4.0/"
---

# Solving Team Development with web projects hell

By Roy Osherove October 15, 2004 In [.Net Original](https://osherove.com/blog/category/net-original), [Cool Articles](https://osherove.com/blog/category/cool-articles)

**Historical article** · Originally published October 15, 2004; technical details may be outdated.

I've been inspired by [this article](http://www.sys-con.com/dotnet/article.cfm?id=320) to change the way one of the teams at work has been handling a large solution.

We had a big problem with a large solution (over 100 projects)  that had many web services and asp.net projects within it. the problems arose when the project needed to be built on a new machine at work. creating the project from source safe made for a big hassle because of the way vs.net handles web related projects - it requires they sit on a virtual directory on IIS to be built. SO virtual directories would be created on the new machine automatically but lots of times (especially when trying to re-get the whole project on the same machine multiple times) we would get new virtual directories with different names created automatically for us. This "broke" the solution for other machines which relies on different virtual directories names and so we got a big headache when working as a team on the same web project.

It was a nightmare.

The article suggests that web projects will not actually be "web projects" inside the solution, but instead will be class library projects which can be built just the same. You can easily drop web pages, asmx pages, controls and anything else you would have in a normal web project into a class lib project and it would build great. Only now you don't need to hassle with virtual directories being automatically created by vs.net. nope - you simply **map your own** directories on the build directories on your project and that's that. very easy and saves us a LOT of time.

Another bonus is that web projects are now saved **under** the source tree route instead of **next to it** with regular projects.  Yes - its very nice.

anyone have experience with this? any other means of working with a shared web project?

## More in .Net Original

[All posts in .Net Original](https://osherove.com/blog/category/net-original)

- Nov 8, 2004

    ### [Simple math with regular expressions?](https://osherove.com/blog/2004/11/8/simple-math-with-regular-expressions.html)

- Oct 19, 2004

    ### [Osherove.Interception 1.04 - Change return values and incoming parameter values at runtime easily](https://osherove.com/blog/2004/10/19/osheroveinterception-104-change-return-values-and-incoming-p.html)

- Oct 15, 2004

    ### [\[Tools and Addins\] : SharpTools, web controls and various utilities - free!](https://osherove.com/blog/2004/10/15/tools-and-addins-sharptools-web-controls-and-various-utiliti.html)

- Oct 12, 2004

    ### [Introducing the Osherove.Interception framework](https://osherove.com/blog/2004/10/12/introducing-the-osheroveinterception-framework.html)


---

## About the author

**Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery.

### Sites

- [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership.
- [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts.
- [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin.
- [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model.
- [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps.
- [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes).

### Social

- X: https://x.com/royosherove
- LinkedIn: https://www.linkedin.com/in/osherove/

### Contact

- Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7

### License

Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/
