I have a asp.net mvc application which comes with web.config. I deploy it to my Windows server 2012 with IIS 8.
I have to make some changes to the web.config because of the unique settings on the server, for instance, disable a URL rewrite rule, to name a few.
I treat my application as a open source project which shouldn't include settings specific to my server. But if I don't put the unique settings in web.config, every time I deploy the site, I have to manually edit it again.
Are there ways to resolve the problem? Is it possible for IIS to load two web.config, one from the repository, the other somewhere on the server?
I know <appsetting> has file attribute that include additional app settings, but my changes are not only app setting.
Related
I have the following error after move my website from server to another server
I have already checked iis and make sure the app has an application pool and it points to the correct file path
here is a screenshot of my application pool
I even tried to add virtual directory and add application and still not working
Check siteMapFile attribute of sitemap
The possible reason behind the issue is:
When you create a new web application using visual studio.net, it automatically creates the virtual directory and configures it as an application. However, if you manually create the virtual directory and it is not configured as an application, then you will not be able to browse the application and may get the above error. The debug information you get as mentioned above, is applicable to this scenario. To resolve it, Right Click on the virtual directory - select properties and then click on "Create" next to the "Application" Label and the textbox. It will automatically create the "application" using the virtual directory's name. Now the application can be accessed.
When you have sub-directories in your application, you can have a web.config file for the sub-directory. However, there are certain properties that cannot be set in the web.config of the sub-directory such as authentication, session state (you may see that the error message shows the line number where the authentication or session-state is declared in the web.config of the sub-directory). The reason is, these settings cannot be overridden at the sub-directory level unless the sub-directory is also configured as an application (as mentioned in the above point). Mostly we have the practice of adding web.config in the sub-directory if we want to protect access to the sub-directory files (say, the directory is admin and we wish to protect the admin pages from unauthorized users). But actually, this can be achieved in the web.config at the application's root level itself, by specifying the location path tags and authorization.
in your case the site map section causing the issue. try to remove it from the config file.
You could refer this below link:
Nested ASP.NET 'application' within IIS inheriting parent config values?
We are using ASP.NET for our web application which is hosted in IIS 8.5. ASP.NET uses a web.config file to store all application and IIS related configurations. Whenever we deploy a new version of code for the web application, we also deploy the web.config file.
Recently the operation team has raised a concern to this deployment process. They say, if someone change some settings in IIS and for that web.config has been updated for that, there is no way for the developers to know that change so that they can update the web.config in codebase (version control system). So eventually at the time of next deployment the web.config changes will be overridden by the old web.config.
There are two possible solutions can be taken:
Merge the web.config with server and codebase before deploy the code everytime.
Decouple the application configuration and IIS configuration in different configuration files.
My question is, what is the best practice to solve these kinds of problems in ASP.NET?
IIS 7+ introduced its distributed configuration which allowed for IIS as well as .NET configuration to live inside of Site/App/Directory web.config files. One of the primary reasons for this is as follows: In IIS 6, whenever an application team needed to deploy their application and make changes to settings like Default Document, they needed the IIS team involved because "Default Document" was an IIS configuration setting. You could argue that Default Document settings for a particular application is not IIS configuration, but instead is Application configuration. As result, the Application Team should own that configuration setting and deploy it as part of the application.
A bit more about IIS7+ configuration system: Administrators are able to configure what settings are allowed to be set inside Web.config files. For example, by default, "Default Document" is able to be set inside Web.config files, and Authentication settings like Windows Authentication are not. The implementation can actually get complex, but if you'd like to read about it, you can see it here: https://learn.microsoft.com/en-us/iis/get-started/planning-for-security/how-to-use-locking-in-iis-configuration.
Ultimately the best practice is for IIS Administrators to configuration the settings they want Application teams to manage (by delegating those settings to Web.config) and then not touch them. In other words, if Default Document needs to be updated, then it is the Application Team's responsibility and they publish a new web.config file. If the IIS team decides they want to manage Default Document, then they need to lock down the IIS configuration system to prohibit Default Document from being managed in the web.config files.
I am getting this error when I try to run an ASP.NET application without a web.config file.
The requested page cannot be accessed because the related configuration data for the page is invalid
as I read, we can run .NET applications without web config files, but when I tried it is giving me the error. I am using iis 7 on windows 7 machine.
When I create the application virtual directory inside inetpub/wwwroot it works fine. Why doesn't the other directory location?
One reason could be the version of .NET framework (on IIS or application pool level) is different from the application one.
Another reason could be if there are modules used in your web.config which the current configuration of IIS doesn't recognize. E.g. URL rewrite or other optional modules, which you have to explicitly enable before using.
This can be a reason:
If there is no Web.config file in the
UNC directory, IIS 7.0 uses the rules
that are defined for the parent
directory. For the Web content to be
served in this scenario, the
worker-process identity must have
access to the whole content directory.
Otherwise, the Web request is
rejected.
Details here.
You need to set permission for your Website folder or copy them to wwwroot folder.
If you choose to set permission, there are two ways:
Right click on Your Website folder, or
Right click to Your Website in IIS
Then select Edit permission and Add a permission (IUSR - default iis user)
I have a custom ASP.NET application that I utilize for several clients that I host. Each client has a separate domain and the application is normally a child application under the root domain (http://domain.com/customapp). The application files are the same (aspx, ascx, style sheets, images, etc.). The only thing different is the web.config file for each client. As development of the application continues to evolve, I have to update the application for each directory and this obviously becoming tedious. I am trying to come up with a method keep the application up to date. My first though is placing the application into a single physical path and creating multiple applications pointing to that path (the problem with this method is I can't have different web.config files). I am curious as to what solution others are using in this scenario...
If you want to handle this entirely in Visual Studio, VS2010 offers web.config transforms which could solve your problem.
In a nutshell, create a build configuration (In VS, select Build|Configuration Manager...) for each site. Add a web.config transform for each client, which only specifies the differences required for each application.
I use this for differentiating between development, staging and release configurations - each transform adjusts the connection string, app settings, etc - and it works quite well both within Visual Studio and when deploying via MSBuild.
Also, note that web.config settings are inherited by IIS applications. So, if you have a root site
/root
and client apps
/root/client1
/root/client2
...
you could place the client-specific config settings in a web.config in each client-specific folder, and global settings a web.config in the root folder.
Can you just move your web.config content to a database and load it conditionally based on the domain that was referenced?
Select Case Request.Url.Host.ToLowerInvariant()
Case "xyz.com", "www.xyz.com"
'Load XYZ stuff'
Case "abc.com", "www.abc.com"
'Load ABC stuff'
Case Else
'Throw an error probably'
End Select
Even better, store your domains in the database as keys so that you don't ever have to touch the code.
I have uploaded a simple hello world on my IIS server 7 (shared hosting). It doesn't work. Is it necessary to add a web config and what's the minimum in that case ?
Thanks.
Error says:
Server Application Unavailable
The web application you are attempting
to access on this web server is
currently unavailable. Please hit the
"Refresh" button in your web browser
to retry your request.
Here's the script, very basic :)
<%# Page Language="VB" %>
<html>
<head>
<title>ASP.NET Hello World</title>
</head>
<body bgcolor="#FFFFFF">
<p><%= "Hello World!" %></p>
</body>
</html>
A individual, site-specific web.config is not required to be present in order to get a basic "Hello World" site up and running in IIS7, however, it's rather unusual not to have one.
IIS7, unlike previous versions, effectively has the ASP.NET worker process component "built-in". This allows web.config files to specify configuration of not only your ASP.NET site itself, but also how the IIS server hosting your site should be configured (i.e. you can specify (for example) the default document type in an ASP.NET web.config file).
If you don't specify an individual web.config for your ASP.NET site, the IIS7 server will use the "default" web.config, which is usually located in your "windows" folder within the system-wide configuration of the .NET framework itself.
This article:
Working With Configuration Files in IIS 7
from the MSDN library states:
Configuration Files
Configuration exists in a physical
directory in either server-level
configuration files or in Web.config
files. Every configuration file maps
to a specific site, application, or
virtual directory.
Server-level configuration is stored
in the following configuration files:
Machine.config. This file is located in
%windir%\Microsoft.NET\Framework\framework_version\CONFIG.
Root Web.config for the .NET Framework. This file is located in
%windir%\Microsoft.NET\Framework\framework_version\CONFIG.
ApplicationHost.config. This file is located in
%windir%\system32\inetsrv\config.
Site, application, and virtual and
physical directory configuration can
be stored in one of the following
locations:
A server-level configuration file. When configuration for a site,
application, directory, or URL is
stored in a server-level configuration
file, you must use a location tag to
specify the site, application,
directory, or URL to which the
configuration applies.
A parent-level Web.config file. When configuration for an application,
directory, or URL is stored in a
parent-level configuration file, you
must use a location tag to specify the
child at which the configuration
applies.
The Web.config file for the site, the application, or the directory.
When you configure settings for an
application, directory, or URL, the
configuration is stored in the same
directory as the site, application, or
directory. You do not need to use
location tags.
Storing configuration settings in a
parent configuration file is helpful
when:
You want to store configuration settings in a configuration file that
is accessible by only certain users or
groups. For example, the
ApplicationHost.config file is
available only to the Administrator
account and to the members of the
Administrators group on a specific
computer, as well as to domain
administrators when a computer is part
of a domain.
You want to configure a feature at the URL-level (also known as
file-level).
Also, see the following article for further information:
The new Configuration System in IIS 7
EDIT:
Regarding the specific error message that you're getting, I've seen this before on an IIS7 server, and the problem turned out to be the Application Pool that the site was set to use wasn't "running". Going into the IIS7 admin gui and starting the Application Pool cured the problem.
I have also seen this error caused wen the relevant permissions have not been set on the folder containing your website code.
See here, here, and here for further information.
Of course, since you're testing a shared hosting environment, you probably don't have access to the web server itself, and it's difficult to know exactly what you do have access to, administration-wise, through your hosting provider, but they probably have some kind of interface to set permissions on folders/files, so I'd look there first.
Failing that, you may have to include a web.config file in your "test" site as that will allow you to set configurations within IIS7 that you may otherwise have no access to.
Failing that, you may need to speak to your web host's support team.
It should be enough to inherit from machine.config. What's the exception?
I am not sure about the shared Hosting environment. But If you try to create a web application ( try ASP.Net Empty web application template) and just use Response.write("Hello World !") . it will work without any web.config.
I tried my self and it work successfully.
Only problem is that It may ask you if you wanted to debug your application then it requires to add "compilation = true" attribute in web.config.