I'm in the process of moving the UI side of an application to the new ASP.NET Core MVC structure. Unfortunately, I still need to reference a data layer which is built in the prior-generation ASP.NET framework. This data .dll has the appropriate connection strings to various databases all being managed by ConfigurationManager.ConnectionStrings["ConnectionStringName"].ConnectionString which required me to mimic in the UI layer in order to actually get at the data.
Now, with ASP.NET Core MVC, the web.config for configuration has been replaced with the appsettings.json file.
That paradigm shift breaks all my access to data since I can no longer replicate the connection string in the UI application.
Is there an appropriate solution that can make this data layer .dll more self-contained and rely on its own, internally defined connection string(s), while still exposing the Methods to the "containing" application - in this case, the UI layer?
I have resolved my issue with a work-around, and it will do for now. Ultimately, I'd like to find a better option, but I'm moving forward which makes my boss happy.
I ended up changing my method signatures to accept a string value representing the connection string that's no longer in the calling project because of the conversion to Core MVC.
In the called .dll, the code now looks to see if there is a value to the passed parameter, and, if so, uses the passed value to initialize the SqlConnection. If no parameter is provided, it will look to the config section in web.config using the ConfigurationManager capabilities.
This will allow the existing project to use the code, as well as the new Core MVC project. It's a bit kludgy, but functional.