Home Dashboard Directory Help
Search

Difference in fully patched System.Web between windows 7 and server 2003. by gonzalo_BsAs


Status: 

Active


1
0
Sign in
to vote
Type: Bug
ID: 785919
Opened: 4/30/2013 7:31:15 AM
Access Restriction: Public
0
Workaround(s)
view
0
User(s) can reproduce this bug

Description

Hi,

We hit upon a problem where one of our projects was working when tested locally (iis7 - win7 machine) but when deployed to our dev server (iis6 - server 2003) the page no longer worked. Both machines are fully updated to .net 3.5 sp1.

The page including some callbacks and is pretty complex. After some intense debugging I discovered the cause of the issue but would like someone else to verify if possible.

The problem is that in windows 7 (and windows server 2008) is seems System.Web has been patched so that the embedded WebForms.js is different than WebForms.js within System.Web as included in server 2003. This was easy to see by using reflector. Both dlls have identical version numbers (2.0.0.0), as does .net (v2.0.50727).

The difference is a single line within WebForm_CallbackComplete() - ("WebForm_ExecuteCallback(callbackObject)" has been moved to the bottom of the method). It is mentioned here http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=260892 and marked as Closed and supposedly fixed in 3.5 SP1, but we have 2 machines both with Win 2003 on and 3.5 SP1 applied, both of which don't have this fix.

WIN 7/WIN SERVER 2008

function WebForm_CallbackComplete() {
    for (var i = 0; i < __pendingCallbacks.length; i++) {
        callbackObject = __pendingCallbacks[i];
        if (callbackObject && callbackObject.xmlRequest && (callbackObject.xmlRequest.readyState == 4)) {
            if (!__pendingCallbacks[i].async) {
                __synchronousCallBackIndex = -1;
            }
            __pendingCallbacks[i] = null;
            var callbackFrameID = "__CALLBACKFRAME" + i;
            var xmlRequestFrame = document.getElementById(callbackFrameID);
            if (xmlRequestFrame) {
                xmlRequestFrame.parentNode.removeChild(xmlRequestFrame);
            }
            WebForm_ExecuteCallback(callbackObject);
        }
    }
}


WIN SERVER 2003


function WebForm_CallbackComplete() {
    for (var i = 0; i < __pendingCallbacks.length; i++) {
        callbackObject = __pendingCallbacks[i];
        if (callbackObject && callbackObject.xmlRequest && (callbackObject.xmlRequest.readyState == 4)) {
            WebForm_ExecuteCallback(callbackObject);
            if (!__pendingCallbacks[i].async) {
                __synchronousCallBackIndex = -1;
            }
            __pendingCallbacks[i] = null;
            var callbackFrameID = "__CALLBACKFRAME" + i;
            var xmlRequestFrame = document.getElementById(callbackFrameID);
            if (xmlRequestFrame) {
                xmlRequestFrame.parentNode.removeChild(xmlRequestFrame);
            }
        }
    }
}

I was wondering if anyone can verify this, and more importantly know of any reason why a patch would only be applied to the latest OS versions and not via another service pack for .NET 2.0. While this might only affect a small number of users it seems odd to only patch the framework for certain OS and to not even change the version number to make the change more obvious.

Thanks in advance.

Details
Sign in to post a comment.
Posted by Microsoft on 5/21/2013 at 11:01 AM
Thank you for your feedback!
We have already released a hotfix for this issue. The hotfix can be found from http://support.microsoft.com/kb/961864 .
Please let us know if you have more questions.
Posted by Microsoft on 4/30/2013 at 7:58 PM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by Microsoft on 4/30/2013 at 7:50 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Sign in to post a workaround.