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.

Good thread about Dotnet people on Mastodon

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

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.

As @nibblebit@programming.dev 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