How to choose between a library and shared project?

Question

I am working on a set of .NET Core 2.0 Microservices together with some other developers. I wrote some code to add my own custom logging as described here. My logger sends the logging messages to an external cloud based log system (so not the command line). I am now trying to find out where my code should be placed. The logging is needed for all Microservices.

One option is a library. This library can be called from all Microservices. This seems an obvious solution. The library needs to be compiled once and can be used everywhere.

Another option is a shared project. It is compiled as part of each project. This may seem a less obvious solution. The code needs to be compiled as part of each Microservice all the time. However, I see some obvious advantages of this solution:

1. A shared project has no references. Therefore the used references can not cause a version conflict with used references inside Microservices. They do not exist.
2. A shared project can also (well is likely to) be compiled as part of a future .NET Core version. The shared project does not have a .NET Core version itself so a wrong choice can not be made.

How should I make the choice and what it is the best solution for being future proof?

Answer 1

In my view there is rarely a good case for a shared project.

The main reason is versioning and change control. If you recompile source code, then strictly speaking you have a new version. Its not so much of an issue in these days of build servers and ci. But some of us will remember when building on a devs machine and copying to production was a normal thing. You had to worry which dev had compiled the code because the varying machine and compiler setups would change the resulting binary.

You should compile your library and version it. Then use that versioned binary in other projects via a package manager such as nuget.

If and when a new version of .net standard comes out you can update and recompile your library against that version. and have two versions of your library, one for each target.

If you fix a bug in the library, again publish a new version and you can check which of your other projects needs to be updated.