I set custom configuration in APP.config.
When I convert the application to DLL and use in within another application, the dll in not running because it can not access to my custom config. Instead it tries to search in new application APP.config.
You cannot access the app.config (or the actualy properly named assemblyname.exe.config/assemblyname.dll.config) from a DLL. A DLL does not read a configuration file and thus doesn't provide the respective mechanisms.
The only way to use the .NET configuation mechanisms from a DLL is to copy the relevant configuration sections to the executing application's configuation file.
The application will then read the configuration and the DLL will be provided with the current values. I've done this several times successfully.
Related
When publishing a .Net Core app to a server via WebDeploy, a Web.Config file is created, with stdoutLogEnabled=false. This is overwriting the web.config on the server where I have set stdoutLogEnabled=true.
I struggling to find how I set the default value of stdoutLogEnabled prior to publishing. On .Net framework apps I would do this within the web.config file with transformations, however in .Net core I actually don't have a web.config file within my solution.
I've tried to find documentation on how to set the value, but it either doesn't exist, or more likely, I'm not using the correct search term. Can somebody please advise on how to set default values in the web.config.
Create a web.config and put it the root directory of your source, Modify the web.config file to enable logging and any other customization you need.
When you publish, it’ll use that file instead of generating a completely new file.
Like this(this is asp.net web The program):
While web.config transforms are still an option, Asp.Net Core seems to be moving away from them for application-level configuration and instead using things like environment variables and config.json files.
For the JSON configuration file option, you are able to create multiple JSON files for each environment, and use an environment variable at runtime to determine which file is loaded. More information can be found here: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/configuration
I've built and compiled my WCF client to run successfully. I've found that as long as these two files are together, my client will run anywhere on my computer:
Client.exe
Client.exe.config
When I move these files to another computer, there's an error:
System.InvalidOperationException: Could not find default endpoint element that
references contract 'Service.IService' in the ServiceModel client configuration
section. This might be because no configuration file was found for your
application, or because no endpoint element matching this contract could be
found in the client element.
I've already made sure that the service URL is accessible from the intended host of the computer.
After looking up the issue, seems like a solution is to copy the config retrieved from executing:
svcutil http://host/Service.svc
to the application configuration file. However, the config info is already in the App.config file when I built the project.
Do I need to recompile/build on every client machine that intends to use the WCF web service?
I seem to have resolved this by copying over the entire compiled folder:
Client.exe
Client.config.exe
Client.pdb
Client.vshost.exe
Client.vshost.exe.config
I don't have the time to go back and forth to see which subset of files are core or whether all these files are necessary, but hopefully someone can follow up with an answer to that.
I have wcf client. It uses .NET 3.5.
When I compile the client I get two files:
client.exe and
client.exe.config.
The second file contains configuration for the wcf client.
In my case I need to prevent the user sitting on the computer to see the urls and change some other parameters from the config file.
So the requirements are, the end user not to see and modify the data stored in the config. The config file contains the same data as app.config. I need to forbid the person using the program to see the end point urls so easy.
Also I have a lot of configuration there so I do not like to code in the moment.
Is there any solution for the problem (embedded app.config of something else)?
Edit: I do not need configurable options. The config file is automatically created when adding service reference from the studio.
Regards
You can also create your proxies programatically instead of using the service reference feature.
Every parameter in the serviceModel config section can be represented in code as well.
The ChannelFactory class will help you create proxies to the service.
You can easily encrypt entire parts of your config files - and not just web.config in web scenarios, but also application config's in stand-alone apps.
Check out some resources on how to do this:
Encrypting web.config values
Encrypting passwords in .NET app.config file
Encrypting the app.config file for Winforms application
I have a WCF service project hosted in IIS. The main SVC file is in the root of the web application folder, and in the bin\ folder are the actual dlls. The web.config (also in the root) contains all the unity mappings. Unfortunately, it seems that because the concrete assemblies etc. are living in the bin\ folder, Unity cannot find them.
Is there a way in the Unity configuration file that one can specify a path (sort of like probing) where the DLLs might live - or to put the path inside the mappings themselves somehow? I don't want to actually have to modify the probing paths in the machine.config etc. if we can avoid that.
I've looked on MSDN and Googled around but couldn't find anything of help.
Any ideas?
I too doubt this is a Unity issue. Have you tried using the Fusion log viewer, FUSLOGVW.EXE, to see what the application is trying to load and where it's looking for the assemblies?
http://www.ademiller.com/blogs/tech/2008/01/gotchas-fusion-log-viewer-your-best-friend-for-assembly-load-errors/
This should tell you what the current probing path looks like and you can take it from there.
This wasn't a Unity issue in the end - it was more that I was trying to host the application within IIS and had to configure that correctly.