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.
Related
I am trying to create an app.config that allows my WPF application to probe into a local lib folder. However, I am not getting an exe version of my app.config when building my project. Renaming the .dll file does not work either.
Edit: I am using .NET Core
In .NET Core project the generated exe is just a bootstrapper. Your application resides in a DLL file. So it makes sense that the config is also associated with that DLL.
I have a very simple question. When I use donet build on a c# project in ubuntu it outputs a .dll file. I was wondering why or how it does that and why does it not output a .so file ?
Because .NET Core (and .NET as a whole) uses the Portable Executable format even for other platforms, it's still technically a dynamic link library.
The .NET Core run-time loader can read and run it fine.
You can read more here - .NET assembily file format
.NET Core uses it's own file system that has to be ran with a specific command in order to run the application.
(It) relies on the presence of a shared system-wide version of .NET Core on the target system
To run the application you type in
dotnet {FileName}.dll
This will start running the application using the .NET Core framework.
Your app contains only its own code and any third-party dependencies
that are outside of the .NET Core libraries. FDDs contain .dll files
that can be launched by using the dotnet utility from the command
line. For example, dotnet app.dll runs an application named app.
Source: .NET Core Application Deployment
I have a .NET Framework project that requires running a built console application from a .NET Core project in the same solution.
Take the example file structure:
Test/bin/Debug/Test.exe
Service/bin/Debug/netcoreapp2.2/Service.dll
The current approach involves starting a new process, similar to the following:
dotnet run ../../../Service/bin/Debug/netcoreapp2.2/Service.dll
I am fairly new to .NET, and so unsure if the following ideas are possible:
Modifying the path when running the Test application so that I can start the Service process with dotnet run Service.dll.
Getting the Test project to copy the Service build files into the Test build folder.
For bonus points, if/when the Framework project is upgraded to Core, is it possible to start a Core application process by using it in another application?
Edit:
For clarification, I'm hoping to avoid using that hard-coded relative path to build output folder, since it changes between Framework and Core and different versions of Core.
My hope is to find a built-in variable or functionality to get the build location of another project (even if I need to hard-code the Debug/Release part).
For example (excuse the pseudocode):
using Service;
var path = getPathToDebugBuildFolder(Service);
startProcess(Path.Join(path, "Service.dll"));
If you right click your project in Visual Studio you can define your Pre- and PostBuild Tasks (Build Events).
And yes.. if you are using .NET Core for both applications then you can Add a reference to your class library / console application and use the public types.
I've created a simple .NET core console app targeting .NET Core Framework 1.1. When I build it, it creates an assembly file named DotNetCoreConsoleApp.dll in the \bin\debug folder. So there is nothing that I can double click and run directly but interestingly when I start debugging the project by pressing F5 then Visual Studio is able to launch a process.
Project configuration of my project is as below:
How windows will be able to launch such an application process without any exe file? I understand that Windows only understands a file as starting point of a process if it contains PE header.
There is no exe file.
From msdn:
"Short answer, there isn’t one. When you compile your .NET Core console application for example, you get a DLL. Then you execute it using the DOTNET command from the .NET Core SDK found here."
From a different answer on stackoverflow (Visual Studio 2017 missing exe file):
You have two options:
If you want an EXE, you need to target the .NET Framework.
If you don't want to change your code, then you need to install .NET Core on the server and run dotnet pathToDll on a command line
https://blogs.msdn.microsoft.com/benjaminperkins/2017/03/07/net-core-application-where-is-my-exe-how-to-publish/
Problem: ConfigurationManager does not work to access App.config in a v3.5 Azure WebJob
Question: How can I make it work?
* Background *
I have inherited a very old web application which must run as a Windows Azure Web App under a .Net 3.5 app pool.
There is a corresponding service which must be turned into an Azure WebJob (runs for several hours and requires access to the website files).
My problem is that the WebJob must be a .Net v3.5 application in order to run within the corresponding Web App (they both share the same App Pool so a v4.5 Web Job cannot be deployed to the v3.5 Web App).
This means I cannot use the normal WebJob NuGet packages such as Windows Azure Configuration Manager which I understand allows the System.Configuration.ConfigurationManager class to access App.config in the normal way, allowing referenced libraries containing EDMX based EntityFramework ObjectContexts to load their connection strings and app settings to be accessed by various bits of code all over the place. The code is shared between the web app and the web job so I need a method of configuration which is consistent across both.
Running the WebJob as a v4.5 allows it to work fine using ConfigurationManager but as soon as I switch to v3.5 (which I have to do to make the web app work) I have to remove all the incompatible WebJob Nuget packages including Windows Azure Configuration Manager. ConfigurationManager will no longer work to load AppSettings, no error, it just returns nothing for AppSettings.
My question is - how can I make ConfigurationManager work to load the deployed App.config without using those incompatible NuGet packages. I've looked at the code in Microsoft.WindowsAzure.Configuration.dll but I can't see how it make ConfigurationManager actually work, I must be looking in the wrong place.
After running some v4.6 vs v3.5 app pool tests (exactly the same codebase - no NuGet packages installed apart from Azure WebJobs Publish) I have found that Web Jobs running in v3.5 app pools simply don't load their config files.
On a side note RSACryptoServiceProvider.ImportParameters also explodes under v3.5.
The following works to force the config file to load.
class Program
{
static void Main()
{
AppDomain.CurrentDomain.SetData("APP_CONFIG_FILE", #"D:\home\site\wwwroot\App_Data\jobs\triggered\DataImportWebJob\[TheAppName].exe.config");
Thanks to Using ConfigurationManager to load config from an arbitrary location