I am trying to create a console application using .NET framework 4.7.2. I see an app.config file by default present in the project.
App.config is used to store configuration details of project. Just wanted to know the difference between app.config and appsettings.json
app.config is used to store configuration details for a .NET Framework application, and it's a traditional way to store configuration data in XML format. However, in recent times, there's a trend towards using appsettings.json files instead of app.config for storing configuration data in .NET applications.
The main difference between app.config and appsettings.json is the format of the data they store. app.config uses XML format, while appsettings.json uses JSON format.
Another difference is that app.config is specific to .NET Framework, while appsettings.json is used in .NET Core applications. You also get web.config, which is used specifically for a .NET Framework Web based application.
In your case I would go with what the framework provided and use the app.config file.
Here are some key differences
app.config is used usually in .NET Framework applications, while appsettings.json is commonly used in .NET Core applications.
app.config uses XML format to store the configuration, appsettings.json uses JSON format. JSON is easier to read and write compared to XML.
appsettings.json makes it easier to manage specific configurations for specific environments (you can have different JSON files for each environment appsettings.Development.json, appsettings.Production.json).
"app.config" is typically used in older .NET Framework applications - format with XML, while "appsettings.json" is used in .NET Core applications - With json format
Related
I'm mainly PHP dev, recently forced into .NET.
I have a solution with 2 projects:
one has data connection to one database and is a .NET Core project
another one has data connection to a second database and it is .NET EF 4.7 project.
I want to create a console app that will allow me to work with both databases. I need those 2 projects as they already have all models and connection defined and work well on their own. I need to be able to connect to both databases, and fetch some data to output in a console.
So far I've created a third project, Core 3.0. I managed to use the 1st project data connection, but I can't possibly work out how to use the EF 4.7 project connection. I'm getting this error:
The ADO.NET provider with invariant name 'System.Data.SqlClient' is
either not registered in the machine or application config file, or
could not be loaded. See the inner exception for details. --->
System.ArgumentException: The specified invariant name
'System.Data.SqlClient' wasn't found in the list of registered .NET
Data Providers.
I've tried reinstalling EntityFramework, checked app.config (provider string is there), checked if EntityFramework.SqlServer.dll is in dependencies - everything seems ok.
Is this even possible? Can the 3rd project be a Core 3.0 project? Someone mentioned that I should use .NET Standard Class Library to work with both projects, but Class library is not a console app. Please point me in the right direction...
Both 1 and 2 should be .NET Standard projects. The third should target either .NET Core or the .NET Framework.
I am afraid you can't "use" a .NET Core project from a .NET Framework project and vice versa. That's why there is the .NET Standard.
You may want to consider breaking out parts of your existing projects into class libraries that target .NET Standard. You can then reference them from any app that is compiled against a version that is compatible with the .NET Standard version you are targeting.
I have a .net core application , that at some point in the project refers to another .netStandard DLL which reads from app.config file using:
var x=ConfigurationManager.AppSettings["EngineServiceScansApiUrl"].
When I execute the application in debug mode (with debugger attached) x is null (the application can't find the configuration), whereas if I execute in ctrlf5 , sometimes it manages to read the configuration file, and sometimes it doesn't.
.NET Core uses appsettings.json instead of app.config. Take a look at this article for more information. ConfigurationManager is not available in .NET Standard 2.0 without a NuGet package.
As far as I can see, there are three file providers in the .NET Core. now I want to delete a file, but there is no delete method in the IFileInfo interface.
What is the standard interface in the .NET Core to manipulate files? I want to delete or write a file etc.
It's worth differentiating between ASP.NET Core and .NET Core. You linked to ASP.NET Core documentation for file providers, which are used to read files which might be virtual files within an assembly etc.
For plain file system access, use System.IO.File as you do in desktop .NET. That's been part of .NET Core since version 1. It allows files to be created, appended, read, deleted etc.
Is it possible to use built-in logging to file in dnx?
I tried to use System.Diagnostics.TextWriterTraceListener but is not available in .Net Core. Any suggestions?
By itself, ASP.NET Core’s logging system does not come with a file-based logging provider.
It would be pretty simple to roll your own though; just look at the Debug logger as an example to see what you need to do.
Of course, you could also use another logging framework that already supports this. For example NLog – a .NET Core compatible version is in alpha. Another example would be Serilog which also has .NET Core versions in beta (versions 2.x)
If you run your app through IIS, you can also use IIS’ file logging to redirect the stdout logging into files. This can be configured in the web.config.
I am writing an API for an existing .Net application, in order to use that application as an 'engine' for other custom applications (that may be written by customers). The premise is that the 'engine' will always be installed and working on the target machine.
My approach is to create a new project in the VS solution for the 'engine' application, a class library that provides public methods to aggregate the fine-grained functionality of the application's own libraries into higher level, simplified method calls for a 3rd party application author to use.
The API works well in the context of the 'engine' solution, unit tests working correctly. However, when I attempt to author a simple 'custom' application outside that VS solution, using a reference to the API to provide the services I need, I hit a problem - unless my custom aplication has a copy of the "engine"'s app.config (sic) file before it is compiled, the engine throws an exception when it attempts to access its config file.
It clearly is impractical to expect the 3rd party developer to have the app.config file to hand, and a bit inelegant to expect them to have to copy the engine's config file into their solution and and rename it.
Is there a cleaner way to do this? The aim is for the custom application to need a reference to the API assembly only, and for the engine to 'just work' as if it were being used normally. Preferably binary remoting, web services and COM are to be avoided (assuming they will solve the problem).
Oh, this is all .Net 3.5 & VS2008
TIA
Yes, use NuGet.
If you package your assembly in a NuGet package you can add a configuration file transform that will automatically add/update your engine's configuration properties. Then, when your consumers pull your reference (from local NuGet server?), then they will get the assembly reference and the config transform.
I would recommend to make a formal configuration section for your engine so that you know that you are only managing its configuration in the NuGet package.