I am migrating a legacy .NET framework application to .NET core and on to .NET 5 and ran into an interesting issue. We have a shared library that multiple projects use for database access and business logic. One of the main problems is that one of the projects that uses this library is an .NET framework MVC website and this website doesn’t support .NET Core. This means that I cannot use Entity Framework Core until the website gets updated to .NET Core.

In the meantime, I migrated a smaller application as a test run to find any “gotcha’s” before we try migrating the larger website. The smaller application that I migrated was a .NET 4.8.1 windows service to a .NET 5 worker service. Things were straight forward until I ran into an issue where Entity Framework 6 automatically loads the connection string from the older .config files instead of the newer applicationsettings.json. At first, I was trying to figure out how to get the config files to transform like they did in .NET 4.8 so that the problem would resolve itself. However, I didn’t really find a good way of doing this.

I was also not happy with the idea of passing in a connection string every time I created a new call to the context. This would require rewriting a lot of constructors to pass the connection string down, and seemed like a lot of extra work for something that I could simplify again later when I upgrade and can load the connection string from the applicationsettings.json file and inject it into the context when I am able to upgrade the library.

The simple work around that I am using until I can upgrade the library is to inject the configuration into my worker service and load the connection string from that. Then I can simply update the connection string in my repository that is used.

 public APHIDWorker(
            IProcessRepository processRepository,
            IConfiguration configuration)
        {
            _processRepository = processRepository;

            string connectionString = configuration["Connnectionstrings:MyDBConnection"];
            _processRepository.ChangeConnection(connectionString);
        }

Not necessarily an ideal solution, but I think it is temporary solution that will work until we can finish migrating our library. Once we do it will require very minimal work to fix the temporary solution and get it up and running quickly.

Have any other good ideas we could use? Let me know in the comments below.