Accessing appsettings.json from startup.cs of another project in .net core 3.1 - config

I have two projects: webAPI and IdentityServer4. these two projects maybe deployed on different physical paths.
I want to read appsettings.json of the main webAPI project and use those connection strings etc in IdentityServer4 project's startup.cs. the solution is in .net 3.1.
There is a config class in a class library of models.
Having a hard time being able to read appsettings.json.

Related

Externalize the Configuration (appSettings.json) file in ASp.NET Core 3.1

I have developed a default Web API project using .Net Core Web API template. I would like to externalize the appSettings.json file to some other location instead of the default root location.
Below is the piece of code that I'm using.
I'm not able to read the settings from the Config file. Is there a way to retrieve them?
Thanks,
Praveen

Read configuration from a specific file - Web.config or appsettings.json based on the calling web application

I have a monolith project and I'm trying to convert one Web Application from ASP.NET to ASP.NET Core with Full Framework.
As you can see from the figure, both Web Applications are referencing Class Library 3. CL3 contains Business Logic but also logic about how to read specific configuration (till now from Web.config file).
Since the way to read configuration has changed in ASP.NET Core (appsettings.json Environment based) I have to rewrite the part that reads the configuration from CL3.
Is it possible a scenario like this?
#IF CALLED FROM ASP.NET
RETRIEVE CONFIGURATION FROM WEB.CONFIG
#ELSE (CALLED FROM ASP.NET CORE FULL FRAMEWORK)
RETRIEVE CONFIGURATION FROM APPSETTINGS.JSON
If you are refactoring, try to move configuration reads out of the shared DLLs and provide a clean abstraction that does not have hidden dependencies on framework-specific assets.
Your ASP.NET Core Application and classic ASP.NET Applications could create a config based on their config system (you could provide two different config implementations) and then use your CL3's classes and pass in configuration objects.
Alternatively, you could use a ConfigurationBuilder to read AppSettings and connection strings from appsettings.json and appsettings.{Environment}.json and make it available through the classic ConfigurationManager API. See this blog post for details on how to do this. This can be extended to configuring custom configuration sections (classic .NET) from json files.

ASP.NET 5 , wanted to separate entity framework from Web Project

I'm trying to achieve below application structure
App.Model
-- UserModel
-- OrderModel
App.Service
-- UserService
-- IUserService
App.Entity
-- DbContext
Website
-- WebAPI
-- Invokes Service
Most of ASP.NET 5 application examples , initializes entity framework in startup file of website. like .AddEntityFrameowrk() .. etc.
Need to know how we can separate the Entity into separate project and how do we initiate the DBContext if we are invoking repository from Service project.( since startup file is not available for class library)
In previous projects, I have taken the approach of maintaining multiple ASP.NET projects in one solution (or multiple solutions). This will give you the ability to remove the EF dependencies from your web application and have the web application talk only to the API which handles all the EF
In the past, I've created a dedicated 'domain' project which contains all the models and can be referenced by both your web application and API projects.
So the project structure would look like this
Domain project: Contains only c# classes that represent your model. Start with an 'empty' project
API: Contains your web API. Uses EF to interact with database. I would personally scaffold the APIs fro your model but that is a personal choice. Right now, in ASP.NET core 1.0 RC1, the web api template is poor so I'd start with the full 'web application' one and remove all the default views, controllers, scripts etc. References the domain project so that you can scaffold your API controllers from the model
Web Application: Your main web application project. Start with the 'web application' template but use HttpClient I your controller to use the api for data interactions. In the past I've created a set of static 'api helper classes' to make this task easier but that is a personal style choice again. References the domain project so that you can convert incoming JSON responses to the full .net model

ASP.Net Web Project Deploy with Database Migration at Different Project

Our solution contains (basically) 3 different projects.
Web Api
MVC
DbCore
Domain
Web Api and MVC projects are (as you can guess) web projects and DbCore and Domain are Class library projects.
DbCore contains Entity Framework definitions, configurations also migrations.
Web Api connects DbCore through Domain.
This infrastructure works well but i want to deploy and apply migration db while deployment. But deployment wizard doesn't show me option about that because web projects don't contain any DbContext definition.
How can i achieve this?

Equivalent of WCF UriTemplate in ASP.NET MVC4 WebApi

Am migrating a WebApi project (from preview version aka WCF WebApi to final release aka ASP.NET MVC4 WebApi).
In WCF WebApi, URI templates were defined for all services operations, like:
[WebGet(UriTemplate = "{movieGenreId}/movies")]
Bare I mind I have tens of those in the project. How do I translate this to MVC4 WebApi without having to register tens of entries in the Route table?
You could go with the excellent attribute routing for Web API project:
Here is the source on GitHub (both MVC & Web API) - https://github.com/mccalltd/AttributeRouting
Here is a short intro to attribute routing in Web API - http://www.strathweb.com/2012/05/attribute-based-routing-in-asp-net-web-api/
Here is the Nuget for the attribute routing Web API package - http://nuget.org/packages/AttributeRouting.WebApi/3.1.2
It should be almost as easy as search and replace to convert UriTemplates to Attribute Routing.
If you are not willing to include the attribute routing library in your project, unfortunately the only other way is - as you said - registering tens of routes.