1

We have a team of 5 developers working on a product and are at a crossroads trying to determine a better way (if one exists) of managing development workflow and project dependencies. We currently have two solutions, Core and Client. Core references 8 projects as dependencies (not via NuGet). Core is essentially an admin UI and REST API. Client, is a project template that will be replicated every time we have a new instance that needs to be customized. Client references 4 of the same projects that Core does. Again, both are solutions (.sln's) and both directly reference dependency projects.

For local development, developers currently branch from two separate repos - one for each solution. The developers' local environment must be set up so that the Client can properly call the REST API locally. Local dev often requires changes to both Core and Client in order to test new features, etc.

Our issue is that at times our changes do not build on other developers' systems due to differing repo locations on the file system. This causes issues with the path to projects in the solution files and creates a lot of unnecessary extra work and frustration.

We are considering moving to a NuGet workflow (local, Test, and Prod NuGet servers), but that seems like a lot of extra overhead for the payoff. Can someone recommend a better solution for local, test, staging, prod development workflow for our small team?

Improve this question
5
  • 1
    Can you address the concern I raised on Stack Overflow, and tell me why your developers are sourcing from different repo locations?
    – Robert Harvey
    May 26, 2015 at 21:45
  • We use two separate Git repos. The Core project contains the majority of the projects, but not the Client. The Core repo covers all code except the Client and the Client repo only contains the UI/Admin for the template that other Client sites will be built from. Since the Client is really a template for future projects, we don't really want to store everything in a single repo. I suppose we could, but it didn't seem ideal at the time.
    – joeldow
    May 26, 2015 at 21:48
  • 1
    My instinct says that this is a small management problem with your repos, not a complete overhaul of your source control system.
    – Robert Harvey
    May 26, 2015 at 22:05
  • I am not looking for a source control resolution. I'm trying to find a better way to organize the solutions themselves. I will rephrase my question to get rid of the ambiguity.
    – joeldow
    May 26, 2015 at 22:28
  • @joeldow: maybe you did not read my comment below, so I try to use different words: please give us some more details, or an example of the path resolution issues you face. From what you wrote it is really hard to tell what your actual problem is.
    – Doc Brown
    May 28, 2015 at 5:53

2 Answers 2

Reset to default
1

A classic problem - the simplest resolution is to do what everyone does, treat your Core product as a separate product, similar to how you'd treat an open source project you were reusing in your product.

For example, I use log4net in my product. I don't have a copy of their source, I only take the latest stable dll and use that directly, putting it in a '3rd party libs' directory that I know the location of. You can do this with your Client projects that use the dlls from your Core product.

If you are sharing source code between these projects then you're in a world of nuisance, I would combine the repos together in such a case, or put the shared code in a 3rd repo that both your main projects use. This isn't ideal but can work well - I've done such things with C/C++ projects in the past where a common /include directory was used, by building the dependant project it copies the source into this directory. Visual Studio's C# system isn't so friendly towards source code that is external to the project root though, so I wouldn't recommend this for C# (which is a shame that C# is so 'blunt-scissors' in this regard).

Improve this answer
2
  • Why wouldn't you use NuGet for third party libs? NuGet resolves the external dependencies issue. Core needs to follow a separate development path from Client, so it makes it tough for us to put them in a single repo.
    – joeldow
    May 27, 2015 at 14:39
  • You can certainly use NuGet... so why don't you? Oh, wait you already said why not. You can just checkout and build Core locally as needed, which is probably just as good and much easier until your system gets so complex that the management overhead of Nuget (or other build-server based system) becomes worth it.
    – gbjbaanb
    May 27, 2015 at 16:16
0

The repo location on the file system should not cause issues with the path to projects in the solution files. The latter should only depend on the locations of the working copies - maybe you mixed that up?

However, if I have to guess what's really going on, the solution to your problem is probably: relocate your projects so all references are relative paths to each other. So it should not matter where they are checked out on the file system as long as their relative location is the same. This must be true for your Core and your Client solution in combination. If you need to have different branches in parallel on a local workstation, have a local "root folder" for each branch, containing always both Core and Client solutions of that branch.

Improve this answer
2
  • Even with relative paths, if developers have set up the local repo folders incorrectly, the solution will not find and build the solution properly. We may need more of a procedural solution than a technical one to make sure all developers follow the same protocols.
    – joeldow
    May 27, 2015 at 14:27
  • @joeldow: well, you did not provide the details about what exactly is going wrong, only some very vague statements, so it is hard to give you a more specific advice. But as a general strategy, if there is room for manual errors, eliminate the manual steps, for example, by providing scripts for setting up things like "local repo folders" correctly. I would probably first start making a short checklist how to setup the environment correctly, and afterwards check if the checklist or parts of it can be encoded as scripts easily.
    – Doc Brown
    May 27, 2015 at 15:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.