I have a .NET 4.0 web application which uses an asp gridview control to display data. The control will automatically sort data when a column header is clicked. I have this application running and sorting fine on both a dev and test server. However, on the prod server, it does not sort correctly. No error is thrown, it just does not act correctly. Since the code is identical I believe this has to be an environment issue.
When trying to troubleshoot this issue, I deliberately malformed the web.config in both environments and noticed the following difference when the error page is displayed:
Dev (code works as expected):
Version Information: Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.0.30319.34249
Prod (code does not work as expected):
Version Information: Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.6.81.0
Could this be the cause of the issue? What exactly does this signify? Trying to find this answer on my own has proved fruitless. Any help is appreciated. Thanks!
This issue is caused by ASP.NET Version:4.6.81.0. When updating the dev server to match this version, the gridview does not sort correctly. I'm uncertain as to whether or not this is a bug in ASP.NET or a fix for a bug which was exploited by the code. Regardless, the original issue was caused by difference in ASP.NET versions.
Related
I have an ASP.NET application written in .NET 4.0. When I run the application through Visual Studio, everything works and looks good. Same thing when I deploy it to IIS7 on my local machine. However, when I deploy it to another box running on Windows Server 2008 R2 with .NET 4.0 and IIS7, I get the following parse error:
Cannot create an object of type 'System.Web.UI.WebControls.TextBoxMode' from its
string representation 'Number' for the 'TextMode' property.
It's complaining that the TextMode property on asp:TextBox doesn't contain the Number option, even though it works perfectly fine on my local IIS. I came across this post and people are suggesting the two machines have different .NET versions. This is not the case for me; both machines are have .NET 4.0 and IIS7.
Besides this error, other pages are also rendered differently style-wise. For example, IIS on the server machine doesn't respect the Width property on any of the asp:TextBox controls; I have to apply the width as a style, even though my local IIS renders them just fine. I'm using IE10 w/o compatibility mode.
I originally thought the problem might have been with missing js or style files, but IE reports success status for all content files in the Network Profiler window.
I'm truly lost at this point. The code, IIS settings, and .NET versions are exactly identical on these two boxes, but the pages are rendered differently. The only thing I can think of is that some other Web component was installed with Visual Studio that is changing the way IIS renders aspx pages. Is that possible? If anyone has come across this issue at some point I'd appreciate it if you could give me some pointers as to what could be causing the issue.
So I finally figured out what the problem was. The parse error did in fact have something to do with .NET. I have .NET 4.5 installed on my machine but not on the server. What I'm still confused about is that the target version for my application is 4.5, so if the Number option exists only in 4.5, why does Visual Studio even display it? Not sure if that's a bug or if I'm overlooking something.
As for the discrepancies between local and server IIS, it turned out I had to install the ASP.NET Browser Definitions Hotfix (KB2600088) on the server. That fixed all the styling issues.
I was trying to use Sample application OpenIdProviderWebForms Application from DotNetOpenAuth-4.0.0.12084.
It was working fine with OpenIdRelyingPartyWebForms when I used it as it is but suddenly I started getting following error
Error while reading message
'DotNetOpenAuth.OpenId.Messages.CheckIdRequest' parameter
'openid.claimed_id' with value
'http://specs.openid.net/auth/2.0/identifier_select'. Invalid cast
from 'System.String' to 'DotNetOpenAuth.OpenId.Identifier'. (Contact:
, Reference: )
It happened just after I moved the provider application to .Net 4.0 using visual studio(2010)'s project properties. I noticed it was Intermittent. It was not visible each time.
I need help to understand the issue.
BTW the problem was resolved when I moved back to .net 3.5...
But I need this to work on .Net 4.0
I moved to DotNetOpenAuth v4.1.2.12274 and it was working...
I have inherited a working VB.NET 2.0 web app that has several User Controls with GridViews inside Update Panels. After running the VS 2010 Upgrade Wizard, the app runs fine in the debugger except for a couple of these Gridviews. In these, update and delete work but adding a new item causes the following javascript error when Save is clicked (calling DoPostBackWithOptions):
Microsoft jscript runtime error
Sys.WebForms.PageRequestManagerServerErrorException: Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index
My theory is that the code is fine (I haven't touched it) and that there is some sort of configuration issue causing this. I have looked through SO and elsewhere and have tweaked my web config and updated the Ajax toolkit assembly. I got nowhere stepping thru the ScriptResource.axd javascript throwing the error. Any suggestions?
Update
The app works fine if I upgrade it to .NET 3.5 using the VS 2008 wizard. However, if I then upgrade that to 4.0 with VS 2010 the problem resurfaces.
Have you tried setting the controlRenderingCompatibilityVersion? The upgrade process should have included it for you, but it might be the cause of your heartache. It's in the <pages... tag of your web.config file...
This is only a workaround not a fix. But I figured I'd add it to help anyone else that might have a similar issue.
What I have figured out is that the project upgrades to .NET 3.5 just fine but that going 4.0 breaks it. I am not sure if the framework breaks it or the upgrade wizard does.
So the successful path for me has been:
Open in VS 2008 and run the upgrade
wizard to upgrade to 3.5.
Open the project again in VS 2010
and run the upgrade wizard but opt
to leave it on the 3.5 framework.
At this point the project behaves fine and I can used VS 2010 to make my updates.
Opening a .Net 2 project in VS2010 it converts the project without any issues BUT when I attempt to build it fails.
The reason is that in VS2005 a reference was added to System.Web.Extensions which is a .Net 3.5 assembly. Now VS2005 never complained at this and quite happily worked but VS2010 is far more strict and won't allow it.
I've tried changing the targeted framework to .Net 3.5 but I get another situation there where the web page is never displayed, it simply hangs not even getting to Applicatin_OnStart.
Any help either on adding the reference with .Net 2 as target framework (prefered option for time) or getting the .Net 3.5 version to work would be greatly appreciated.
[Edit]
Ok so maybe the reference was a read herring. One of my colleagues opened the project and did the conversion and once he changed the targetted framework to .Net 3.5 it all worked. The difference between our machines is that he's on 32 bit XP and I'm on 64 bit Windows 7. When I change the targetted version and try to run the program the build seems to stop at CppCodeProvider and hang.
[Edit]
Check your web.config file for the references to System.Web.Extensions. It could be there are duplicate entries or entries pointing to older versions.
Check if the project is just targeting the client profile. The following link could provide you additional information: System.Web.Extensions Assembly cannot be resolved
We've been working on an application that quite heavily relies on VirtualPathProviders in ASP.NET.
We've just come to put the thing on a live server to demonstrate it and it appears that the VirtualPathProviders simply don't work when the site is pre-compiled!!
I've been looking at the workaround which has been posted here: http://sunali.com/2008/01/09/virtualpathprovider-in-precompiled-web-sites/, but so far I haven't been able to get that to work, either! (Well - it works fine in visual studio's web development server - just not on our IIS box - again!).
Does anybody here have any more information on the problem? Is it fixed in .NET v3.5 (we're currently building for v2.0)?
Unfortunately that is not officially supported. See the following MSDN article.
If a Web site is precompiled for deployment, content provided by a VirtualPathProvider instance is not compiled, and no VirtualPathProvider instances are used by the precompiled site.
The site you referred to is an unofficial workaround. I don't think it's been fixed in .NET 3.5 SP1