In ASP framework I can add
<connectionStrings configSource="ConnectStrings.secrets.config" />
to the Web.config file and have a local development database ConnectStrings.secrets.config file which is in the root folder of the project but not included in the solution, and a deployed ConnectStrings.secrets.config file with my live database details.
Its a great fail safe to only develop with the dev database and publish to staging and live environments without cross pollination.
I don't want to setup predicates etc, so wont use appsettings.development.json etc. Is there a way of working with ASP Core and its appsettings.json file to refer to a separate file as above.
I'm not aware of any binding redirects in the json config of ASP core.
Generally the way we handle something like this (which is not quite as great but helps solve the whoopsies) is to validate config on startup. Inside of each config file such as appSettings.development.json we have the following key
Environment: "Development"
If the environment variable ASPNETCORE_ENVIRONMENT is a mismatch, prevent app from starting.
Related
I want to add a service reference to a wsdl web service in my ASP.NET website. In Visual Studio I right clicked the project and then Add service reference. It then created the *App_WebReferences* folder with some files in it and it added some new things to my web.config.
After I moved the changes to my test server by copying the new file, the App_WebReferences folder and the changed web.config, the server tells me that I'm missing a reference for the web service. I thought it should be in either web.config or that ASP.NET should find it in the App_WebReferences folder.
I've missed something obvious but I can't figure out what. What have I missed and what do I do to get my web service reference to work on my test server?
It's working really well on my local machine.
Was this working fine locally? You need to make sure you import the service to any classes that may be using it (or Using if you are doing this in C#). Also, is the service you imported from a project that is on your pc? IF so, you will need publish that as well to the test server.
Is it there (I'm sure there is) a way to separate the local Config file and the online ? I don't want to write and rewrite each time i upload my web.config files! talking about an asp.net mvc3 application!
If you're using .NET 4.0, take a look at Web.config Transformations
It basically keeps a base web.config file, and then you can specify different values depending on whether you're in Release or Debug mode.
Another simple solution is to have sections of your web.config reference external files. You can then change the external file without a need to restart the web application.
You can then overwrite the external file with one that contains data required for your local environment.
When you come to publish your app. you can include the online config files.
I just inherited a very old ASP.NET 2.0 web application.
In the application it has SEVERAL support class library projects. In the DataAccess class library, is an app.config (and setting.settings file) with a connection string named ConnString1.
I always thought that a .DLL couldn't have a app.config/setting.settings file (or at least you can include them but they won't be used), so this is what is confusing to me.
The web.config also has a connection string named ConnString1 with the same server login credentials, but a different server name.
When I run the application from Visual Studio DEBUG, it uses the connection string that is located in the app.config/settings file, and not the one defined in the web.config/machine.config.
I thought .DLLs wouldn't do this, but use the web.config instead?
However, when I pushed this application in RELEASE mode to our production server (in test website), it seems to be using the correct connection string in the web.config.
Can anyone explain this?
There's got to be something that is confusing you to think that the config file that's a part of that DLL is being used - as opposed to the applications (entry point's) config file (yourapp.exe.config or web.config). Maybe that conn string is hard-coded somewhere for the use in debug mode, e.g. by using conditional compilation via "#if DEBUG" preprocessor directive (so, maybe search for "#if DEBUG" across your solution to see if this particular thing is happening).
MSDN article about app settings
See the yellow "Note" in the section "Creating Application Settings at Design Time": "Because there is no configuration file model for class libraries, application settings do not apply for Class Library projects."
I found the issue:
In the above example, I am using the web.config/machine.config to set the connection string for the application.
If the connection string isn't defined in the web.config, it defaults to the machine.config. If the connection string isn't defined in the machine.config, it will use the app.config setting found in the .dll.
It's important to note, that placing the connection string in the machine.config, it must be defined in the correct Framework/CONFIG.
On my development machine, the connection string wasn't defined in the web.config but in the environment.config, but in the Framework64/CONFIG -- however, the application is compiled in 32-bit, thus, the reason for using Framework/CONFIG that did not have the connection string defined in it and causing it to default to the app.config in the class library.
I hope that explains that?
All config settings must be specified in the executable config file. For windows and console apps it's app.config, for web projects it's web.config.
Libraries can specify config settings, but you have to copy the settings to the executable's config file in order for the application to be able to read them.
Difference between Web.config, AppSettings.json and App.config
Web.config:
Web.config is needed when you want to host your application on IIS. Web.config is a mandatory config file for IIS to configure how it will behave as a reverse proxy in front of Kestrel. You have to maintain a web.config if you want to host it on IIS.
AppSetting.json:
For everything else that does not concern IIS, you use AppSetting.json.
AppSetting.json is used for Asp.Net Core hosting. ASP.NET Core uses the "ASPNETCORE_ENVIRONMENT" environment variable to determine the current environment. By default, if you run your application without setting this value, it will automatically default to the Production environment and uses "AppSetting.production.json" file. When you debug via Visual Studio it sets the environment to Development so it uses "AppSetting.json". See this website to understand how to set the hosting environment variable on Windows.
App.config:
App.config is another configuration file used by .NET which is mainly used for Windows Forms, Windows Services, Console Apps and WPF applications. When you start your Asp.Net Core hosting via console application app.config is also used.
Summary
The choice of the configuration file is determined by the hosting environment you choose for the service. If you are using IIS to host your service, use a Web.config file. If you are using any other hosting environment, use an App.config file.
See Configuring Services Using Configuration Files documentation
and also check out Configuration in ASP.NET Core.
I created an empty Azure Cloud Service project, then added a web role there. The role project has a web.config file.
When I hit F5 the role is deployed in Compute emulator. I went into the folder where role binaries are deployed - there's no web.config file there.
What's happening? Is that because I didn't set "copy always" on web.config file? What web.config does my role use?
If your role is configured for Full IIS mode (for those unaware of the difference between Hosted Web Core and Full IIS, see this blog post), the compute emulator should deploy the web role to IIS where it can be viewed in IIS Manager. On my machine (I'm running Azure SDK 1.5), the deployed web role's physical path is my source code directory.
I think web.config is compiled into your assembly as content in your development environment, and is not directly accessible like in staging/prod. You don't need to use Copy Always, if its marked as Content its all you need. You can use Environment.CurrentDirectory to see your web root path.
Even though the preferred way of storing configuration in Windows Azure applications is in the ServiceConfiguration.cscfg file, there are still many cases when you may want to use a normal .NET config file - especially when configuring .NET system components or reusable frameworks. In particular whenever you use Windows Azure diagnostics you need to configure the DiagnosticMonitorTraceListener in a .NET config file.
When you create your web role project, Visual Studio creates a web.config file for your .NET configuration. While your web application can access this information, your RoleEntryPoint code cannot-because it's not running as a part of your web site. As mentioned earlier, it runs under a process called WaIISHost.exe, so it expects its configuration to be in a file called WaIISHost.exe.config. Therefore, if you create a file with this name in the your web project and set the "Copy to Output Directory" property to "Copy Always" you'll find that the RoleEntryPoint can read this happily. This is one of the only cases I can think of where you'll have two .NET configuration files in the same project!
All info is from Azure Team Blog and I have used this solution successfully- http://blogs.msdn.com/b/windowsazure/
I just upgraded to Visual Studio 2010 and MVC 2.0 and I noticed the Web.config has two additional files attached to it? Are these files used to specify debug and release specific settings, so you don't clutter up the main Web.config?
Does it even make sense to place a connection string in the root Web.config file if I have a local and remote one in the debug and release Web.configs respectively?
Thanks!
It's the new Web.config transformation feature of Visual Studio 2010. More information here.
Edit:
Are these files used to specify debug and release specific settings, so you don't clutter up the main web.config?
It isn't limited to three files, you could (in theory) have as many files as you have environments. The "top level" Web.config provides a template of your web config. The files under it provide replacement values specific to that environment (like if you have different connection strings for local/stage/test/whatever).
Does it even make sense to place a connection string in the root web.config file if I have have a local and remote one in the debug and release web.configs respectively.
It would only make sense if it wasn't going to change between environments. Sounds like in your case it does so, in your case no, it would not make sense to leave it in the Web.config.
These are Web.config transformations files. From ASP.NET Web Deployment using Visual Studio: Web.config File Transformations:
There are two ways to automate the process of changing Web.config file settings: Web.config transformations and Web Deploy parameters. A Web.config transformation file contains XML markup that specifies how to change the Web.config file when it is deployed.
You can specify
different changes for specific build configurations and for specific
publish profiles. The default build configurations are Debug and
Release, and you can create custom build configurations. A publish
profile typically corresponds to a destination environment.
In case anyone is interested, here is something I wrote up to have a dynamic connection string per environment. I wanted to deploy the code to any environment (Dev, Test, Pre-Prod, Prod...) without having to worry about changing connection strings. I couldn't really find a good way to do this with Asp.Net MVC 4, so I came up with my own way to rely on a properties file per environment.
There may be a better solution, I come from a Wicket/Java background and recently started developing with MVC 4 so, it's possible a better solution exists. But here is a link to my question and answer for a dynamic connection string:
Asp.net MVC 4 dynamic connection string
That was something long needed in VS. Unfortunately there seems to be a problem with the implementation. For example consider this scenario (VS.2010 Ultimate, all SP):
Web.Config
No connectionStrings section
Full Membership User/Role/etc. Provider configuration using connectionStringName="test"
Web.Release.Config
No membership configuration (already specified in main web.config)
connectionStrings section including the CS named "test"
Web.Debug.Config
No membership configuration (already specified in main web.config)
connectionStrings section including the CS named "test"
When executing the application gives the following error:
The connection name 'test' was not found in the applications configuration or the connection string is empty.
In other words, because the connection string elements are in the Release/Debug designer files and used by configuration elements in the main (Web.config) file, it is unable to resolve it.