I have deployed an application as a Microsoft Azure Web App with a log level Default of Information as shown below in appsettings.json in code. Is it possible to change the log level for example to Trace during runtime without redeploying?
"ApplicationInsights": {
"LogLevel": {
"Default": "Information",
"Microsoft": "Warning",
"Microsoft.Hosting.Lifetime": "Information"
}
How about using kudu?
First, we all know that we can change the log level by modify the configuration in appsetting.json, hence we can using kudu to change the value after deploying to azure web app. Pls note the setting in my screenshot below, it's Logging->appinsights->loglevel
After deploying to azure web app, you can visit https://yourdomain.scm.azurewebsites.net to reach kudu website, in this website, you can modify all the settings in static files. I've tested in my side and it worked well.
Related
I've developed a tool built with .Net 6 which serves a rest api. I modified the appsettings.json file so that it suppresses the default "info" messages that usually appear in the console when running an api project:
"Logging": {
"LogLevel": {
"Default": "Warning",
"Microsoft.AspNetCore": "Warning",
"Microsoft": "Warning",
"System": "None"
}
}
This works fine for my local build, and all but my custom log messages are suppressed, but after publishing as a dotnet tool, unfortunately the default info messages continue to be displayed to the cli. How can these be suppressed?
Edit: More details -- I've confirmed the appsettings.json file is located in the package, and it is installed in the global tool installation folder. I've also confirmed that the tool runs as intended after copy/pasting the appsettings.json file into the same directory of the executable, which indicates that the executable could not find the appsettings.json file.
This is just a shot in the dark, but, the tool name (and executable name) differs from the package name and its associated directory in .store. I have to wonder if this could be related to the executable search path for the settings file.
This problem was caused by the executable being unable to locate the appsettings.json file included with the distribution. According to this source it looks like this is intentional behavior:
The IHostEnvironment.ContentRootPath property represents the default directory where appsettings.json and other content files are loaded in a hosted application, including ASP.NET apps. This property's value defaults to Environment.CurrentDirectory, which is the current working directory of the application. This behavior allows the same app to be executed under different working directories and use the content from each directory.
When a Windows process (either application or service) is launched
without specifying a working directory, the working directory of the
process that created it is used.
Being that this is my first dotnet tool as a webdev unfamiliar with the use of .Net for most CLI applications, this was a curveball for me, but once I understood the issue the fix was relatively straight foward.
My tool has no need to be configured using local settings, so the WebHost content root path had to be updated in Program.cs as follows:
var builder = WebApplication.CreateBuilder(new WebApplicationOptions()
{
ContentRootPath = Directory.GetParent(Assembly.GetExecutingAssembly().Location)?.FullName
});
I have an app made with ASP.NET Core and I published/deployed it to IIS. It has a database with multiple tables, and multiple rows of data. I was tasked with recreating the web app again and improving it. I used ASP.NET Core again, this time the database and tables are all different. I am using the same url as the old one, just a different app with different database.
My question is, can I just add the connection string in the appsettings.json file to the new app with just a different database name and transfer the publish profile over to the new app? Can I do this and it will add the new web app to the url and simply override the other web app currently running on it? If so do I need to create the database on the server before hand, then reference it in the connection string? Or when I publish the new web app, the new database will be created?
I can add more details if necessary. I just want to know if connecting the new app will be as easy as adding the same connection string. Here is appsettings.json currently running
{
"ConnectionStrings": {
"DefaultConnection": "Server=Server-Name;Database=DatabaseName;Trusted_Connection=True;MultipleActiveResultSets=true"
},
"https_port"; 443,
"Logging": {
"IncludeScopes": false,
"LogLevel": {
"Default": "Warning"
}
}
}
To be more specific. I just want to add replace the current web app with the new one. The database, code is different in the new app. I just want to use the same url which is hosted on IIS server, but with different code. Basically I don't want to buy a new domain name from somewhere. I want to push new project onto server and host it.
Can I just change Database=DatabaseName to Database=NewDatabaseName inside the connection string?
From the comments, it seems like you are trying to host two applications in IIS under the same domain.
When doing it manually, you simply "Add Application" in your site.
If you are publishing it from Visual Studio, you can do a Web Deploy or publish to a folder.
Web Deploy: https://learn.microsoft.com/en-us/visualstudio/deployment/tutorial-import-publish-settings-iis?view=vs-2019
Publish Folder:
Create an application manually in IIS.
Share the app folder with you.
Publish from Visual Studio to the folder.
Having said that... I don't recommend publish to your production directly from your machine. I recommend using a CD pipeline from your repo. If you don't have one yet, I recommend using Azure DevOps.
I did it and all I had to do was create the new database on the IIS server in SSMS, create a folder to publish the code to on the server, and also direct the url to point to the folder in IIS.
On my app, in appsettings.json, just copy the same connectionstring over from the old project to the new project, just update the database name.
This did what I expected, just replaced the url/website, with the code from my new app.
I found a lot of questions similar to my problem on MSDN and SF but none of them helped me or maybe I didn't understand them. I'm getting the following error while I'm trying to publish my app on Azure.
Entity framework SQL Script generation failed
I'm using the SQLite database here. Point to be noted that everything is ok in my local machine. The app runs fine.
I already ran these commands on package manager console - Add-Migration -Initial and Update-Database
Publishing setting
In this photo, I entered "Initial" as the connection string in the EF Migrations field. The result is the same. Maybe the problem causing here I guess.
appsetting.json
{
"Logging": {
"LogLevel": {
"Default": "Information",
"Microsoft": "Warning",
"Microsoft.Hosting.Lifetime": "Information"
}
},
"AllowedHosts": "*",
"ConnectionStrings": {
"EmployeeDB": "Data Source=employeedb.db;"
}
}
For me, this error went away when I checked the Apply this migration on publish checkbox under the Entity Framework Migration options in the publish menu.
For some reason it was failing to run on its own and my migrations were probably out of sync but I was getting this weird error message in the question above.
Hope this helps anyone that has this issue in the future.
I think this could help you if you got an Azure App Service running. I had been searching so long for fix this issue. I was able to resolve the issue using Server Explorer from the Visual Studio 2019 Community Edition.
Before you start, you need to deploy your app without migrations, deselect Entity Framework Migrations on your Publish Profile settings, and then publish your Azure profile.
On Visual Studio Community 2019, log into your Azure Account under Server Explorer -> Azure
Select App Service and double-click on Open Cloud Explorer
A new tab window appears and you'll need to find your Azure Subscription
Within your Azure Subscription, you'll see all your App Services
Within one, go to the Files folder and you´ll see all of your deployed files
Right click on the Files folder and select Upload File
Upload your .db file in this window
.NET Core 2.2
I have a basic CLI created with dotnet new console. It uses HttpClient to make web requests. How can I see trace or logging information about these requests?
Data like this:
https://www.stevejgordon.co.uk/httpclientfactory-asp-net-core-logging
In the .NET Framework, you could turn on System Tracing: https://learn.microsoft.com/dotnet/framework/network-programming/how-to-configure-network-tracing
In your appsettings.json file there will be an object which looks similar to the following:
"Logging": {
"LogLevel": {
"Default": "Warning"
}
}
Increase the log level to Information and run your application again. Once you have done that, take a look at this page in the ASP.NET Core documentation for how to enable logging to file or the terminal.
I have added application insights to my asp.net 4.6 web application.
This also added the file Service References\Application Insights\ConnectedService.json
The contents of this file:
{
"ProviderId": "Microsoft.ApplicationInsights.ConnectedService.ConnectedServiceProvider",
"Version": "7.1.719.1",
"GettingStartedDocument": {
"Uri": "https://go.microsoft.com/fwlink/?LinkID=613413"
}
}
What is this file for? It does not seem to provide any logic to my application and does not seem to be required for anything to work.
This file is simply a marker to the Visual Studio "Connected Services" tooling that Application Insights (or any other connected service) was installed, what version of that service installed it, and where to go for getting started documents. The file is not compiled into your app, is not set to content included in the project or anything else, it is only there for Connected Services to know what things you've installed.
This info shows up in solution explorer in a folder called "Service References", and you'll see all of the connected services you have added that way. You can double click the node there to re-open the documentation.
To see what other services are available, you can right click the project, go to add->connected service and see more items there.
For more information, you can see this channel 9 video:
https://channel9.msdn.com/Shows/Visual-Studio-Toolbox/Connected-Services