Team Development Environment for .Net

Question

I've just joined a new company that has recently switched development from PHP to C#/.Net Core. They're writing a new CMS from the ground up in this new environment.

Before me, there was only one developer working on this new system, and he set up a system that is rather hard to work with. I'm trying to think of ways to improve it, but have trouble finding information about the capabilities of the various tools involved.

Warning: Long description/rant incoming. TL/DR: current system makes day-to-day development very inefficient. If you want, you can skip to the concrete questions below.

Our current setup works like this: the system is split into a core part and customer-specific parts. Each part is further split into a number of small projects according to logical divisions of responsibilities. So far so good.

Each of these projects is in its own individual Git repository and consists of a single solution that usually contains two projects, one class library containing the functionality, and one unit test project. (Occasionally there is more than one such pair, but I consider that an accident.)

The Git repositories are hosted on a TFS. The TFS automatically builds each solution as commits are pushed, and publishes the result of the build as a NuGet package. Dependency between the various projects are handled exclusively by NuGet dependencies.

There's a number of problems with this.

When I need a new feature, necessary changes are often split across a number of projects. Because the CMS is very young, many new features require additions to the core; in addition to that, a new feature may well require changes in multiple projects of the customer-specific parts: the view-controller layer (one project), the systems layer (another project), and some data layer (yet another project).

Because of the way the dependencies work, to achieve this I need to change the project at the end of the dependency graph, commit and push, wait for the server to publish the new package, refresh the next layer, make the changes there, commit and push, etc., until I reach the final layer. At any point in this process, the world build may be broken if I changed anything in an incompatible way.

As you can imagine, this is an incredibly inefficient process. Also, if at any point I realize that a change in the lower layer was incorrect or insufficient, I have to start the process over. This means I can easily accumulate Git commits that are not actually a useful state of the system. What's even worse, if I want to try something out in a lower layer (e.g. add some debug output), I actually have to commit this and push it to the official repository to get a build, then later add another commit that undoes the effect.

Furthermore, because every little project is in its own solution, I have to open each in its own instance of Visual Studio. I currently have 6 instances running. Finding the right one for a job is sometimes confusing. Also, because of the way VS configuration works, any change I make (e.g. layout of tool windows) is at risk of being overwritten if the instance I made it in isn't the last one being shut down.

Finally, because the NuGet packages being built are release versions, debugging through the stack is suboptimal. (Also, we currently don't have symbol information or sources in the packages, so debugging is completely impossible, but I know how to fix this particular problem.)

Questions

1. Is there a way to have both the NuGet dependency setup for CI builds, and a single-solution project dependency setup for developer builds?

2. Is the usage of NuGet here even useful? Is there a better way to compose projects that span a number of Git repositories?

3. Is there a way to have a developer-local NuGet repository that overrides the server in a predictable way, where builds are automatically pushed to with a good version number? I'm rather worried about synchronization issues when two developers work on the same repository concurrently.

4. Would it be a strong benefit to merge into just one Git repository for the core and one per customer-specific stuff?

Or to put it another way, what is a good development setup in general? Unfortunately this is the first time I'm working with .Net development either, so I'm lacking in experience in general.

Answer 1

It sounds to me like this has been setup very well.

There are a couple of things you can do to make your day to day dev life easier.

Problem 1: having to publish nugets before they can be used in dependent projects

You can manually publish a pre-release nuget from a local build by appending -beta to the version number. Dependent projects can then be updated to use this pre-release version and tested, before you commit a 'real' version

Alternatively: Package your test nuget on your machine and copy to a directory. set this directory up as a local nuget repository in VS

Alternatively: you can change the reference in the project to the dll you have locally

Problem 2: debugging release compiled nugets.

Ideally here you should never have to do this. Write unit tests in the nuget project to ensure it functions correctly

However, you can compile a debug version and use as pre-release or pop it in your local nuget repo

Answer 2

1. If I understand what you are looking for correctly there is a tool called SlimJim that helps deal with that by modifying the solution with all of the constituent packages replaced with their project references.
2. It means you can have different customer specific parts depend on different versions of the core. If you don't want that it probably isn't helping you. You could try submodules or subtrees but I don't think they would be helpful in this case.
3. You should not be publishing to the central feed from your local workspace. You can host a package source out of a local directory. The specifics vary depending on what version of Visual Studio you are working with but this article should get you started.
4. There could be, it seems like you are using the project structure of a much larger application for your fairly new and currently small application and it's causing excess overhead.