Strategy to manage multiple apps with common features

If the common features do not affect the API between services you can just develop an internal library, deployed with nuget, that is used by all the services. If services happen to use different versions it should not be a significant issue since the APIs remain the same.

If these common features do affect the APIs, are you sure microservices are the best solution for your particular problem? A core tenet of microservices is independence and independent deployability. This makes changes in the APIs between services intentionally very costly, since services are required to maintain old APIs for some time. If the common features are placed in a library each service would need to simultaneously use multiple versions of that library to maintain the old APIs, and that sound very difficult and costly to me. And that assumes all services even use the same language.

Microservices mostly benefit very large organizations with hundreds of developers. If you are that large, should you not ask your colleges instead? If not, are you sure that independent deployability is worth the cost? Perhaps it is better to design a more conventional application that is deployed all at once? All at once deployment makes your problem so much easier since you can just use a common library. The project may still use separate services where it make sense, but it is perfectly possible to keep a clean separation between components in a single application, see "modular monolith". And modern servers should provide plenty of vertical scaling if needed.

[...] but with microservices each new app an issue would be overhead to do.

I'm sorry, can you clarify what this means? Are you saying that logging one issue per app would be too much overhead? And what do you mean by "app"? Are you using "app" in the sense of a web app, Andoid app, and iOS app? Or are you considering each microservice an "app".

Unfortunately, the word "app" can be quite ambiguious.

Use a shared packages concept in NuGet, as mentioned earlier. Create a separate NuGet dependency that holds the common functionalities - let's say http clients, logging, db access, infrastructure setup or whatever will be applied all over the place. That is the way to go.

1. Use NuGet
2. Use GitHub packages.
3. Use whatever distribution your company is into.

My mistake, what I meant was that our .NET apps

If the functionality is truly common between the different services then it sounds like creating NuGet packages to contain it would be a good approach. If you're using deployment tools then you can have minor version updates get pulled in automatically during build so you don't have to make commits across all the services that use a package.

The challenge of course becomes ensuring that you're not making breaking changes when you update the shared functionality. Having backwards compatible changes and using the [Obsolete] attribute properly will help mitigate bugs appearing due to a package update.

Greg's asking what kind of app it is, not what technology it's written with.

A ".NET app" could still be a web app, web API, Android app, iOS app, desktop app, background service, console app, or whatever else you can think of. .NET provides the ability to create all of those. So, saying it's a .NET app doesn't really answer Greg's question! We already know you're implementing in .NET, as you mentioned that originally :-).