0

Temporal ASP.NET Bug strikes again, crazy problem crazy solution.

by Jon 15. April 2011 23:32

Just 4 months ago I posted about a weird bug with ASP.Net/IIS 6 around compiling in the UK and releasing to a different time zone.  I got hit again by it again, after a customer release we discovered parts of the system werent working correctly, several controls weren’t styling or working correctly.  It took almost an hour of diagnostics to remind myself of my original blog post, so I defiantly need to write a second post on the subject.

The problem is caused when you deploy to a timezone that’s behind you, i.e. you live in the UK and you are deploying to the USA, and it only effects iis6/server 2003 or below. When you have assemblies that return content from a webresource.xsd it will throw an exception when the dll timestamp is in the future.

You have a couple of ways to fix this:

  • Don’t use old Servers/IIS6, can be tricky if you are maintaining older code, or restricted by server choice.
  • Make sure you leave enough hours between compiling and deployment to make up for the time difference
  • Make sure your server time/computer time is set at –12 timezone time
  • After you deploy to a customer site, re-timestamp the dlls

The only sensible Option

So it appears the only sensible option is to re-timestamp the DLLs, you could do this on your CI server so this never happens (but telling your CI to compile and timestamp the dlls in the future may be tricky), or you could do it on the customer site after deployment when you hit the problem.  The command to touch/re-timestamp dlls can be done from the command line.  It involves copying the dlls over the top of themselves, and applying the correct timestamp when you do it.  The command to do this is almost more crazy than the problem:

copy /b *.dll +,,

 

yeah…. you need the + and the two ,, for it to work, crazy problem, crazy solution

Tags:

asp.net | Deploy | development

0

Deploying Asp.Net to a different time zone, Temporal Future Shock! Specified argument was out of the range of valid values. Parameter name: utcDate

by Jon 17. December 2010 09:57

You would have never of thought it but if you compile ASP.NET in a different timezone you could cause yourself some temporal problems.  I recently discovered that parts of ASP.NET are date specific and if you compile an ASP.NET application in one timezone (The UK), and deploy to another timezone (California) you may find that your web application won’t work correctly until the time catches up.  Its all to do with the date stamp in the assemblies, when you install your application onto a server in california the timestamps on the assembly files may be in the future and parts of the ASP.NET framework will refuse to load them.  Just by waiting 8 hours for time to catch up the problem will resolve itself!  Its defiantly worth saying this doesn’t effect all server setups I had no problems with a customer running server 2008 in a different timezone, I only came across this problem with an AJAX enabled system when a customer was running server 2003, but I haven’t had time to test different scenarios

I installed the application the AJAX was ‘working’ however nothing was styling correctly

I viewed the source of the page and started debugging by copying the WebResource.xsd url into different tab, I was surprised to see the following error:

Server Error in '/' Application.

Specified argument was out of the range of valid values.
Parameter name: utcDate

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values.
Parameter name: utcDate
Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

I returned to the system after 8 hours and the site was working and the error was gone! Be careful out there, this was a fully patched server 2003!

Tags: , , , , , , ,

asp.net | Deploy | development | General | IIS | Maintanance | TechSupport | vs2010

0

500.19 Internal Server Error, There is a duplicate ‘system.web.extensions /scripting /scriptResourceHandler’

by Jon 29. October 2010 22:22

Http Error 500.19 There is a duplicate ‘system.web.extensions/scripting/scriptResourceHandler’

After shipping your asp.net 2.0, 3.0 or 3.5 application to a new server you get the following error:

There is a duplicate ‘system.web.extensions/scripting/scriptResourceHandler’

Don’t worry you haven’t done anything wrong, your are just trying to ship to a new server that has been configured to use .NET 4.0 as the default, and lucky for you it is a quick and simple configuration change to fix it:

Change Application Pool to .Net Framework v2.0

  • Open Internet Information Services (IIS) Manager
  • Goto the Application Pools screen
  • Open the Application Pool offending web application(s) are using
  • Change the Application Pool to use dotnet 2.0 instead of .net 4.0
  • Hard Refresh the erroring page with a <Ctrl> F5

Tags: , , , , , , , ,

asp.net | Deploy | IIS | TechSupport

5

The Asp.Net Vulnerability and DotNetBlogEngine.Net

by Jon 20. September 2010 21:34

A FIX HAS NOW BEEN RELEASED BY MICROSOFT, download from here

Looking at ScottGu's Post and DotNetBlogEngine.Net configuration it looks like DotNetBlogEngine may be one of the Web applications that is vulnerable in the out of the box configuration (I'm not 100% sure and I cant find anyone on the dotnetblogengine forums about it).  Its still not especially clear but it looks like we need to take these steps to take to secure our blogs.  Better safe than sorry, until the underlying problem is fixed?

Replace the Custom Errors in Web.Config

<customErrors mode="RemoteOnly" defaultRedirect="~/error404.aspx" />
   <error statusCode="404" redirect="error404.aspx" />
</customErrors>

With

<customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="~/fail.aspx" />

 

Then Add a new File Called fail.aspx to the root folder:

<%@ Page Language="C#" AutoEventWireup="true" %>
<%@ Import Namespace="System.Security.Cryptography" %>
<%@ Import Namespace="System.Threading" %>

<script runat="server">
   void Page_Load() {
      byte[] delay = new byte[1];
      RandomNumberGenerator prng = new RNGCryptoServiceProvider();

      prng.GetBytes(delay);
      Thread.Sleep((int)delay[0]);
        
      IDisposable disposable = prng as IDisposable;
      if (disposable != null) { disposable.Dispose(); }
    }
</script>

<html>
<head runat="server">
    <title>Error</title>
</head>
<body>
    <div>
        An error occurred while processing your request.
    </div>
</body>
</html>

For more information on the Problem and details of the fix please look at scott's post

Tags: , ,

asp.net | BlogEngine | scottgu

0

Could not load file or assembly <AssemblyName> or one of its dependencies. An attempt was made to load a program with an incorrect format

by Jon 16. September 2010 22:00

One of the recurring problems I get when installing our ASP.Net system onto customers servers is this cryptic error:

Could not load file or assembly <AssemblyName> or one of its dependencies.  An attempt was made to load a program with an incorrect format

 

The first time I saw it it really stumped me for a couple of hours to find what the problem was, the stack trace, nothing made any sence.  I eventually tracked the only difference down to the server being 64bit.  IIS can run an asp.net application in either 64 or 32bit mode and most people leave both 32bit and 64bit support enabled when they compile there ASP.Net to automatically give them improved performance on a 64bit machine.  Unfortunatly if you are using a 3rd party componant that is older, perhaps an old non managed library it is more likely to be compiled for 32bit exclusivly.  This 3rd party library means your entire application wont be able to run in 32bit mode, and to make matters worse IIS running under 64bit has 32bit support disabled by default and your Compiled code will attempt to run in 64bits, which in turn causes the nasty error message above.

There are one of two solutions:

1. find the offending library and remove it from your Web Application

2. Enable 32bit support in IIS.  

a. Go to Application Pools in IIS
b. Right click on the relevant application pool
c. Press advanced settings
d. Set Enable 32-Bit Applications to True
e. Restart the Application Pool

This quick fix will buy you time so you can remove the offending library at your leisure

Tags: , , ,

asp.net | development | IIS | TechSupport

Powered by BlogEngine.NET 2.0.0.36
Original Design by Laptop Geek, Adapted by onesoft, and finally some tiny tweaks by JonAlb