Share projects between Visual Studio solutions

This is one of the big questions of how to "organize" our "artifacts" ... which is the elixir of architects ;) There are many approaches and for each one, characteristics of the project as well as the "environment" must be evaluated ( project team, degree of volatility of requirements, how decoupled the components or modules are, etc) As @jasilva told you, as you progress in the project you can "explore these architectures" so that it is not an impediment at the beginning or worse that everything be delayed by having an "oversized" architecture for the first baby steps of a project... as they will tell you, you have to walk! (and so it is) but you can start taking some "practical improvements" from the beginning, which is what it is after all.

Well... we all start with projects "just for a client"! and they were growing to become some Software Packages to customize it by client or even as SaaS (Multi-Tenant). Where at each step you have to "refactor what is created and assembled" so that it can support the new customization requirements and request of several clients to the same module for example

Let's start... although a couple of years ago the only way to share was "referencing" today you have practical improvements with component packages (NuGet of the day you use it) and for example with DI (Dependency Injection) you can do the same without so much coupling , which after all is what we want to achieve in each "module"

recommendations

• Start as you can... with projects "referenced in the same solution". (as you were told it can be slow, unmanageable due to the number of files and the compilation process)
• If you have already been working on it like this... As it grows. Make them into components that you can decouple and install into each "client customization" as packages. Even here the advantage is that for each client you have the "version" that you use and thus you can add the version package to each client (separate project). EVEN theme related to styles and javascript (which you can also version in packages)
• Obviously here you would have to have an internal package server ( Hosting Your Own NuGet Feeds )
• When the modules grow one more step is to use a more adaptable publication, integration, installation mechanism (composeable) for that you can take a look at MEF ... to have components of your core "what plugins" That you can install simply by copying the corresponding assembly
• Although you can do the latter with Reflection (it is much more friendly with MEF)

Then you can have with the "modules" part what I commented above, with respect to CORE

1. OPTION 1: Have a single core and perform everything... web, api/services, SaaS which will make you think of always sending, for example, the "Connected" client to know the template or what modules it has enabled. Here is a single App that is "customized" by the "logged in" client (and you sell it as a Service or you install it individually). The good thing about this very easy to apply changes for everyone)
2. OPTION 2: Have several projects separated by client (you could even have a template in VS already pre-assembled) and insert them (the bad thing about the latter is for changes that are from the CORE it is more difficult to implement them in all)

Well... the recommendations

RECOMMENDATION 1: Modify behavior (plugins) with MEF

If I had to recommend something to you, it would be... MEF -Managed Extensibility Framework the idea is simple "to be able to inject modules/plugins just by copying or uploading an assembly" (you could even have a module server to add to your "core project" Like this you can use MEF in MVC

RECOMMENDATION 2: Separate packages (modules) in internal NuGet

Some components you could make "modular" and completely decouple them from your Core. To make them Testable above all and reusable... to do this you can create it in separate projects and alone and then share them at an enterprise level in your own package repository ( an internal NuGet ).

Well they are ideas and recommendations,

Links that can help or guide you

• MEF-Managed Extensibility Framework
• MEF-Managed Extensibility Framework
• Injecting MVC with MEF 2 in 2 Minutes
• ASP.NET MVC Extensibility with MEF
• How to use FEM in MVC
• Using MEF with MVC by defining a ControllerFactory
• ASP.NET MVC and the Managed Extensibility Framework (MEF)

This seems like a common dependency problem, what you want to do is "good", as you want to make core that has all the main logic, of a product, that looks like it will be sold to several clients as their own, but each one will have things unique.

This would leave you with an architecture similar to this

Where in main is all the common logic is in MAIN, and each client has a small piece of logic that is different from all the others.

Later in the project, each client will ask you for things that are only for him and you would have something like this

But you must keep in mind that MAIN will never be modified by the request of a client, when everyone needs something, it would be better to add it to main and send it to be called.

with the above

All the logic, including that of the N solutions is in the Main Solution, which the idea is that the N solutions refer to the DLLs of the main solution. Is this correct?

• Yes it is acceptable, but it is not easy, and it is much better than having N Solutions with copy/pastefunctionality that will be almost impossible to maintain

The problem I find with this is that if a client needs a specific requirement, what should he do?

• Add it in its own logic, with a condition, for example, a new query to extract the year's sales separated by fortnights , none of the other clients have requested it, but it could be that they will need it in the future, what's next? add functionality in MAIN and only reference it in client logic.

• On the contrary, if a client asks to change the x80 request that says that it consultaEjemploreturns Ait, that for all clients it is the same and it is in MAIN, but he wants it to return now AB, it must be overwritten in the client logic, without affecting MAIN .

Now, on the subject of how to organize the solutions in visual studio, I think it is a bit more subjective, since the one that each person likes the most should be used, for example:

You can have a super solution, with your 1000 DLL's that have all the main Logic, and each client's mvc and web api project, perhaps with their respective DLL's

Advantage:

• Everything is in one place

Disadvantages:

• The loading of the project will be slower (The intern's laptop with 1 GB of RAM will not load the solution XD )
• Code control (say git , tfs , etc) might not be the most appropriate, when someone makes a commit, meaningless things might be referenced, making it a bit difficult to track commits
• All programmers have access to the main code, and can damage or steal it

You can have a core solution and a solution with all mvc and web api projects.

Advantage:

• The loading of the solutions is better than in option 1
• A programmer who does not have to modify the main code will only use the client solution, and the main code will not be at risk.

Disadvantages:

• Requires setting up two repositories for source control instead of just one

You can have a core solution and have as many solutions as you have clients, with their mvc and web api projects and maybe DLL's.

Advantage:

• A programmer who does not have to see the code of client A, because he only works for client B, will not be able to do it since he only needs the solution of B
• Solution loading is fastest

Disadvantages:

• You need many repositories or alternatively sub-repositories, or some other source control strategy, however this option is the most difficult to configure.

So as you can see, it depends a lot on how you organize yourself, on the security methods you want to have, or the ease of configuring environments, it is most likely that I have missed some other advantage or disadvantage, but I am sure a fellow OS in Spanish, it will help us.

You will always find a thousand different ways to approach this problem, I share with you the result of my personal experiences, some in agreement with other exposed alternatives and others in total disagreement.

In large corporate projects, especially in multi -company ones, you will always find this scenario.

Typically, customers demand customizations according to their needs and this is where physical, logical and process architecture decisions are of vital importance.

My recommended solution is listed below as

Multi-tenant application, and the world of software as a service**

For now here are my notes.

Multiple projects or solutions, 1 for each client.

It is the worst possible solution, the more projects the solution has, the slower the loading and compilation process will be. This alternative seems to be good but it is really creating a lot of collateral problems especially code redundancy . Over time it will be inevitable that this will happen and there will be no methodology or process that will prevent it.

You can try to keep some core projects that are 'untouchable' and only have a few customizable for each client, but as the solution grows you will see how, due to very specific needs of a specific client, you will begin to have core code leaks to migrate them to each client.

Solutions through design patterns and dependency injection

This approximation is a little better, a good architecture and implementation of design patterns can decouple your code a lot to get to have a highly customizable solution where by means of configuration you can establish the resolution of object instances that have the logic determined by each client. .

You will not need to open multiple projects but rather create custom classes according to the needs of each client, and then in the installation process for each of them modify the configuration of the application so that each client uses the objects that are relevant.

The catch with this methodology is that your app tends to get bigger and messier over time. Each new client may require endless configurations for dependency injection and in the end, despite the high technical value of your application, the level of entropy and maintenance effort will be high, this last part in particular is the typical scenario of an application with a high technical value but a great complexity in the code which will make it difficult to maintain the application during its life cycle.

Versioning per client

You can create a new branch of the application for each client, in this case you would have a single solution and set of projects, but every time you have to make a change outside of the standard, you create a new branch of the application.

This will give you the flexibility to apply changes or new features only to a certain client without creating a set of different solutions or projects (although they will be in the long run).

In this way you must maintain a main or core branch, with the application in its standard version and ensure that each change is replicated to all branches and then customized in each branch as necessary.

In any case, although you get rid of projects with great complexity due to the exaggerated use of patterns and dependency injection, and compiler problems by having solutions with multiple projects, in the end you will have a fairly complex issue to manage with the theme of versions opening the way to many errors and 'strange' differences between one branch and another.

Despite this, it is one of the most widely adopted solutions by software houses.

The plugins / MEF

It is an excellent alternative, which also gives a lot of flexibility in the middle of a widely tested framework.

However I wouldn't recommend it as much for LOBs, although it works. Because given the number of possible changes, the complexity of the application will overflow and the number of plugins could bring you some performance complications. Just take a look at how Visual Studio behaves when you have a lot of plug-ins or extensions installed.

Multitenant application, and the world of software as a service

For modern times this is my best option and by far! If your application is flatly multi-client, you should think about why you have to install your application on each client if you can probably offer it as a service in the cloud, reaching more clients and with considerably better implementation and maintenance costs.

The point is that even if you don't want/can/know how to sell your application as a cloud service, this same multi-tenant architecture will give you huge benefits when building and maintaining your code base.

What you have to do is build the application as if, in effect, multiple clients connected to the same instance.

This implies that your application must behave in different ways for each client, but since it knows that situation from the beginning, such customization is achieved by configuration parameters interpreted from the code, not asking why the client is connected but what configuration features are available. established for this specific customer.

So in your code you would have something like this

//Cargar configuración del cliente, en una LOB grande
//estos suelen ser parametros en una tabla de la BD
//usualmente solo se hace el cargue cuando el usuario 
//inicia sesión
var ConfiguraciónCliente = CargarConfiguraciónCliente();

If(ConfiguraciónCliente.PagaImpuestoIVA)
{
   FacturarIVA ConfiguraciónCliente.PorcentajeIVA);
}
elseif (ConfiguraciónCliente.ObligadoaDeclararRenta)
{
  DeclararRenta():
}