So I'm a developer/admin for a medium size .net site, and I've run across a weird inconsistency. For reference, I'm running two instances of my site on the same server (IIS 8.5, .net 4.5); the live website and a sandbox instance of the codebase so I can test all development changes before I push them live. The config files differ only in that the sandbox site uses alternate connection strings and has it's debug flag set to true, and the sites each run on their own (identically set up) application pools.
I noticed recently that anywhere I use an asp:Image, the live site renders 'style="border-style:0px;"' onto the image tag. Interestingly, however, the sandbox instance does NOT render the style attribute.
Any idea what could be causing this discrepancy? I know that a simple solution would be to just not use asp:Images where it's a problem, but if I can I'd like to fix the underlying issue since the whole point of the sandbox is to reliably test changes on the actual server before I push them to the public site.
I got back to this issue after a few days of more pressing matters.
Turns out I missed a line in my web.config. On the sandbox site, the controlRenderingCompatibilityVersion attribute of the system.web <pages> element had been updated some time ago from 3.5 to 4.0. Apparently the live site config file never got updated, and Microsoft changed the border rendering behavior between those two versions. Updated the live site and the issue resolved itself.
Related
PLATFORM
* Asp.net Webforms - C#
* .Net 4.5
* Azure Web Hosting
* Chrome (43.0.2357.134 m) - Latest
PROBLEM
I am currently bundling CSS and Javascript using the ASP.NET Web Optimization Framework. When testing in my local environment, all is working great. You can clearly see that the aspx page is relatively small and the bundles are listed as separate individual files (cssAll & jsAll).
https://www.dropbox.com/s/dazt681qylk41hm/local-login-cache.PNG?dl=0
Once I deploy to Azure, the Javascript bundle does remain correctly linked and is cached, but the CSS bundle is no longer referenced. Instead, all CSS code is written directly into the head tag of the aspx file. This causes the aspx file to grow exponentially (from 5KB to 87KB) and it prevents the CSS from being cached. Interestingly, when I disable cache, the CSS file is now sent as a seperate file, and my aspx returns to its smaller size.
https://www.dropbox.com/s/eox7b0vc0mi27wo/azure-login-combined.PNG?dl=0
MY THOUGHTS & QUESTIONS
Is this normal behavior? Am I simply misunderstanding or misusing Chromes developer tools and/or the way CSS caching works?
If this is normal behavior, then why does my local environment respond differently to the Azure hosted environment?
If this is NOT normal behavior, then where could the issue be? (Please read considerations below to see what I have already tried or troubleshooted)
CONSIDERATIONS
I have confirmed that all CSS, Javascript, and relevant directory structures are identical between my local machine and Azure. (Web deploy handled this well)
I have tried the exact same tests with IE11 and Firefox, getting similar results. If caching is disabled, the CSS comes seperately as intended, but if caching is enabled, then CSS is verbosely written into head tag of aspx page.
Problem is not with Bundling because it is working. However, I have tried linking to each CSS file directly, rather than using the bundle, and the same oddity occurs.
I have completely cleared browser cache (using the clear browsing history in chrome) between tests and have used multiple computers to test this, yet the results are the same.
The page I am illustrating is very small, but other larger pages fair worse and can grow upwards of 600KB, due to this oddity.
The odd bundling behavior was finally resolved!
My local project was set to use "https" by default. However, when browsing my production site on Azure, I noticed it was using standard "http". Once I enforced all pages to be routed through "https" in Azure, my CSS was now properly bundled, linked and cached.
- As a disclaimer, I honestly have no idea why this works, but it clearly is a fix for my particular problem. If anyone can explain the "why", please feel free to do so.
I have this annoying CSS rendering issue that I am not sure what is causing it.
on my local copy everything looks that way I want it. When I deploy it to the server IIS.
there is one minor very minor DIV that is not rendering the way I want it or the same is what the local copy renders.
In this case, there is a padding on top and bottom of the div when there should not be. It looks fine in the local.
I tried setting the X-AU in the header but that did not help.
It is only rending that one div differently. all of the other elements looks fine. This is really strange.
Have you tried to disable IIS static content compression?
I already had issues with minified jquery and css on servers running IIS and I had to change it to non-minified versions of it.
Can you check if on your local you are running the site using SSL? I had a similar issue. I was running the site within VS 2013 and local IIS over SSL and on the live site, I was not. Fix was to configure https bindings on the live site and this fixed the issue.
i have deployed my application from IIS 6.0 to IIS 7.5. the website links does not work in IE 10 from Prod but from uat the website is accessible. both the server are same.
Does anyone know why this is happening in only one server and not the other. Do i need to change some setting in IIS or config file. I am getting the error of
SCRIPT5007: The value of the property '__doPostBack' is null or undefined, not a Function object
Can anyone please help i am facing this issue on production.
"There is a bug in the browser definition files that shipped with .NET 2.0 and .NET 4, namely that they contain definitions for a certain range of browser versions. But the versions for some browsers (like IE 10) aren't within those ranges any more. Therefore, ASP.NET sees them as unknown browsers and defaults to a down-level definition, which has certain inconveniences, like that it does not support features like JavaScript."
http://www.hanselman.com/blog/BugAndFixASPNETFailsToDetectIE10CausingDoPostBackIsUndefinedJavaScriptErrorOrMaintainFF5ScrollbarPosition.aspx
Maybe that could be it?
Thought I'd share for posterity since every page on the internet links to the browser files issue.
This can also be caused in some cases by a change in the .Net Framework 4+ where encoding the __doPostBack encodes a single quote (it did not do this in 3.5).
I was able to fix a LinkButton with that error by manually putting the __doPostBack into the OnClientClick, overriding the href and not encoding a single quote. Granted, maybe not clean, but it worked for me.
http://www.blakepell.com/asp-net-4-5-1-linkbutton-the-value-of-the-property-__dopostback-is-null-or-undefined-not-a-function-object
I have a MS Chart component displaying fine on an ASP.Net page. When I deploy it I get a broken image. The settings in the web.config are the same and the temporary images folder has the correct permissions.
When I get the URL of the images I can see that the /.png file is not getting created.
What sort of things do I need to look at to track down the problem?
I was able to resolve the issue by ensuring that my application pool settings was using "ASP .net integrated" and not "ASP .Net Classic". This will ensure that your handler is being used.
I had the same problem when I was working with the charting in .NET 4 and my problem turned out to be related to the default value of the privateImages attribute and the fact that my code wasn't using any identifying attributes for the session or the user.
See my post here for an explanation of how I solved my problem.
It's also worth noting that the ASP.NET Development server ignores the config settings for charting and renders them in memory unless you specifically set an attribute to force it to use your config.
I've just deployed my first ASP.NET MVC 2 site, and all appears to be well except I've run into an issue with IIS banning double-escaped characters, which I was relying on for a few routes.
As I don't have control over IIS (it's on a shared host) I've decided to go around the issue and replace the spaces with underscores in my URLs. Have tested and verified that this works on my local machine, and deployed the two new model classes which contain the methods that url-encode and url-decode the various bits that need this.
However, the remote website hasn't apparently noticed that I've updated the code. I've edited web.config a couple of times to try and force a recompile, deleted the remote model classes and reuploaded them, and googled around for any other reason why this would be happening. Any ideas?
Make sure you've made a xcopy to the whole site including all the assemblies that you've modified in the bin folder.
Try clearing your browser cache by pressing Ctrl+F5.