How do I properly split large interdependent projects and maintain simple workflow?


  • Hey guys, not sure if there is a better forum I should have selected for this; its an all-around question for a complicated project.

    I've got an old .NET 4.6.1 solution (upgraded all the way up form VB6 originally, at least 17 years old).  We are trying to migrate away from direct DB access to a bunch of .NET Core microservices.  Between microservices, client libraries for those services, etc, the solution has grown to a good 60+ projects.   We would now like to break this solution up for both speed, our own sanity, and for automated building using jenkins and 1 git repository for each major deployable artifact (so application, web services, etc, some git repositories may build multiple shared libraries however)

    I'm sure others have had to deal with this, I'm running into a few issues.

    First, this new broken up model works great for the build server / automated deployment processes we are implementing.  It is terrible for locally hosting it on a developer box and walking through debugging things; as well as locally editing where you may need to make related changes inside several projects.

    My thought was to create a solution for each repo covering its specific projects and use that for the build server, and then another solution that references all of the individual project files (assuming everyone checks them out to the same folders), and makes it easy to work with as a whole within Visual Studio.   

    The second issue is references.  There are a lot of inter-dependencies.   We have a private Nuget server, so I was planning on utilizing that.  However, now the "big solution" to make local debugging easy fails, because now I would have to check in shared library code, wait for it to compile on the build server, update my nuget references... just to debug or develop the changes in the next part of the project... and because the next part of the project hasn't been updated to work with that library change yet, you have now checked in a library that could cause other related builds to fail.   I thought well, you could do two project files... one on the build server that uses Nuget, one locally that uses local references.... but who on earth would keep the two of them up to date?

    So, with all that said, this can't be a unique challenge to me.  I'm sure other people have had to solve similar issues.  Could someone please share what they have done?



    Monday, April 17, 2017 2:46 PM

All replies

  • Hi TascDanG,

    According to my understanding, when we have the following circumstances, we can consider split large interdependent projects.

    *have a plugin architecture
    *libraries to be used in different places
    *work in multiple languages
    *deploy assemblies separately

    If a component is used by other programs: The recommended way is to put interfaces of the referenced stuff into a third project.

    According to your description, I suggest you can try to use TFS(Team Foundation Server).

    Team Foundation Server provides a set of collaborative software development tools that integrate with your existing IDE or editor thus enabling your cross-functional team to work effectively on software projects of all sizes.

    You can also visit the Team Foundation Server forum for getting further support.

    Best Regards,

    Yohann Lu

    MSDN Community Support<br/> Please remember to click &quot;Mark as Answer&quot; the responses that resolved your issue, and to click &quot;Unmark as Answer&quot; if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact <a href=""></a>.

    Wednesday, April 19, 2017 7:22 AM