I have two projects targeted .net 6 and there are no any explicit declarations for using user secrets (I remember, it was required in previous versions to use AddUserSecrets()). Though, one project gets the right config from secrets.json, but another one - tries to get it from appsettings.json.
So, I'm wondering, what's the issue? How the behavior was changed in .net 6?
In .Net6, WebApplication.CreateBuilder initializes a new instance of the WebApplicationBuilder class with preconfigured defaults. The initialized WebApplicationBuilder (builder) provides default configuration and calls AddUserSecrets when the EnvironmentName is Development.
As long as you initialize your web application using the WebHost.CreateDefaultBuilder method, ASP.NET Core automatically picks up your configuration from the secrets.json file in .Net6. If you initialize your application manually or not .Net6, make sure to call the AddUserSecrets-method.
refer to this
Related
I am using Serilog in .Net 6 WebApi and the required serilog settings, including default logging level and few overrides, are currently being set via appsettings. However, I am looking for a way to dynamically add/remove logging level override for additional namespaces during runtime so that I can capture additional logs on demand for troubleshooting issues, without redeploying the application with setting changes. Is this possible? Any guidance available on how this can be achieved?
Thanks!
You can implement a custom configuration provider in .NET Core which reads the configuration from Database. And you may need to implement Reload option as well. So when you update the database - your configuration will get updated. Here are some references which may help you.
Implement a custom configuration provider in .NET
A Refreshable SQL Server Configuration Provider for .NET Core
Creating a custom ConfigurationProvider for a Entity Framework Core source
I've got a webapp for containers running in Azure that I have working locally with a local appsettings file.
once I deploy to Azure, I want the container to pull appsettings values from the azure settings. These are set via AzureDevops and appear correctly when I check the portal.
However, the site is not pulling the appsettings values from Azure once deployed. It is using the ones from the file. I am using the double-underscore names as specified.
I have created a testcontroller to output the appsettings values. This is an a snippet of what the test view outputs:
Build version: 2019.1.23.1
Location: local
Database__DatabaseConnectionString: Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=application;Data Source=.
---
-------
Env vars: Key WEBSITE_AUTH_SIGNING_KEY Value ASDS*(&*&*(SDSD05C29
Key DOTNET_RUNNING_IN_CONTAINER Value true
Key WEBSITE_ROLE_INSTANCE_ID Value 0
Key Database__DatabaseConnectionString Value Server=tcp:servername01.database.windows.net,1433;Initial Catalog=application;Persist Security Info=False;User ID=applicationUser;Password=password;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;
Key APPSETTING_Database__DatabaseConnectionString Value Server=tcp:servername01.database.windows.net,1433;Initial Catalog=application;Persist Security Info=False;User ID=applicationUser;Password=password;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;
As can be seen, the Database__DatabaseConnectionString should be consumed by the app. But it's not being.
What could be the problem here? This should be standard functionality according to the aspnetcore documentation.
Turns out this was a bug in the application. The controllers in question has an injected IOptions being injected into the constructor. Unfortunately, one of the controllers had different behaviour as a concrete instance was being inject in instead. As this object was not being correctly initialised in Startup.cs, this has the effect of passing empty values into the constructor.
Finally as empty values were found, this mean the default appsettings.json values were used.
Having fixed this above bug (by ensuring all controller use the same IOptions values), the azure appsettings values are being picked up and used correctly by the application at startup time.
We want to use the Azure Redis service as a session cache for our MVC 5 web application.
For that we use Nuget Microsoft.Web.RedisSeessionStateProvider, which was updated to v3.0.2 recently.
However, putting that specific version in the web.config throws an error saying that the session state provider must inherit from SessionStateStoreProviderBase (namespace System.Web.SessionState).
The RedisSessionStateProvider v3.0.2 from the Nuget inherits from SessionStateStoreProviderAsyncBase (namespace Microsoft.AspNet.SessionState), and hence doesn't work.
The web application is running .NET Framework 4.72! So it must be compatible with v3.x according to the release notes.
The only solution so far is to fall back to version 2.x of the Nuget and use that instead.
What am I missing?
I have an WCF application which has seperate client and server application. When I running the application runs fine, but when I try to unit test the application methods the object builder exception is generated. Can somebody help?
I think you should check your test setting of your test project. You have to mention the necessary files that are required for the deployment. Also check whether the test.testsettings file is included in the project and it is properly configured.
I´m creating a new WCF service. I initially had only three operations. But after some time I decided to add two more. This operations doesn't appear in the Microsoft test client, neither in the list of operations when I try to add a service reference from my WPF client. Also I tried to comment one of the initial operations. It still apears in the Microsoft test client and can be invoked. I Tried also delete the dlls generated by the service and regenerate again. No luck. There are some kind of "cache" where Visual Studio stores the WCF services libraries that I can delete?
UPDATE: I'm working with the service running in the ASP.NET devolopment server.
You need to understand the order in which things happen.
You change your code, adding methods with [OperationContract] on them, or removing them, or changing their parameters or return values.
You then must build your service, producing a .DLL that contains the changes.
You must then deploy the changed DLL to the server it's going to run on
You must then restart the service (this may happen automatically depending on the server. For instance, IIS will recycle the service when it sees that the DLL changed)
You must then update your client, either the WCF Test Client, or "Add Service Reference", or the equivalent.
This last will have the effect of sending a request to the service for the new metadata or WSDL. Only then can the client see the changes you made to the definition of the service.
I don't know why, but I created a new project and copied the definitions of the operations from the problematic project and the problem is gone. One case more for Microsoft mysteries.
Make sure you are updating the services after adding the new operations.
Also make sure they have the attribute [OperationContract].
One thing we have discovered is that when you deploy the dlls that they must be in the bin, and cannot reside in the debug or release folder.
For me worked: just rebuild the wcf project
Did you close the client connection in client side
as showing your service
class Test
{
static void Main()
{
LocationClient client = new LocationClient();
// Use the 'client' variable to call operations on the service.
// Always close the client.
client.Close();
}
}
SOLUTION HERE :
Make sure your dataContract does NOT contain any enum
(You can use integer instead)
Be sure to reference a project in the solution and not a dll on your disk
Remove your "bin" and "obj" folders
Recompile
In IIS recycle the application pool
In IIS restart your service
In IIS "Browse" your service
=> You got it