I would recommend one chart per service. The place where helm dependencies work well is where you have a service that embeds/hides specific single other parts. And as @christopher said if your .NET service and MongoDB have different lifecycles, they shouldn't be packaged together in the same helm chart.

The most basic way to use Helm is by having a single chart that holds a single application. The single chart will contain all the resources needed by your application such as deployments, services etc.

Chart versions and appVersions

The version of the chart itself (version field in Chart.yaml). The version of the application contained in the chart (appVersion field in Chart.yaml). These are unrelated and can be bumped up in any manner that you see fit. You can sync them together or have them increase independently. There is no right or wrong practice here as long as you stick into one.

An important point here is that you need to adopt a policy in your team on what a “chart change” means.

Helm does not enforce chart version changes. You can deploy a different chart with the same version as the previous one. So, if this is something that you want to do, you need to make sure that all teams are on the same page for versioning practices.

On the plus side, this workflow allows you to individually version charts and applications and is very flexible for companies with teams that manage separately the charts from the application source code.

Umbrella charts

However, you can also create a chart with dependencies to other charts called umbrella chart.

They are completely external using the requirements.yaml file. Using this strategy is optional and can work well in several organizations. Again, there is no definitive answer on right and wrong here, it depends on your team process.

Take a look: umrella-charts-example.

In other words, a collection of software elements that each have their own individual charts but, for whatever reason (e.g. design choices, ease of deployability, versioning complexities), must be installed or upgraded as a since atomic unit

An umbrella chart references the version of the Helm chart itself and not the underlying version of the container image. This means that any change to the image version will result in chart modifications to the individual component charts.

What to take into account when deciding on an option

There are two dimensions to take into account:

• Team structure: You have to ask yourself questions like: do you have small autonomous teams that are responsible for each service? Do you have developers who have knowledge of DevOps?
• Dependencies and reproducibility: You have to ask yourself questions like: How different are the dependencies for each service? What is the risk that a change to one service will break another? How do you reproduce the conditions of a specific development?

Read more in useful article: helm-managing-microservices.

Speaking about versioning of microservices for backward compatibility, see Product Versioning Microservices, in general Semantic Versioning is generaly adviced.

In the broader sense - there should be an agreed phase-out roadmap for major versions, that is communicated to API consumers (together with SLAs). This is why tracking who uses your APIs is important. Take a look on this useful article about versioning management.

See example tool for tracking microservice versions- DeployHub.