Clever Geek Handbook

How to set up a control source with multiple products that depend on the same class library

I am the CTO and the only developer for my company. I am looking to hire our first developer and possibly a second one within the next 6-12 months. I am embarrassed to say that I have never used source control as part of my workflow. I think the 1 member development team allowed me to be a little lazy. This is not something I didn't want, I just have a little mental block on how to start with it.

We have 5 web applications that I create and maintain. We are using ASP.NET, and each web application references a single .NET class library (DLL) that was copied to the bin folder for each application. I developed with one solution "Visual Studio" which includes the class library and all web applications. A bit bloated I'm sure, but this method made it easier for me to minimize errors by allowing me to perform global find and replace operations on all my applications (and class libraries) at the same time.

I understand that the introduction of source control is a big change in my workflow, but the introduction of another developer into my process surprised me a little. I'm looking for some help on how to design a workflow that allows my small team to move quickly without cumbersome processes. I would like to avoid discussing which SCC system to choose (we'll be using Mercurial). I'm more interested in discussing aspects of structure and workflow.

Here are the questions I need help with:

  • Should I split each application into a separate "project" or save everything together so that we can continue to use global find and replace operations as needed. I'm worried about splitting them due to the class library situation (see # 2).

  • If I split my applications into separate projects, I'm not sure how to continue the class library, each of which needs to be copied. For example, let's say that a change in one of the applications (call it "project 1") requires a change in the class library ... if the class library is in a separate project (call it "project 2") it seems "messy" to me that project 1 will depend on the latest changes in project 2 to work properly. Or just make changes to project 2 (class library), check them, and then copy the newly compiled dll to project 1 (but no new copy of the DLL copied to SCC project 1 should be written somehow). I feel embarrassed even as I write this ...

Thanks in advance for your help.

+2


source to share


2 answers


First, congratulations on your final decision to use version control. I know changing your habits can be frustrating, but ultimately I'm sure you'll see the benefits.



  • There is nothing wrong with a solution that has multiple projects. I usually keep mine until about 10, but that's just to increase load times. If keeping them together is best for you, leave it that way. Using source control will not affect this.
  • As far as the class library is concerned, I think you need to change the way you make changes to the library project, not how to use the projects that reference it. Unit testing your library project for backward compatibility so you know that removing the latest version of the library won't break your application. You will most likely find this to be wrong a few times, but as you develop more unit tests to handle cross-cases this will happen less and less.
+1


source


You can have multiple projects in one Visual Studio solution. What I have done in the past is an ASP.NET project and a class library project in the same solution. You can link to the ASP.NET project of the class library project (Add Link and then go to the Projects tab to show other projects in the same solution). Therefore, when you change the class library, the ASP.NET application will be built using the latest version of the class library. You can configure multiple solutions - one for each ASP.NET application with each solution, including the libary class project.



You can also set up one big solution with all of your ASP.NET projects as well as the class library, but they can be tricky to work with, especially with multiple developers working on different ASP.NET pages.

0


source






More articles:


All Articles