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" />
Related
I have a really weird situation, for months now, and not being able to find a solution.
In a .net application using mvc bundles, i create a new bundle in every request, containing the scripts and styles needed for this request. This is working just fine most of the time.
The problem is that sometimes during development and more often during a clean deployment, the bundle requests return 404.
When this bug occurs (can't reproduce it) i try the following:
IISReset and then refresh - still 404!
Restart application pool - still 404!
Random edit in web.config - still 404!
Cut all files of the project and then copy them back, then refresh - still 404!
Cut all files of the project, refresh page to generate error due to empty folder and then copy the cut files back - fixed!
Editing Compilation element with debug=false, refresh page, and then debug=true again - fixed!
As you see this doesn't make any sense!
Any ideas, anyone?
thanks in advance
Found it!!
Just add the following in web.config
<modules>
<remove name="BundleModule" />
<add name="BundleModule" type="System.Web.Optimization.BundleModule" />
</modules>
I have been working on a very complex asp.net program and suddenly after 2 years of development I receive the following:
I cannot post the Screen Image where but you can see it at:
http://vmcsys.com/images/VSCorruption.jpg)
This happens in VS2012 Professional while starting a debug session. The program runs fine outside using any of the major internet browsers.
I have wiped out the entire directory, downloaded a backup. It seems no matter what I do, I still run into this program. Where is ScriptResource.axd located? Should I reinstall VS2012? I am also using Ajax Toolkit. Any ideas would very much be appreciated. Thanks!
Solved this by adding the following to Webconfig file
<system.web.extensions>
<scripting>
<scriptResourceHandler enableCompression="false" enableCaching="true"/>
</scripting>
</system.web.extensions>
I know this question has been asked in other threads, but none of the solutions provided could fix my problem.
When I upload a file greater than ~4MB (i.e. bigger than default), I get the "Internet Explorer cannot display the webpage" error. (Files smaller has no problems).
Here's what I've done so far:
1) Edited webconfig:
<httpRuntime maxRequestLength="20480" executionTimeout="3600" enable="true"/>
<customErrors mode="Off"></customErrors>
AND
<requestLimits maxAllowedContentLength="20000000000" />
2) Updated hosts file (C:\Windows\System32\drivers\etc\hosts) to remove line:
:: 1 localhost
3) Tested on IE, Chrome, and Firefox (all have the same issues).
4) Tried using IE's developer tools but not quite sure what to look for.
Would really really appreciate any advice/guidance on this! I've spent almost 2 days on this and still cannot figure it out. I gather it must be the file size issue (since I have load smaller files...)
THANKS so much!
Assuming that you have file upload control as follows:
<asp:FileUpload ID="flUpImg" runat="server"/>
when uploading is done you usually upload files to the server by clicking a button.
In that button click event check for
flUpImg.PostedFile.ContentLength
let xxxx be the value returned.
Note it down and stop debugging.
Go to web.config file and edit the following tag as
<httpRuntime maxRequestLength="value greater than xxxx"/>
where xxxx is the size of the uploaded files.
Two more things to look at:
1) Are you running UrlScan or some other IIS add-in? You can check through the IIS console by choosing your web-site and clicking ISAPI Filters. If so, check whether it too has an upload size limit that you need to override: e.g., C:\Windows\System32\inetsrv\urlscan\urlscan.ini, [RequestLimits], MaxAllowedContentLength=1073741824.
2) Check your global .config files: machine.config and root-level web.config in e.g. C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config (for 64-bit applications running .NET 4) for <system.web /> and applicationHost.config in C:\Windows\System32\inetsrv\config for <system.webServer /> in case there are any non-standard settings in there such as allowDefinition="MachineOnly" or allowOverride="false". I suspect this isn't the problem, as you would probably see some sort of message on the screen or in the application event log if it were; something else to tick off your list, though.
I was facing the same issue which got resolved by adding below in web.config under system.web.
<httpRuntime maxRequestLength="20480" executionTimeout="3600" enable="true"/>
The key is the maxRequestLength="20480" inside your <httpRuntime> tag. It's failing because the page is rejecting the file you're testing, which is evidently larger than 20MB. If you check the file you're testing you'll probably notice this.
Try setting this figure a lot higher and you will get some success!:
<httpRuntime maxRequestLength="51200" executionTimeout="3600" enable="true"/>
I can't get script files to load on my website. Everything else works fine. I haven't tried ScriptResource.axd however.
I have verified this issue exists on both cassini and IIS7.
I have verified my 64bit 4.0 web.config contains the mapping for WebResource.axd.
My system time is correct (I heard there may be issues with that).
I have verified that it works in other projects, so the culprit has to be my web application.
My web application is 4.0 MVC3 web application.
My web.config can be found here.
This error is killing me! Any help would be appreciated!
Your web.config file is amazing (it's not a compliment): in .NET Framework 4.0, it should be much shorter/lighter.
I think that your handler is declared in the wrong section :
<system.webServer>
<handlers>
<add name="WebResource" path="WebResource.axd" verb="GET" type="System.Web.Handlers.AssemblyResourceLoader" />
</handlers>
</system.webServer>
Normally, the WebResource.axd handler is declared in "system.web" section :
<system.web>
<httpHandlers>
<add path="WebResource.axd" verb="GET" type="System.Web.Handlers.AssemblyResourceLoader" validate="True" />
</httpHandlers>
</system.web>
I resolved a similar issue by adding read permissions for Everyone to the folder where the assembly containing the embedded resource was located. Clearly Everyone is overkill, but that might help others researching similar issues.
In our case some resources loaded (so I know the AssemblyResourceLoader was working) and it worked on one machine but not another.
This answer to another question helped me determine what assemblies were not working.
I solved this issue on a production machine running again aspnet_regiis:
%WINDIR%\Microsoft .NET\Framework\4.xxxx\aspnet_regiis -i
Probably the standard installation of the framework 4 went wrong.
Bit late but might help someone in the future...
I found that this can happen if the DLL of the web application you are delivering are newer than the current date time. For example, you put your web application on the production server where the server time is older than on your development machine.
Getting the server time in sync with the dev machine did the trick for me...
Absolutely solution is : https://web.archive.org/web/20211020131200/https://www.4guysfromrolla.com/articles/080906-1.aspx
when you check the .net framework code : https://github.com/Microsoft/referencesource/blob/master/System.Web/Handlers/AssemblyResourceLoader.cs
you can see the trick : at line 606
WebResourceAttribute wra = FindWebResourceAttribute(assembly, resourceName);
if the assembly does not have WebResourceAttribute it throws 404 error.
You can see at this line
if (resourceStream == null) {
if (resourceIdentifierPresent) {
LogWebResourceFailure(decryptedData, exception);
}
throw new HttpException(404, SR.GetString(SR.AssemblyResourceLoader_InvalidRequest));
}
so add the WebResourceAttribute to your AssemblyInfo.cs file like this :
[assembly: WebResource("FullNameSpace.SampleResourceFile.js", "text/javascript")]
I had this .axd issue with Umbraco on a production server, it drove me crazy until I found out that the server had different security and under Request Filtering, the extensions .axd and .asmx were not listed in the Allowed filenames by default, and the hosting company had the setting Allow unlisted file name extensions turned off, which was different to my development machine.
None of the previous solutions worked out for me. Although it took me some time, in the end it was as simple as this:
Plesk Admins, Please disable the Web Application Firewall to solve this issue.
Tools & Settings > Web Application Firewall > Turn Off
Cheers!
Colin's tip got me looking at my new webhost (InterServer). Turns out their Web Application Firewall was the culprit. Switch it to Detect Only or Off, and it's fine.
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).