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.
Related
So, in our project we are using https://bundletransformer.codeplex.com/ to process LESS files. The problem is that in debug mode (on developer machines) it works soooo sloooow. I understand, that for production is doesn't matter, but it makes life of developers much harder. Some details:
In web.config we have the following line:
<add name="LessAssetHandler" path="*.less" verb="GET" type="BundleTransformer.Less.HttpHandlers.LessAssetHandler, BundleTransformer.Less" resourceType="File" preCondition="" />
Bundles are rendered using
#Styles.Render("~/assets/css/fileupload-css")
So when I look at page in Chrome Dev Tools, I see the following picture:
As you can see, it takes more than 3 seconds just to receive 304 back..
Weird problem is that: if right click on a line in network tab and open it in the new tab, it works super fast (49ms).
Does anybody know, how to speed it up? And could anybody tell if it's a problem in bundler, or it's by design, or something else?
Thanks.
So, the answer is this:
in web.config this thing has setting, which enables/disables cache. Just turning cache on solved the issue.
Before:
<assetHandler disableServerCache="true" disableClientCache="false" />
After:
<assetHandler disableServerCache="false" disableClientCache="false" />
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 an application, that uses System.Web.Routing and it works great on all my environments. The only issue is, that my staging environment needs the ".aspx" at the end or I will get a 404. All other environments do not require it. They all run in Classic for the Managed Pipeline Mode with v4.0 .NET framework. I keep comparing IIS settings, but I can't find any differences. I've even compared web.config and machine.config, but no differences there either. Anybody know what it could be?
Make sure you have this in your web.config (and normally you do want Integrated, unless you can't for some reason and jump through the hoops so it works under Classic).
<system.webServer>
<!-- omitted for brevity -->
<modules runAllManagedModulesForAllRequests="true"/>
</system.webServer>
runaAllManagedModulesForAllRequests has gotten me a couple times in the past.
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).
.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" />