Is anyone aware of any situations in which an ASP.NET 2.0 webservice might be unable to read the appSettings values from the web.config? I seem to have exactly that problem - the code thinks the appSettings is empty when it isn't.
In more detail: This code:
Dim settings = ConfigurationManager.AppSettings
Dim count = settings.Count ' always gives zero
Incorrectly shows that there is no data in the app settings.
My web config looks like this
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
<!-- lots of other stuff -->
<appSettings>
<add key="SomeKey" value="Some Data" />
<!-- other keys -->
</appSettings>
</configuration>
I've verified that the code can see the web.config file (by the simple device of commenting out everything in the file, and seeing that when I try to run the service, it complains that the web.config is invalid).
The code is production code which does in principle work, just not apparently on my machine - so I'm guessing the problem has something to do with my environment, it's almost certainly not a problem with the code.
Ah, it seems the reason was absurdly simple. I just needed to recompile the VB code! What happened was that, because I was (correctly, as it happens) convinced there was nothing wrong with the VB code, I focused all my efforts on fiddling with the web.config and with the IIS settings (because those were the things that might conceivably be different between my machine and the known working live program). Eventually I gave up on that, and decided to temporarily work around by changing the VB code to use hardcoded values instead. As soon as I did that and rebuilt, I found that the program now picked up the appSettings correctly (and my hack became unnecessary).
So, my guess is that somehow the VB code became detached from the web.config, and needed recompiling to re-attach it. I'm somewhat puzzled because I thought that ASP.NET would automatically detect changes to the web.config and so recompile anyway, but evidently not.
If anyone can satisfy my curiosity by explaining what might have been going on in ASP.NET that could result in an explicit code-recompile being necessary to read the web.config correctly, then I'll mark that as the answer to my original question. (If noone does after a day or so, I'll mark this post as the answer).
Related
There are 2 relevant questions on this site on this issue, none of them seems to go to any detail or provide any solution that has proven helpful. They are:
The 'CodeFile' attribute cannot be used without an 'Inherits' attribute
ASP.NET CodeFile, CodeBehind and Inherits
I am not sure what type of project this is, I believe it is a either ASP WebForms or ASP WebSite. Some more illuminated individual here may ask the correct question to figure that out, I would appreciate that.
Regardless, this issue has been happening on and off and we're never quite sure what causes it exactly nor what we've done to fix in the past. What I am sure is that I've way to many hours doing nothing but staring at this cryptic output to no avail.
Every time, the story is something like:
Everything fine, compiling, all working ?great? (sort of, its an old project...).
Do some changes; that works as expected.
Do some change; that results in this error. (sometimes some git operation is involved, and this is a big suspect for me.)
Retry compile. (Let us say, it works 9 out of 10)
But then comes that 10th time, and no luck.
Do ??? and it starts working (mostly restore a hard backup of the machine's project folder, done daily)
This is frustrating and counter-productive. We're never quite sure what we did that caused it or what fixed it.
Any help would be very much appreciated. Here is a screenshot of the error in Visual Studio 2019.
Figured it.
So the real question here is, should the Web.config file be added to version control?
Yes
Of course. The project will not compile without the correct Web.config file.
No
The Web.config file is for environment configuration (you know, environment variables are so outdated.). You should never place things like database credentials in source control.
ASP
So the answer, in ASP, is yes and no. For the reasons above. If this is not crazy, I'm crazy.
It turns out, the Web.config file had been tampered with. I had;
<system.web>
<compilation explicit="false" strict="false" targetFramework="4.5.2" debug="true">
(...)
</system.web>
Where it should have been:
<system.web>
<compilation explicit="false" strict="false" targetFramework="4.7.2" debug="true">
(...)
</system.web>
Can you spot the difference? Its not easy, in fact not even Visual Studio was able to understand, or tell me, what was wrong. But that little pesky 4.5.2 should have been 4.7.2. Its not like we changed it. It had been like that for a while before this non sense.
What a cryptic framework.
I am creating a very simple site that was originally just a bunch of HTML / CSS files. Then I needed to add a little bit of server-side logic so I thought I'd use ASP.NET Web Pages as they sound like a suitable solution.
So I changed index.html to index.cshtml, added the code I needed and I though that would be it (I also added this basic web.config file:
<configuration>
<system.web>
<compilation debug="true" targetFramework="4.0" />
</system.web>
</configuration>
However, launching this on local IIS Express yielded this error:
Could not determine which version of ASP.NET Web Pages to use.
In order to use this site, specify a version in the site’s web.config file. For more information, see the following article on the Microsoft support site: http://go.microsoft.com/fwlink/?LinkId=254126
So I added this to my web.config:
<appSettings >
<add key="webPages:Version" value="2.0" />
</appSettings >
Now the site starts but handles UTF-8 really weirdly - although all the HTTP headers, file encodings and meta tags are correctly set to UTF-8, my national characters display incorrectly. I found this question: Do I need web.config for non-ASCII characters? but it didn't really solve my problem.
I though, what can be wrong with my setup? When I create a new site in WebMatrix and copy my files over to it, it all works fine, even without specifying the Web Pages version in web.config. And the only difference I can see is the presence of bin folder in the WebMatrix-generated project.
So the question is, do I need to have the bin folder as part of my source files too? I don't really feel like checking 1.5MB worth of binary files into Git should be necessary just to add one dynamic line in my index.cshtml but maybe that's how it is?
Thanks for either confirming this or showing me some better way.
ASP.NET WebPages requires a BOM on UTF-8 pages or it won't read the page as UTF-8. And if it doesn't do that, it won't output a UTF-8 encoded page.
This isn't an ASP.NET issue, but rather a WebPages issue. WebPages processes the real page, and it doesn't interpret the html to know that it should be UTF-8. The only way it knows is by looking for a BOM.
I have published an ASP.NET MVC3 site. It runs great. However, looking back at my web.config file, I was not sure if some of the values I used are correct for publishing versus for developing. These configurations are in the <system.web> section.
...
<system.web>
<httpRuntime requestValidationMode="2.0" executionTimeout="200" maxRequestLength="20000000"/>
<compilation debug="true" targetFramework="4.0">
...
I read here ( http://msdn.microsoft.com/en-us/library/e1f13641.aspx ) that using debug=true in compilation will disregard the executionTimeout of 200, and use a default value of 110. This seems to be the case, and the site is setup to allow very large amounts of files to be uploaded all at once. However, with only 110 seconds, not much can be uploaded.
My question is this: Is the correct setting to publish a live site for debug "false"? In addition, is requestValidationMode="2.0" still safe to use considering asp.net is now on version 4 (soon to be 4.5)?
Validationmode 2.0 is not the framework version and can stay like that.
Put debug=false and you are fine.
requestValidationMode... As far as I'm aware, this has to be set to 2.0 if you want to allow special characters (<, >, % etc.) in request data to pass ASP.NET's request validation at all. requestValidationMode="2.0" means "only enforce validation on pages (i.e. .aspx), rather than on every request (as was introduced in 4.0). That allows ASP.NET MVC to take over the validation - and hence also lets you turn it off for specific requests.
Is it safe? It is, if you've made sure that any actions or controllers that have [ValidateInput(false)] applied or models with [AllowHtml] have been properly secured against attacks. Imran Baloch has a full explanation here.
And yes, debug should be "false" for several reasons, including performance and memory usage. Also, debug="true" changes the default cache policy for static files to never cache the files in the browser, meaning tons of redundant requests for scripts, CSS etc.
As for the image upload, other than the suggestions given, check in Event Viewer that it's not really the application pool recycling for one reason or other, rather than an execution timeout.
.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 understand that I can redirect a user on an exception by setting the customErrors element in the Web.config
<customErrors mode="On" defaultRedirect="/WebTest/ErrorPages/AppError.html">
</customErrors>
I could also do a Response.Redirect in the Application_Error event in the Global.asax file.
What are the differences between these 2 approaches and which one is preferred?
If you don't want to do anything with the error (such as logging), you'd better simply use the configuration file. It's simpler and easier to reconfigure. Moreover, using the configuration file has the advantage of supporting RemoteOnly type, where you can easily see the exception on the server for diagnostics purposes but others won't be able to see it.
In general, there's no point in writing code for something that's perfectly configurable and is built in the system. Code is more prone to errors than configuration options.
I am not sure of anything official, but I find using the config file easier for local testing versus production behaviour.