Will SYSTEM.WEB.DLL be updated with regular microsoft updates ? if so will it impact any ASP.NET application built on framework 2.0 / 3.5 in terms of performance while triggering event methods like ONROWCREATED ? coz I am
facing a weird issue related to delay in triggering ONROWCREATED event. Plz help
but I think that is 10 years old issue and most probably you had installed the update for this issue before.
so I suggest you to check and test the code again.
if necessary then try to create a new project and just try to test this
ONROWCREATED event and try to check for the delay.
if that works correctly it means there is something else that causing this issue.
you can try to debug your project again and try to check all the code that get execute with
ONROWCREATED.
check for any code which have complex logic or long execution.
which may help you to find the cause for the issue.
also if possible for you then try to copy your code to new project and try to test again for the delay.
it is possible that something get corrupted in your old project causing this delay.
further you can try to post your project with your testing code.
we will try to make a test with it on our side to reproduce the issue.
Regards
Deepak
MSDN Community Support
Please remember to click "Mark as Answer" the responses that resolved your issue.
If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.
1 . If all frameworks are installed ( v2.0.50727, 3.0, 3.5,4.0.30319) and that System.Web.dll is available in frameworks 2.0 & 4.0 , then how can I determine from which version of framework System.Web.DLL is being referred in an application. having said
that my web application is built on 3.5 framework.
how can I determine from which version of framework System.Web.DLL is being referred in an application. having said that my web application is built on 3.5 framework.
Select the System.Web assembly in the "References" folder in the Solution Explorer.
Open the properties window (F4) and check the Version.
Select the System.Web assembly in the "References" folder in the Solution Explorer.
Open the properties window (F4) and check the Version
Hi Zxj,
Thanks for the info and that worked for me in VS 2015, but can you help me determine the same on VS 2008 and I am little confused about the System.Web.Dll version that is registered in GAC is v2.0. Shouldn't it be v4.0 since its higher and framework 4 is
installed in my machine ? Please advice.
Thanks for the info and that worked for me in VS 2015, but can you help me determine the same on VS 2008 and I am little confused about the System.Web.Dll version that is registered in GAC is v2.0. Shouldn't it be v4.0 since its higher and framework 4 is installed
in my machine ? Please advice.
Visual Studio 2008 does not understand the target framework version for version 4.0.
Additionally the format of the project files are slightly different between the Visual Studio versions.
.NET Framework 4 is quite different from previous versions, and Visual Studio 2008 doesn't support this.
Thanks and that clarified a lot of things for me . Can u also help me understand my another concern - why v2.0 - System.Web.dll is registered in GAC instead of the higher version v4.0 System.Web.Dll since both versions are installed in my system and I use
both VS 2008 & VS 2015.
Thanks and that clarified a lot of things for me . Can u also help me understand my another concern - why v2.0 - System.Web.dll is registered in GAC instead of the higher version v4.0 System.Web.Dll since both versions are installed in my system and I use both
VS 2008 & VS 2015.
Starting with the .NET Framework 4, the default location for the global assembly cache is
C:\Windows\Microsoft.NET\assembly.
In earlier versions of the .NET Framework, the default location is C:\Windows\assembly.
In .NET Framework 4.0, the GAC went through a few changes. The GAC was split into two, one for each CLR.
The CLR version used for both .NET Framework 2.0 and .NET Framework 3.5 is CLR 2.0. There was no need in the previous two framework releases to split GAC. The problem of breaking older applications in Net Framework 4.0.
To avoid issues between CLR 2.0 and CLR 4.0 , the GAC is now split into private GAC’s for each runtime.The main change is that CLR v2.0 applications now cannot see CLR v4.0 assemblies in the GAC.
For example, if both .NET 1.1 and .NET 2.0 shared the same GAC, then a .NET 1.1 application, loading an assembly from this shared GAC, could get .NET 2.0 assemblies, thereby breaking the .NET 1.1 application
The CLR version used for both .NET Framework 2.0 and .NET Framework 3.5 is CLR 2.0. As a result of this, there was no need in the previous two framework releases to split the GAC. The problem of breaking older (in this case, .NET 2.0) applications
resurfaces in Net Framework 4.0 at which point CLR 4.0 released. Hence, to avoid interference issues between CLR 2.0 and CLR 4.0, the GAC is now split into private GACs for each runtime.
Because there was a CLR change in .NET 4.0 but not in 2.0 to 3.5.
The GAC has the ability to store different versions of assemblies as long as they are from the same CLR. They do not want to break old applications.
Member
1 Points
5 Posts
System.web.dll - will be updated with regular Microsoft Server updates?
Nov 10, 2017 01:25 PM|PintoSangi|LINK
Hi All
Will SYSTEM.WEB.DLL be updated with regular microsoft updates ? if so will it impact any ASP.NET application built on framework 2.0 / 3.5 in terms of performance while triggering event methods like ONROWCREATED ? coz I am facing a weird issue related to delay in triggering ONROWCREATED event. Plz help
Thanks in Advance
Contributor
2550 Points
1066 Posts
Re: System.web.dll - will be updated with regular Microsoft Server updates?
Nov 13, 2017 06:49 AM|Deepak Panchal|LINK
Hi PintoSangi,
I find one other thread which have similar issue like yours.
ASP.NET - Gridview - OnRowCreated Event triggers with delay
please try to confirm that whether it is the same issue and created by you or a different issue.
it will help us to understand the issue in better way.
if we talk about the 2.0 SYSTEM.WEB.DLL then there is some security issue with this DLL in the Past.
to resolve the issue Microsoft launched one security update on date 7/10/2007.
.NET Framework 2.0 SYSTEM.WEB.DLL Security Update for Windows Vista
but I think that is 10 years old issue and most probably you had installed the update for this issue before.
so I suggest you to check and test the code again.
if necessary then try to create a new project and just try to test this ONROWCREATED event and try to check for the delay.
if that works correctly it means there is something else that causing this issue.
you can try to debug your project again and try to check all the code that get execute with ONROWCREATED.
check for any code which have complex logic or long execution.
which may help you to find the cause for the issue.
also if possible for you then try to copy your code to new project and try to test again for the delay.
it is possible that something get corrupted in your old project causing this delay.
further you can try to post your project with your testing code.
we will try to make a test with it on our side to reproduce the issue.
Regards
Deepak
Please remember to click "Mark as Answer" the responses that resolved your issue.
If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.
Member
1 Points
5 Posts
Re: System.web.dll - will be updated with regular Microsoft Server updates?
Nov 13, 2017 10:10 AM|PintoSangi|LINK
Hi Deepak,
Thanks for your advice. Yes ASP.NET - Gridview - OnRowCreated Event triggers with delay was created my me few days back. As advised I will try to create a new project and test it but before that can you help me understand ....
1 . If all frameworks are installed ( v2.0.50727, 3.0, 3.5,4.0.30319) and that System.Web.dll is available in frameworks 2.0 & 4.0 , then how can I determine from which version of framework System.Web.DLL is being referred in an application. having said that my web application is built on 3.5 framework.
Regards
Praveen Kumar
Participant
950 Points
475 Posts
Re: System.web.dll - will be updated with regular Microsoft Server updates?
Nov 15, 2017 09:11 AM|zxj|LINK
Hi Praveen,
Select the System.Web assembly in the "References" folder in the Solution Explorer.
Open the properties window (F4) and check the Version.
Regards,
zxj
Member
1 Points
5 Posts
Re: System.web.dll - will be updated with regular Microsoft Server updates?
Nov 16, 2017 09:28 AM|PintoSangi|LINK
Hi Zxj,
Thanks for the info and that worked for me in VS 2015, but can you help me determine the same on VS 2008 and I am little confused about the System.Web.Dll version that is registered in GAC is v2.0. Shouldn't it be v4.0 since its higher and framework 4 is installed in my machine ? Please advice.
Thanks
Praveen Kumar
Participant
950 Points
475 Posts
Re: System.web.dll - will be updated with regular Microsoft Server updates?
Nov 17, 2017 01:58 AM|zxj|LINK
Hi Praveen,
Visual Studio 2008 does not understand the target framework version for version 4.0.
Additionally the format of the project files are slightly different between the Visual Studio versions.
.NET Framework 4 is quite different from previous versions, and Visual Studio 2008 doesn't support this.
Overview of .NET Framework release history
https://en.wikipedia.org/wiki/.NET_Framework_version_history#Overview
Regards,
zxj
Member
1 Points
5 Posts
Re: System.web.dll - will be updated with regular Microsoft Server updates?
Nov 17, 2017 07:37 AM|PintoSangi|LINK
HI Zxj,
Thanks and that clarified a lot of things for me . Can u also help me understand my another concern - why v2.0 - System.Web.dll is registered in GAC instead of the higher version v4.0 System.Web.Dll since both versions are installed in my system and I use both VS 2008 & VS 2015.
Thanks
Praveen Kumar
Participant
950 Points
475 Posts
Re: System.web.dll - will be updated with regular Microsoft Server updates?
Nov 17, 2017 08:11 AM|zxj|LINK
Hi Praveen,
Starting with the .NET Framework 4, the default location for the global assembly cache is C:\Windows\Microsoft.NET\assembly.
In earlier versions of the .NET Framework, the default location is C:\Windows\assembly.
You could take a look at on
Understanding The CLR Binder.In .NET Framework 4.0, the GAC went through a few changes. The GAC was split into two, one for each CLR.The CLR version used for both .NET Framework 2.0 and .NET Framework 3.5 is CLR 2.0. There was no need in the previous two framework releases to split GAC. The problem of breaking older applications in Net Framework 4.0.To avoid issues between CLR 2.0 and CLR 4.0 , the GAC is now split into private GAC’s for each runtime.The main change is that CLR v2.0 applications now cannot see CLR v4.0 assemblies in the GAC.For example, if both .NET 1.1 and .NET 2.0 shared the same GAC, then a .NET 1.1 application, loading an assembly from this shared GAC, could get .NET 2.0 assemblies, thereby breaking the .NET 1.1 applicationThe CLR version used for both .NET Framework 2.0 and .NET Framework 3.5 is CLR 2.0. As a result of this, there was no need in the previous two framework releases to split the GAC. The problem of breaking older (in this case, .NET 2.0) applications resurfaces in Net Framework 4.0 at which point CLR 4.0 released. Hence, to avoid interference issues between CLR 2.0 and CLR 4.0, the GAC is now split into private GACs for each runtime.Because there was a CLR change in .NET 4.0 but not in 2.0 to 3.5.
The GAC has the ability to store different versions of assemblies as long as they are from the same CLR. They do not want to break old applications.
Regards,
zxj
Member
1 Points
5 Posts
Re: System.web.dll - will be updated with regular Microsoft Server updates?
Nov 24, 2017 12:15 PM|PintoSangi|LINK
Thanks ZXJ