It's a question I see on here but solutions aren't working.
I have a Multi Project Solution set up like so
The sole purpose of the "Console" is to start/stop the "Controller", the "Controller" the handles the "Plugins".
"Console" is a Console Application the other projects are class libraries.
I've just added log4net to the "Controller" project to write logs to the database.
In DEBUG it works perfectly and logs to SQL.
However once built in release, published and deployed it is failing to log.
I've kept all the log4net config within the Controllers "app.config" and know this is being used because the "app.config" has some other settings present.
Attempted Solutions - ALL WORKING in DEBUG but not Published/Released Version
Changed SQL connection string to a USER & Password from Windows
Changed log4net to separate config file and setting build properties to CONTENT and COPY ALWAYS
Using the below code to configure log4net in either he "AssemblyInfo.vb or the "Contoller.vb" file
Assembly: log4net.Config.XmlConfigurator(ConfigFile:="app.config", Watch:=True)
Any potential ideas please?
NOTE:
If I remove the explicit ConfigFile:="app.config" LOGGING DOES NOT WORK
NOTE 2:
Setting an absolute file path on the server for the ConfigFile enabled the Published Installed version to work. Is this the best method?
Related
I received new project file. Its actually .NET Core Worker Service Project. Created using VS Code. I tried to Manually build the service. but in there no have any dll file. because I only changed the project name after its received. Now I tried to run my project. but I got error. its says
launch: program 'C:My Folders\Glm'
Projects\DBDataService\bin\Debug\netcoreapp5.0\win7-x64\'DBDataService.dll' does not exist
Can you please tell me how to setup my local environment with dll file in VS Code. I am new to VS code actually. How to manually setup dll file in project
VSCode was looking for the DBDataService.dll program, but could not find it.
You only need to configure your environment and then correctly define everything (especially "programs") in your launch.json.
Try to change,
"program": "${file}"
${file} is a predefined variable in VS Code for the current opened file. Refer to：
https://code.visualstudio.com/docs/editor/variables-reference
You can also refer to this post, which may help you:
C# - VS Code - launch:program ... does not exist
Create a debugging file：
https://code.visualstudio.com/docs/editor/debugging
A common pattern used to build applications/software (web, mobile, desktop) is to have multiple build configs like Dev, Stage and Production. Each one of these configs may overwrite multiple variables like the base url of a web service that is consumed by the application. These configs may be stored in multiple ways (.env file, a JSON config file, etc).
I was looking for a name for this pattern/practice and how to implement it on a VB.NET application. Most close thing I was able to found is using the app.config file to store app settings but this is missing the multiple environments part. I'm having some trouble looking for solutions since I don't know the proper term for this practice.
There's a Solution Configurations drop-down on the main toolbar. You would have already used it to select Debug or Release. You can open the Configuration Manager from there to create new build configurations.
You can then control what happens during the build process of a project for a particular configuration on the Build page of the project properties. You can also perform actions using build events, which you configure on the Build Events page of the project properties. Here's an example of a pre-build event commandline that I use to automatically select the appropriate config file for NLog:
IF EXIST "$(ProjectDir)nlog.$(ConfigurationName).config" XCOPY "$(ProjectDir)nlog.$(ConfigurationName).config" "$(ProjectDir)nlog.config" /Y
We're making a project that is primarily a Windows Service EXE.
We're using WIX (with heat) to create an installer, that creates the relevant files and registers the EXE with Windows Services.
We've got to the point of implementing the installer upgrade logic, which largely JustWorks(TM) by setting the Version attribute of the Product tag in the .wxs file.
One issue that I can't see how to manage is the config files of the tool.
The tool has various config settings that can be modified from within the tool.
We're using ASP.NET, which has built in settings/config management, and the config settings that get changed are declared as "User" settings. When we run the save the config changes, it creates a secondary config file which overrides the default settings in the primary config file.
The primary config file exists at <installRoot>\MyCustomService.exe.config, and the secondary config file is at <complicated\Path>\vX.Y.Z\user.config.
Where X.Y.Z is the AssemblyInfo version number which is held in sync with the WIX Version number.
When we install a new version, the tool starts looking in a new path for the user.config ... and can't find it. So functionally, installing a new version resets all of the user's configuration :( .
What is the appropriate way to get a WIX upgrade installation to maintain the existing config?
ASP.NET config supports upgrading user settings from one version to the next, using the .Upgrade() method. You're better off using that rather than manage this in the installer.
This question has details on how to manage that: How do you keep user.config settings across different assembly versions in .net?
but the core solution is:
if (Settings.Default.UpgradeRequired)
{
Settings.Default.Upgrade();
Settings.Default.UpgradeRequired = false;
Settings.Default.Save();
}
Having created UpdateRequired as a user property existing only to manage this process
I have the following code:
var config = new ConfigurationBuilder();
config
.SetBasePath(Directory.GetCurrentDirectory())
.AddEnvironmentVariables()
.AddJsonFile("appsettings.json")
.AddJsonFile($"appsettings.{environment}.json", true);
Which works fine in development environment and production too. However if I place this:
Raise<FileNotFoundException>.If(File.Exists(Path.Combine(Directory.GetCurrentDirectory(), "appsettings.json")),
$"Could not find the settings file");
It raises exception during debug sessions and release sessions (basically when the app is not published and executed from Visual Studio) that file could not be found which is kind of correct because VS2017 does not copy settings file to the debug folder and instead keep them in the source folder. So my question is,
how does the dotnet core resolves the configuration path for aspnet core?
I think you're getting confused on things here. The configuration is pulled by default from the entry point directory. Inside Visual Studio or when running dotnet run from the command-line within your project root, everything works fine. Also, when you publish, the published directory will contain the configuration files alongside the entrypoint DLL, so this will work fine as well.
What you seem to be talking about is running from the bin directory, which is not a supported thing. The bin directory is effectively a cache. It's not a published version of your application, and thus cannot be run as if it is.
I have WCF library project which I have recently done some minor refactoring on eg changing the namespace and changing it location on disk. I also removed the app.config, because I thought the app.config is used by whatever hosts the wcf service.
I have since noticed that I can no longer debug the library using the WcfSvcHost like I used to be able to do. The message I get from Visual Studio is:
'A project with an Output Type of Class Library cannot be started directly.
In order to debug this project, add ana executable project to this solution which references the library project. Set the executable as the startup orject.
I don't want to do as it says, because I didn't need to do this before. Please let me know how to restore the ability to debug it using the WcfSvcHost. On the Debug tab of the project settings, the Command line arguments is still set to: /client:"WcfTestClient.exe"
Not sure what else to try, thanks.
I have observed that changing the output path of the project cause this behavior. To re-enable the debugging using WCFSvcHost/WCFServiceClient leave the output path to default and it should work.
If you changed the project output path you can still run it, you just need to provide some extra parameters to WcfSvcHost like this (enter this in Command Line Arguments in project's debug settings):
/service:ServiceInterface.dll /config:application.config /client:"WcfTestClient.exe"
No need to enter the full path as it will be run from your new project output path
If you still get the 'A project with an Output Type of Class Library cannot be started directly' then you can try changing the start action to 'Start external program' and select the WcfSvcHost.exe in there
You need to build the project in Debug Mode in order to use WcfTestClient and WcfSvcHost
In Debug mode you don't need another project. The Wcf Service Library runs in WcfSvcHost
However if your solution has only Wcf Service Library you need the app.config to configure the endpoints and etc...