We have a .NET 2.0 application which we normally run on IIS6, and used to run fine on IIS7, but recently after installing SP1 for Vista IIS7 seems to be choking on a line in the Web.Config file:
<system.web AllowLocation="true">
Is it safe to remove the AllowLocation attribute? What does this attribute do?
From MSDN:
When set to false, the AllowLocation property indicates that the section is accessed by native-code readers. Therefore, the use of the location attribute is not allowed, because the native-code readers do not support the concept of location.
The default value is true, so you should be able to remove it with no effect on your application.
Having this set to true should enable any <location> sections in your web.config, so you should be fine to remove it if there's none in there.
Related
Consider a group of developers working on an ASP.net web application. Each developer would like to have a private version of the web.config.
By "private" I mean that a developer can freely change the file to suit their dev/test needs at any given moment, without it affecting other team members and without ending up in source control.
How can one go about achieving this with Visual Studio 2015?
My closest solution so far is to have a "private" Solution Configuration with a matching Web.config Transformation file ("web.private.config") that's excluded from source control.
But this is not a satisfactory solution because:
a. The transformation is not run automatically when debugging (with F5). The developers need to remember to run it manually.
b. The result of the transformation ends up in the main "web.config" file which is, naturally, included in source control.
We had a very similar problem but only needed personalized versions of the <appSettings> section in Web.config.
In this situation the inclusion of an external file through configSource turned out to be problematic, as this attribute completely replaces the <appSettings>-node. So there remains no way to keep global key/values AND personal key/values for all developers. The whole section is completely replaced by the included private file.
What we need is both global and private <appSettings>. The solution we found was the file attribute. It allows to merge Web.config settings with settings from an additional file.
We ended up with a construct like this one:
<!-- Web.config with global appSettings) -->
...
<appSettings file="Web.PERSONAL.config">
<add key="BaseUrl" value="https://projectname.dev.local" />
...
</appSettings>
...
<!-- Web.PERSONAL.config with personal appSettings -->
<?xml version="1.0" encoding="utf-8"?>
<appSettings >
<add key="EmailSmtpUser" value="my.name#my.domain.com" />
<add key="EmailSmtpPwd" value="***" />
</appSettings >
If you put identical keys in both files, the Web.PERSONAL.config version will overwrite the Web.config version.
The file Web.PERSONAL.config must be excluded from Git through .gitignore .
Keep in mind:
While configSource works for ALL nodes in Web.config, the file attribute is restricted to <appSettings>.
Have web.config include an external file (via configSource) and add that file to .gitignore
The correct answer is to host your local development site in a separate location from your Visual Studio solution. You can then use publish profiles to publish changes to that location and web.config transforms to maintain a separate local config for each developer. Each developer would use a different publish profile which transforms the web.config with their own transform and deploys the transformed web.config to the publish location. You can then attach a debugger to the published site using Visual Studio's Debug > Attach To Process option.
I think there is a lot of value in standardising dev environments so that one can just download the solution and run it.
Custom, long term/permanent, developer specific configs will sooner or later lead to a subtle bug that will be tricky to find.
My solution to your problem would be to find out the reason(s) why permanent individual configs are needed and have a look if these environment specific differences can be eliminated.
I have run into an issue that when my web application's web.config compilation debug is set to true I am getting a vulnerability error on a security scan.
What I want to determine is if there is a way to have some type of web.config conditional block change the debug setting to use the correct value on debug builds and release builds. I have read that setting the property in each web page itself will do this and don't know if this is in fact true and are there any problems with this?
I would suggest <deployment retail=”true”/>.
You put this element into your machine.config on the production server and it overrides debug=”true” in your web.config and pages. In other words, you can happily use the debug and trace functionality on your developer machines but can be sure it is turned off on the production server. Scott Guthrie recommends this as best practice.
is it possible to set a default page to run when starting debugging? In Visual Studio you can set the default page either through the context menu in Solution Explorer or in the project properties. I did not find something like that in MonoDevelop.
When I am starting debugging the browser will always navigate to the root of the application.
http://localhost:8080
Because there is no default page set in XSP for this application I get an error and always have to correct it manually.
http://localhost:8080/home.aspx
Thanks for your help.
I found a solution. I did not find the xsp.exe.config but it also works when you add the setting either globally in machine.config (residing in /etc/mono/[version]) or by creating a web.config file in your applications root. The values are comma separated.
<appSettings>
<add key="MonoServerDefaultIndexFiles" value="Home.aspx, home.aspx" />
</appSettings>
The help page http://www.mono-project.com/Config does not tell you that a appSettings section is allowed, but I think that the documentation is just incomplete. For example appSettings are used here http://www.mono-project.com/ASP.NET_Settings_Mapping#Inhibiting_the_settings_mapping too.
.NET 4 broke ValidateRequest=“false” for some reason.
The solution is -- just put <httpRuntime requestValidationMode="2.0" /> into your web.config file.
The problem with that solution is that it breaks support for .NET 2.0!
IIS refuses to accept unknown attributes in web.config. Also I don't like the all or nothing nature of this.
Can I set requestValidationMode (or in some other way disable request validation) for a single page that needs it? Without breaking backwards compatibility of web.config with 2.0?
I can confirm that the approach of adding validateRequest="true" to the web.config file works and it is marvellous!
Using this makes the page-level directives work correctly again and it avoids the need to change the behaviour back to the ASP.Net2.0 mode.
Strange that it has any effect, seeing as request validation is normally enabled by default anyway, but no matter.
if you are using .net4 then add this line to web config
<pages validateRequest="false">
and no need to use <httpRuntime requestValidationMode="2.0" /> at all
OK, looks like this can't be done and I can just escape the data easily, but I think this was a legitimate question -- at least to make a note here that this can't be done.
I found a better way, I think. I didn't like the option of reverting back to a 2.0 setting while in 4.0. I also don't like the all or none option.
I played around with a few things and I have at least in my mind a practical solution.
By default all pages are validated regardless of the page directive of "ValidateRequest="false"
I found where to make this setting in the web.config in the system.web section called pages.
(http://msdn.microsoft.com/en-us/library/system.web.configuration.pagessection.validaterequest.aspx)
If the validateRequest attribute is added into the pages element you can control the validation for the whole site.
But I stumbled across a happy thing while testing this. I couldn't find docuementation for this, but here is what I've experienced.
By default validation is turned on everywhere, but if I set the validateRequest to "true" my individual page directives work as they did in 2.0. I don't know why, but I'm happy.
So in summary...
Set the validateRequest to true.
Like here.
Then any page directives work for that validation.
I just put this in my web.config in the system.web node.
<httpRuntime requestValidationMode="2.0" />
I have a folder containing several websites, all using the same assemblies in the GAC. Each website also contains some 'custom' assemblies of their own that refer to the common assemblies.
There is a web.config in this folder, defining common settings for the sites, including the assemblies to load in a <system.web>/<compilation>/<assemblies> element.
What I want to be able to do is add a <runtime>/<assemblyBinding> section to redirect requests from the older 'custom' assemblies to the newer ones installed in the GAC. (Unfortunately, using machine.config or the GAC redirection policy aren't options as this will affect other sites.)
It seems that the <assemblyBinding> section is ignored unless it is in the website's own web.config, or the machine.config.
I've already come across the <configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0"> problem so I know it's not that.
Does anyone know if this is what is supposed to happen or am I missing something?
It is supposed to happen. You did nothing wrong.
for more information, please take a look at
http://msdn.microsoft.com/en-us/library/2fc472t2(vs.71).aspx