Jump to content

How do you manage large projects with multiple developers


aspnetguy

Recommended Posts

Up until now I have been the only full-time programmer for my company. I have been the sole owner/manager of all the projects I have done with the exception of small bits being developed seperately by some other part-time developer. This was never ideal from a team situation but it was relitively painless and has worked.Recently our work load has exploded and the other developer is being put on more and more projects but we are struggling to come up with a system that will allow both of us to work on the same project (different modules) in an easy, fairly seamless way. This problem will be compounded as there is a good possibility of getting another full time programmer in the near future.The development model I am looking at right now is to have multiple projects in a VS Solution, each module of the application being a project. This presents challenges and questions also: 1) How do I share MasterPages with the child projects or would it be better to wrap the common page elements into user controls?2) When I create the projects as Web Applications they are created at equal levels in the file system not with a primary project/child projects in sub folders. If I use the primary project as the application root in IIS and create the child projects as virtual directories under the application root will the child projects use the root web.config file, etc (assuming I have removed the web.config from the child projects?How do you manage this type of situation? What is the recommended approach? Advice is greatly appreciated.

Link to comment
Share on other sites

1) How do I share MasterPages with the child projects or would it be better to wrap the common page elements into user controls?
I still haven't used MasterPages in any of the projects I work on. The only thing similar that I can attest to is that we extended the default System.Web.UI.Page class - we called it RestrictedPage - which resides in a Class Library which is a separate project from each of the Web Applications, Windows Services, and Windows Applications that are all part of our Solution. This model works really well for us as any of the pages that share the same authentication mechanism across the various Web Applications we have can all use this class as long as the DLLs are referenced correctly.I would assume that you would be able to use this to keep at least the code behind for the MasterPage in a common DLL and you should definitely be able to do so with the User Controls.
2) When I create the projects as Web Applications they are created at equal levels in the file system not with a primary project/child projects in sub folders. If I use the primary project as the application root in IIS and create the child projects as virtual directories under the application root will the child projects use the root web.config file, etc (assuming I have removed the web.config from the child projects?
Yes. This is how we do it. For example, we have our main web application and we, among other things, have a separate web application to handle help requests and to store our knowledge base. This child web application is set up as a virtual directory under the main application in IIS and it has full access to the Web.config of the parent application. Nothing at all special needed to be done to set this up as .NET will navigate up the request path all the way to the install directory for .NET looking for the Web.config files.Two other bits of advice:1) If you haven't already done so, get your solution set up in some type of source control. We happen to use Source Safe. While we have various complaints about it from time to time - quirky interface issues, slowness recursively getting the lastest build, full on crashes - it has served us very well and allows us developers to work on a single file without worrying about another developer attempting to work on the same file simultaneously.2) Use folders in Visual Studio to help organize the projects. We have a folder called "Libraries" which contain all the 6 or 7 class library projects, another called "Web_Applications" (.NET seems to hate spaces in the folder names...that took us two good days to determine after receiving hundreds of completely meaningless error messages) which contains the 4 web application projects, another called "Windows_Services", "Web_Services", "Windows_Applications" and so on. This helps because if, for example, one of the developers isn't going to be working on any of the class libraries, s/he can hide that folder from his/her view of the solution and be better able to keep track of which files s/he needs to be working on. Also, in general, it helps (us) to organize all the projects in our solution.
Link to comment
Share on other sites

Just as a quick update on want solution I have decided to use.To get around limitations with MasterPages I have created the common parts of my pages as seperate ASP.Net Server Controls library. Each module/section of the application I have broken into seperate projects which I make as virtual directories (VD) in IIS.To get the VD to function correctly (share Forms Authentication, etc) the VD must not be setup as an application and I delete the Global.asax and Web.config files from the VD.This seems to work well and we are going to be incorporating source control into the mix once we have decided on a product.

Link to comment
Share on other sites

Are the projects you're building set up as web sites or as web applications? Ours are all set up as web applications. As I mentioned above, we have a main web application set up as the default web site in IIS and each of the other web application projects are set up as virtual directories in IIS for that main web site.These virtual directories are all set up as applications in IIS and each has its own Global.asax and Web.config files. That being said, some of the functionality of the VD is unique to that web application and this is why we have the Global.asax file still active in that application. If you had planned on using the functionality of a single Global.asax, your route may have been the way to go.Also, some of the VD applications have unique settings that don't really make sense in the Web.config of the main application so we have placed those settings in the web config files inside each of the applications. Common settings, however, still reside in the main application's config file and trickle down to the VD just fine.Happy to hear that you got it set up though.If you decide on something other than Visual Source Safe, could you please post your decision here or PM me with the decision. We're always looking for alternatives.

Link to comment
Share on other sites

They are all web applications. I went with just the main global.asax and web.config because the project was started with Forms Authentication (FA). We are planning a global framework that we will include in all our applications that will handle database abstraction, security and authentication, custom controls, and things common to web applications in general. In the future we will have a choice as to the IIS setup but for this project we are tied to FA.Also once ASP.Net MVC has matured and I have had time to play with it I imagine that is the route I will try and get us going down. I personally hate working around ViewState. Of course our compnent vendor will have to release MVC compatible controls first :)Have you done anywork with Silverlight yet? 2.0 looks like it might be fairly usable now that you can make user controls for Silverlight.I'll be sure to let you know what we decide to use for source control.

Are the projects you're building set up as web sites or as web applications? Ours are all set up as web applications. As I mentioned above, we have a main web application set up as the default web site in IIS and each of the other web application projects are set up as virtual directories in IIS for that main web site.These virtual directories are all set up as applications in IIS and each has its own Global.asax and Web.config files. That being said, some of the functionality of the VD is unique to that web application and this is why we have the Global.asax file still active in that application. If you had planned on using the functionality of a single Global.asax, your route may have been the way to go.Also, some of the VD applications have unique settings that don't really make sense in the Web.config of the main application so we have placed those settings in the web config files inside each of the applications. Common settings, however, still reside in the main application's config file and trickle down to the VD just fine.Happy to hear that you got it set up though.If you decide on something other than Visual Source Safe, could you please post your decision here or PM me with the decision. We're always looking for alternatives.
Link to comment
Share on other sites

Jesh,could you explain to me a bit about your RestrictedPage class and how oyu use it. I need an alternative to Forms Authentication that can be used by all projects in the solution even when configured as apps in IIS.

Link to comment
Share on other sites

Certainly. Without giving too much away....One of the requirements we set is that cookies need to be enabled in order for users to use our site. Then, when a user logs in, we validate the information against the database and then write a cookie to the browser that contains a little piece of encrypted data which we use to identify a user later on.Our RestrictedPage extends the System.Web.UI.Page class and each of the pages in our site extend the RestrictedPage rather than the .NET Page class. We have an enumerator that describes different levels of access that any particular page could have. A publicly available page might use "Public" whereas an information that requires a user to be logged in to view might use "UserRestricted".Then, on each Page_Load, we call a method in the RestrictedPage that loads all of the session data.For example:

public partial class AccountDetails : RestrictedPage{	protected void Page_Load(object sender, EventArgs e)	{		base.LoadSession(RestrictedPage.PageTypes.UserRestricted);	}}

This LoadSession method, among other things, verifies that the cookie is present, decrypts the data that is stored there to find the identifier, and then checks our session mechanism to see if various objects have been loaded. If not, we load those objects and store them in the session. If there is no cookie present, we either redirect the user to a login page or we show a session expired page, depending on the content.Then, each of the pages, after loading the session, has a reference to the user object that belongs to the RestrictedPage:

public partial class AccountDetails : RestrictedPage{	protected void Page_Load(object sender, EventArgs e)	{		base.LoadSession(RestrictedPage.PageTypes.UserRestricted);		LoadAccountDetails(base.User.UserID);	}	private void LoadAccountDetails(int userID)	{		// do stuff here...	}}

The final piece to this is making sure the authentication is set to None in the Web.config:

<system.web>	<authentication mode="None"/></system.web>

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...