1

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?

  • 1
    What sort of reference conflicts might exist between a shared library and your project? Is this even likely? Would making the logger a NuGet package solve some of these problems? – Robert Harvey Oct 21 '17 at 14:38
  • The more libraries you have, the more assemblies you reference (libraries usually have assembly references). Assembly references can cause conflicts like this: google.nl/… . Shared projects do not have references, so their references can not cause issues like this stackoverflow.com/questions/19682660/… because they do not exist. – Daan Oct 21 '17 at 14:46
  • The problem is likely (after googling and own experience I found out people really have that) and the stackoverflow example is nuget based. – Daan Oct 21 '17 at 14:54
  • 1
    Well, unless the logger is your only shared library, this doesn't completely solve potential reference conflicts. I'm not sure chasing a problem that hasn't happened yet is the best strategy. Conflict resolution has gradually gotten better over time, and the reference resolution strategy in Visual Studio 2017 has improved significantly. – Robert Harvey Oct 21 '17 at 15:35
  • Visual studio is not used by all team members and is not mentioned in my question for good reasons.. And we consider making the logger the only shared library. So in this case, a shared project is preferred? Does it have a disadvantage I did not mention? – Daan Oct 21 '17 at 16:00
5

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.

  • 1
    I would like to say that you helped me with your arguments. However, there are really good use cases for a shared project but these do not apply to my question. If you want to develop a library that supports .NET Framework (without .net core sdk installed) and .NET Core, then a shared project is the way to go. .NET Framework without any addition is not supported by the most obvious choice: .NET Standard docs.microsoft.com/en-us/dotnet/standard/net-standard – Daan Oct 22 '17 at 18:37
  • even then I would simply compile the project by itself twice, producing a .net standard and a .net framework version and use those binaries, rather than share the code across multiple projects. A shared project which isn't shared if you will. – Ewan Oct 22 '17 at 18:46
  • Could be an option. For me a .net standard and a .net framework version would be over complex but that is a personal preference I think. – Daan Oct 22 '17 at 19:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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