As @[email protected] said you can use multiple configuration providers. We usually have local appsettings.json files, even per machine appsettings.<HOSTNAME>.json and then use Environment Variables that are stored in a vault for the production environment. We add the appsettings.<HOSTNAME>.json files to .gitignore so that they don't get checked in.

    var env = Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT");
    configuration.AddJsonFile($"appsettings.{env}.json", optional: true, reloadOnChange: true);
    configuration.AddJsonFile($"appsettings.{Environment.MachineName}.json", optional: true, reloadOnChange: true);
    configuration.AddEnvironmentVariables();

Then you can provide the secrets as environment variables in the form of DATA__ConnectionString

Good thread about Dotnet people on Mastodon

https://dotnet.social/@SmartmanApps/110648925352232498

When you are developing a UI library (as we are) we want to support the old API for some time and mark is a deprecated. So one would add a second @Input() of type ScheduleEvent[] leave the old API be as Course[] and mark it as deprecated. In the next major version you could then retire the old API.

Yes, you are right. Long living branches are the problem.

In this case it is a completely new project in the workspace (of course depends on the library in the workspace). It is a POC that has been postponed again and again by the customer due to priorities.

I think it's probably best to isolate the branch and take it out of the workspace. When it is ready, we can integrate it back into the workspace.