app-config | 易学教程

unable to save settings in app.exe.config

阅读更多关于 unable to save settings in app.exe.config

问题 i am facing one problem. i want to save settings in app.config file i wrote separate class and defined section in config file.. but when i run the application. it does not save the given values into config file here is SettingsClass public class MySetting:ConfigurationSection { private static MySetting settings = ConfigurationManager.GetSection("MySetting") as MySetting; public override bool IsReadOnly() { return false; } public static MySetting Settings { get { return settings; } }

App.config for dll

阅读更多关于 App.config for dll

问题 We have an "engine" that loads dlls dynamically (whatever is located in a certain directory) and calls Workflow classes from them by way of reflection. We now have some new Workflows that require access to a database, so I figured that I would put a config file in the dll directory. But for some reason my Workflows just don't see the config file. <configuration> <appSettings> <add key="ConnectString" value="Data Source=officeserver;Database=mydatabase;User ID=officeuser;Password=officeuser;"

The underlying connection was closed: The connection was closed unexpectedly

阅读更多关于 The underlying connection was closed: The connection was closed unexpectedly

Problem: The underlying connection was closed: The connection was closed unexpectedly. This happens on my WCF service that is hosted on the visual studio 2010 built in development server. Information: this does not happen all the time I believe it is a "big Data" issue, I have googled as hard as I can but non of the solutions I have implemented have fixed anything (and I have tried most of them out there) I most likely am just missing something stupid. Question: Why is this happening and how can I fix it? Client app.Config: <?xml version="1.0" encoding="utf-8" ?> <configuration>

set default proxy programmatically instead of using app.config

阅读更多关于 set default proxy programmatically instead of using app.config

问题 Being behind a proxy, my .Net 4.0 C# application only works when there is an app.config with the following content: <system.net> <defaultProxy enabled="true" useDefaultCredentials="true"> <proxy /> <bypasslist /> <module /> </defaultProxy> </system.net> Now since I don't want to have an app.config and since embedding app.config is not recommended, what is the C# code that has the same effect as that xml chunk in the app.config and where do I place it? 回答1: You can use WebRequest

Execute Coded UI Tests in multiple environments

阅读更多关于 Execute Coded UI Tests in multiple environments

问题 Right now my Coded UI Tests use their app.config to determine the domain they execute in, which has a 1-1 relationship with environment. To simplify it: www.test.com www.UAT.com www.prod.com and in App.config I have something like: <configuration> <appSettings> <add key="EnvironmentURLMod" value ="test"/> and to run the test in a different environment, I manually change the value between runs. For instance the I open the browser like this: browserWindow.NavigateToUrl(new Uri("http://www." +

AppSettings in App or Web Config Using a Linked File

阅读更多关于 AppSettings in App or Web Config Using a Linked File

问题 I'm trying to reference some common config settings between a Windows Service and an ASP.NET MVC website. I am doing this by using the file attribute on appSettings in either the App.config or Web.config (respectively). The file (named common.config) that is being referenced is a linked file in a separate project in the same solution. That common.config is set to Content with Copy Always in both projects. This stack answer to a similiar question seems to suggest at least for configSource this

How to prevent Visual Studio from prompting to update .settings file from app.config

阅读更多关于 How to prevent Visual Studio from prompting to update .settings file from app.config

问题 We're using a .settings file to store our application settings, and use default values in there so that we don't need to configure every single setting. This has generally been fine. However, during development we'll frequently change values in app.config, which means that when we open the .settings file, we always get the prompt "Value of setting 'x' was changed in the app.config file. Do you want to update the value in the .settings file?" In our case, the correct thing to do is always

Issues with SQL Alias in ConnectionString in appsettings.json

阅读更多关于 Issues with SQL Alias in ConnectionString in appsettings.json

问题 In my appsettings.json, when I use this snippet: "ConnectionStrings": { "CssDatabase": "Server=BLUEJAY\\MSSQLSERVER2014;Database=CSS;Trusted_Connection=True;" } I can connect to the db as expected... no issues. However, when I change that to use the SQL Alias (CSSDB), like so: "ConnectionStrings": { "CssDatabase": "Server=CSSDB;Database=CSS;Trusted_Connection=True;" } It is properly configured since I can use this SQL Alias in SSMS to connect to DB without an issue. This returns: The server

c# error:Unrecognized configuration section userSettings - stop program reading user.config?

阅读更多关于 c# error:Unrecognized configuration section userSettings - stop program reading user.config?

问题 In my c# form application (created in VS2010, using .NET 4.0) I use an application setting to store an output path. Previously this setting was configured with a user scope, but I had to change its scope to application. After doing this I now get an Unrecognized configuration section userSettings error on start up of the form (note the program has been executed before with the setting's scope set to user): InnerException: System.Configuration.ConfigurationErrorsException Message=Unrecognized

The right way to use Globals Constants

阅读更多关于 The right way to use Globals Constants

问题 In almost every project, I can't decide on how to deal with certain global constant values. In the older days, when I wrote C++ programs which didn't used dll's, it was easy. Just create and .h file with a number of const that described certain constant values for my project. Then I had every file include it, and ta-da! It worked. Clean, respected the DRY principle and was simple. Now my projects are C# .Net, which gives me a large range of options to deal with this problem. From what I know: