Allow users to disable use of Logical Call Context #632

Closed
TomDeWitt opened this Issue Nov 13, 2013 · 112 comments

Comments

Projects
None yet
@TomDeWitt

I updated Glimpse ADO, ASP.NET, Core, EF5, and Mvc4 via NuGet this morning and I am now getting a run time error of Type 'System.Web.HttpContextWrapper' in assembly 'System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' is not marked as serializable.

The complete exception detail:

System.Runtime.Serialization.SerializationException was unhandled
HResult=-2146233076
Message=Type 'System.Web.HttpContextWrapper' in assembly 'System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' is not marked as serializable.
Source=WebDev.WebHost40
StackTrace:
at Microsoft.VisualStudio.WebHost.Host.ProcessRequest(Connection conn)
at Microsoft.VisualStudio.WebHost.Server.OnSocketAccept(Object acceptedSocket)
at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(Object state)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
at System.Threading.ThreadPoolWorkQueue.Dispatch()
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()
InnerException:

I am running an MVC4 application from VS2010. The only changes to the project where the NuGet packages for Glimpse.

@bmavity

This comment has been minimized.

Show comment
Hide comment
@bmavity

bmavity Nov 13, 2013

I just installed Glimpse MVC 3 with NuGet in a previously working app and got the exact same error when I tried to start up the app with Visual Studio 2012 dev server.

bmavity commented Nov 13, 2013

I just installed Glimpse MVC 3 with NuGet in a previously working app and got the exact same error when I tried to start up the app with Visual Studio 2012 dev server.

@CGijbels

This comment has been minimized.

Show comment
Hide comment
@CGijbels

CGijbels Nov 13, 2013

Collaborator

Ok, I think I start to understand why @TomDeWitt and @ameshlal first mentioned the issue on the closed issue #610 which made no sense to me, since that sample was not available on NuGet

But it seems the issue is the same we had with issue #610 which we solved by not using the VS dev server and switching over to IISExpress, but which apparently let slip a real bug into the latest release.

I somehow have the feeling it is related to running in classic mode instead of integrated mode, but that is something we need to check

can you confirm the issue is gone it you use IISExpress instead of VS dev server?

Collaborator

CGijbels commented Nov 13, 2013

Ok, I think I start to understand why @TomDeWitt and @ameshlal first mentioned the issue on the closed issue #610 which made no sense to me, since that sample was not available on NuGet

But it seems the issue is the same we had with issue #610 which we solved by not using the VS dev server and switching over to IISExpress, but which apparently let slip a real bug into the latest release.

I somehow have the feeling it is related to running in classic mode instead of integrated mode, but that is something we need to check

can you confirm the issue is gone it you use IISExpress instead of VS dev server?

@TomDeWitt

This comment has been minimized.

Show comment
Hide comment
@TomDeWitt

TomDeWitt Nov 13, 2013

CGijbels, the issue does go away if you use IISExpress instead of VS dev server.

CGijbels, the issue does go away if you use IISExpress instead of VS dev server.

@CGijbels

This comment has been minimized.

Show comment
Hide comment
@CGijbels

CGijbels Nov 13, 2013

Collaborator

@TomDeWitt thanks for the confirmation, we'll have a look at it, because I'm sure you guys are not the only ones using the VS DEV Server

Collaborator

CGijbels commented Nov 13, 2013

@TomDeWitt thanks for the confirmation, we'll have a look at it, because I'm sure you guys are not the only ones using the VS DEV Server

@CGijbels

This comment has been minimized.

Show comment
Hide comment
@CGijbels

CGijbels Nov 13, 2013

Collaborator

Alright, I've found the commit that added the System.Web.HttpContextWrapper to the CallContext

The commit above is quite old but has been merged in the master branch this release (1.6.0 Glimpse.AspNet)

It seems that the way the VS Dev Server works, is that it makes a cross AppDomain call at some point, trying to serialize what's in the CallContext and then fails, something that is not happening when running in IISExpress or IIS for that matter (to be checked more thoroughly)

I'm not sure if Classic vs Integrated mode is the issue here, but rather the way the VS Dev Server works?

Now the question is: is there a workaround? Because I tried wrapping the HttpContextWrapper in my own wrapper but in the end it fails serializing my wrapper, since it is not serializable either, which makes perfect sense.

@dahlbyk Have you ever used your proposed change in combination with code running in the VS Dev Server?

@nikmd23 @avanderhoorn what do you guys think? Can we work around it or should we say that VS Dev Server is no longer supported in favor of async calls?

Collaborator

CGijbels commented Nov 13, 2013

Alright, I've found the commit that added the System.Web.HttpContextWrapper to the CallContext

The commit above is quite old but has been merged in the master branch this release (1.6.0 Glimpse.AspNet)

It seems that the way the VS Dev Server works, is that it makes a cross AppDomain call at some point, trying to serialize what's in the CallContext and then fails, something that is not happening when running in IISExpress or IIS for that matter (to be checked more thoroughly)

I'm not sure if Classic vs Integrated mode is the issue here, but rather the way the VS Dev Server works?

Now the question is: is there a workaround? Because I tried wrapping the HttpContextWrapper in my own wrapper but in the end it fails serializing my wrapper, since it is not serializable either, which makes perfect sense.

@dahlbyk Have you ever used your proposed change in combination with code running in the VS Dev Server?

@nikmd23 @avanderhoorn what do you guys think? Can we work around it or should we say that VS Dev Server is no longer supported in favor of async calls?

@dahlbyk

This comment has been minimized.

Show comment
Hide comment
@dahlbyk

dahlbyk Nov 13, 2013

Contributor

@dahlbyk Have you ever used your proposed change in combination with code running in the VS Dev Server?

I tested in IIS 7 and IIS Express, but not VS Dev Server.

I wonder if making a serializable wrapper that explicitly marks the wrapped field as [NonSerialized] would do the trick? Trying now...

Contributor

dahlbyk commented Nov 13, 2013

@dahlbyk Have you ever used your proposed change in combination with code running in the VS Dev Server?

I tested in IIS 7 and IIS Express, but not VS Dev Server.

I wonder if making a serializable wrapper that explicitly marks the wrapped field as [NonSerialized] would do the trick? Trying now...

@CGijbels

This comment has been minimized.

Show comment
Hide comment
@CGijbels

CGijbels Nov 13, 2013

Collaborator

@dahlbyk but if you don't serialize it, then it won't be available on "the other side", resulting in a null reference at one moment or the other no? And you can't create a new instance because that would break the app as well?

Collaborator

CGijbels commented Nov 13, 2013

@dahlbyk but if you don't serialize it, then it won't be available on "the other side", resulting in a null reference at one moment or the other no? And you can't create a new instance because that would break the app as well?

@dahlbyk

This comment has been minimized.

Show comment
Hide comment
@dahlbyk

dahlbyk Nov 13, 2013

Contributor

The theory is to make the instance self-healing, if you will:

    [Serializable]
    public class SerializableHttpContextWrapper
    {
        [NonSerialized]
        private HttpContextBase current;

        public SerializableHttpContextWrapper()
        {
            if (Context == null)
            {
                throw new InvalidOperationException("Missing HttpContext");
            }
        }

        public HttpContextBase Context
        {
            get { return current ?? (current = new HttpContextWrapper(HttpContext.Current)); }
        }
    }

And then we store the wrapper with the logical context.

That's the theory. In practice, I'm getting...

Type is not resolved for member 'Glimpse.AspNet.SerializableHttpContextWrapper,Glimpse.AspNet, Version=1.4.1.0, Culture=neutral, PublicKeyToken=null'.

No idea why. I'll push my spike to a branch if you'd like to take a look.

Contributor

dahlbyk commented Nov 13, 2013

The theory is to make the instance self-healing, if you will:

    [Serializable]
    public class SerializableHttpContextWrapper
    {
        [NonSerialized]
        private HttpContextBase current;

        public SerializableHttpContextWrapper()
        {
            if (Context == null)
            {
                throw new InvalidOperationException("Missing HttpContext");
            }
        }

        public HttpContextBase Context
        {
            get { return current ?? (current = new HttpContextWrapper(HttpContext.Current)); }
        }
    }

And then we store the wrapper with the logical context.

That's the theory. In practice, I'm getting...

Type is not resolved for member 'Glimpse.AspNet.SerializableHttpContextWrapper,Glimpse.AspNet, Version=1.4.1.0, Culture=neutral, PublicKeyToken=null'.

No idea why. I'll push my spike to a branch if you'd like to take a look.

dahlbyk added a commit to dahlbyk/Glimpse that referenced this issue Nov 13, 2013

@dahlbyk

This comment has been minimized.

Show comment
Hide comment
@dahlbyk

dahlbyk Nov 13, 2013

Contributor

I'll push my spike to a branch if you'd like to take a look.

https://github.com/dahlbyk/Glimpse/compare/gh632

Contributor

dahlbyk commented Nov 13, 2013

I'll push my spike to a branch if you'd like to take a look.

https://github.com/dahlbyk/Glimpse/compare/gh632

@dahlbyk

This comment has been minimized.

Show comment
Hide comment
Contributor

dahlbyk commented Nov 13, 2013

@CGijbels

This comment has been minimized.

Show comment
Hide comment
@CGijbels

CGijbels Nov 13, 2013

Collaborator

@dahlbyk if I look at the change you made (based on your comment above) and without further testing, I would think that the fix you made, except for the error you get, is actually just undoing the changes you made in the first place to have it work in an async context, no?

I mean, you'll have an HttpContextWrapper instance that will contain an null value for the HttpContext.Current, because that code is actually the same as the original one that was changed to make it work in async, because the current won't be serialized, so it will be null and new HttpContextWrapper instance will be created with null as parameter

public HttpContextBase Context
{
    get { return current ?? (current = new HttpContextWrapper(HttpContext.Current)); }
}

vs

internal HttpContextBase Context
{
-    get { return context ?? new HttpContextWrapper(HttpContext.Current); }
+    get { return context ?? GetOrCaptureLogicalContext(); }
     set { context = value; }
}

except that the current is now stored while the context was being wrapped with every call
or should I look differently at that change you made above?

Collaborator

CGijbels commented Nov 13, 2013

@dahlbyk if I look at the change you made (based on your comment above) and without further testing, I would think that the fix you made, except for the error you get, is actually just undoing the changes you made in the first place to have it work in an async context, no?

I mean, you'll have an HttpContextWrapper instance that will contain an null value for the HttpContext.Current, because that code is actually the same as the original one that was changed to make it work in async, because the current won't be serialized, so it will be null and new HttpContextWrapper instance will be created with null as parameter

public HttpContextBase Context
{
    get { return current ?? (current = new HttpContextWrapper(HttpContext.Current)); }
}

vs

internal HttpContextBase Context
{
-    get { return context ?? new HttpContextWrapper(HttpContext.Current); }
+    get { return context ?? GetOrCaptureLogicalContext(); }
     set { context = value; }
}

except that the current is now stored while the context was being wrapped with every call
or should I look differently at that change you made above?

@dahlbyk

This comment has been minimized.

Show comment
Hide comment
@dahlbyk

dahlbyk Nov 14, 2013

Contributor

After construction, current will only be null if the instance was deserialized. Since serialization doesn't enter into normal circumstances, we should be fine.

But it may be moot anyway - any attempt to wiggle around the deserialization issue is failing me. I can see that it's trying to deserialize across AppDomains, but it simply doesn't see the wrapper type as available to it.

Contributor

dahlbyk commented Nov 14, 2013

After construction, current will only be null if the instance was deserialized. Since serialization doesn't enter into normal circumstances, we should be fine.

But it may be moot anyway - any attempt to wiggle around the deserialization issue is failing me. I can see that it's trying to deserialize across AppDomains, but it simply doesn't see the wrapper type as available to it.

@CGijbels

This comment has been minimized.

Show comment
Hide comment
@CGijbels

CGijbels Nov 14, 2013

Collaborator

@dahlbyk That link indeed seems to talk about the same issue we're having and the fact that we don't have it with IISExpress or IIS (especially the link is telling us that writing your own serializable wrapper won't be known on the "other side" without putting it in the GAC, which is not an option for Glimpse)

And since the serialization can't be fixed, there is no need for additional wrappers and the fix you made, that is now in place to support async ,works and will keep on working, just not with VS Dev Server, since serialization there seems to occur under normal circumstances.

So basically the answer will/might become: "we can't fixed this, try to use IISExpress or Full blown IIS"

@nikmd23 @avanderhoorn what do you guys think? Try to solve it, which at first sight does not seem to be doable, or treat it as unsupported?

Collaborator

CGijbels commented Nov 14, 2013

@dahlbyk That link indeed seems to talk about the same issue we're having and the fact that we don't have it with IISExpress or IIS (especially the link is telling us that writing your own serializable wrapper won't be known on the "other side" without putting it in the GAC, which is not an option for Glimpse)

And since the serialization can't be fixed, there is no need for additional wrappers and the fix you made, that is now in place to support async ,works and will keep on working, just not with VS Dev Server, since serialization there seems to occur under normal circumstances.

So basically the answer will/might become: "we can't fixed this, try to use IISExpress or Full blown IIS"

@nikmd23 @avanderhoorn what do you guys think? Try to solve it, which at first sight does not seem to be doable, or treat it as unsupported?

@dahlbyk

This comment has been minimized.

Show comment
Hide comment
@dahlbyk

dahlbyk Nov 14, 2013

Contributor

We could also disable the logical context support pre-Net45, to minimize the impact on older projects less likely to use IIS Express.

Contributor

dahlbyk commented Nov 14, 2013

We could also disable the logical context support pre-Net45, to minimize the impact on older projects less likely to use IIS Express.

@jspraul

This comment has been minimized.

Show comment
Hide comment
@jspraul

jspraul Nov 14, 2013

Full text of the the error shown in the browser (Visual Studio 2012) to improve discoverability and sign me up for notifications on progress on this issue:

An unhandled System.Runtime.Serialization.SerializationException exception occurred while processing the request.
--------------------------------------------------------------------------------
Type 'System.Web.HttpContextWrapper' in assembly 'System.Web.Abstractions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' is not marked as serializable. 
   at Microsoft.VisualStudio.WebHost.Host.ProcessRequest(Connection conn)
   at Microsoft.VisualStudio.WebHost.Server.OnSocketAccept(Object acceptedSocket)
--------------------------------------------------------------------------------
Version Information: ASP.NET Development Server 11.0.0.0

jspraul commented Nov 14, 2013

Full text of the the error shown in the browser (Visual Studio 2012) to improve discoverability and sign me up for notifications on progress on this issue:

An unhandled System.Runtime.Serialization.SerializationException exception occurred while processing the request.
--------------------------------------------------------------------------------
Type 'System.Web.HttpContextWrapper' in assembly 'System.Web.Abstractions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' is not marked as serializable. 
   at Microsoft.VisualStudio.WebHost.Host.ProcessRequest(Connection conn)
   at Microsoft.VisualStudio.WebHost.Server.OnSocketAccept(Object acceptedSocket)
--------------------------------------------------------------------------------
Version Information: ASP.NET Development Server 11.0.0.0
@CGijbels

This comment has been minimized.

Show comment
Hide comment
@CGijbels

CGijbels Nov 14, 2013

Collaborator

@jspraul Is it an option for you to just use IISExpress instead of VS Dev Server?

Collaborator

CGijbels commented Nov 14, 2013

@jspraul Is it an option for you to just use IISExpress instead of VS Dev Server?

@CGijbels

This comment has been minimized.

Show comment
Hide comment
@CGijbels

CGijbels Nov 14, 2013

Collaborator

@dahlbyk @nikmd23 @avanderhoorn So we've got 2 options here:

  • Continue by not supporting VS Dev Server from now on. We could make this explicit by checking for processname during Glimpse.AspNet.HttpModule initialization? Throwing an exception or writing an error to the log
  • Make the use of the CallContext depending on the availability of the NET45 conditional compilation symbol,

Any other idea?

Collaborator

CGijbels commented Nov 14, 2013

@dahlbyk @nikmd23 @avanderhoorn So we've got 2 options here:

  • Continue by not supporting VS Dev Server from now on. We could make this explicit by checking for processname during Glimpse.AspNet.HttpModule initialization? Throwing an exception or writing an error to the log
  • Make the use of the CallContext depending on the availability of the NET45 conditional compilation symbol,

Any other idea?

@jspraul

This comment has been minimized.

Show comment
Hide comment
@jspraul

jspraul Nov 14, 2013

Switching to IISExpress would affect the entire team. It's not worth the hassle when I'm just starting to demonstrate that Glimpse will be useful... for now I'm going to stick with the previous version.

Install-Package Glimpse -Version 1.7.0
Install-Package Glimpse.AspNet -Version 1.5.0
Install-Package Glimpse.WebForms -Version 1.0.1

Also had to download a 'fixed' 1.0.1 (login as guest):

http://stackoverflow.com/questions/19813397/glimpse-causes-stackoverflowexception-on-web-forms-site
http://teamcity.codebetter.com/repository/download/bt428/98257%3aid/Glimpse.WebForms.1.0.1.nupkg

jspraul commented Nov 14, 2013

Switching to IISExpress would affect the entire team. It's not worth the hassle when I'm just starting to demonstrate that Glimpse will be useful... for now I'm going to stick with the previous version.

Install-Package Glimpse -Version 1.7.0
Install-Package Glimpse.AspNet -Version 1.5.0
Install-Package Glimpse.WebForms -Version 1.0.1

Also had to download a 'fixed' 1.0.1 (login as guest):

http://stackoverflow.com/questions/19813397/glimpse-causes-stackoverflowexception-on-web-forms-site
http://teamcity.codebetter.com/repository/download/bt428/98257%3aid/Glimpse.WebForms.1.0.1.nupkg

@bmavity

This comment has been minimized.

Show comment
Hide comment
@bmavity

bmavity Nov 14, 2013

Sadly, I cannot force my team to move to IIS Express either. I will keep my eye out for a fix.

bmavity commented Nov 14, 2013

Sadly, I cannot force my team to move to IIS Express either. I will keep my eye out for a fix.

@CGijbels

This comment has been minimized.

Show comment
Hide comment
@CGijbels

CGijbels Nov 14, 2013

Collaborator

@jspraul @bmavity out of curiosity, why would this be a hard move? IISExpress can do all the same things as the VS Dev Server, can run on the same port and is configured as part of the project file, it is mostly checking another radiobutton, so all of this can be done in one commit?

I'm not judging in any way, I'm just wondering and curious what the reasons are

Collaborator

CGijbels commented Nov 14, 2013

@jspraul @bmavity out of curiosity, why would this be a hard move? IISExpress can do all the same things as the VS Dev Server, can run on the same port and is configured as part of the project file, it is mostly checking another radiobutton, so all of this can be done in one commit?

I'm not judging in any way, I'm just wondering and curious what the reasons are

@TomDeWitt

This comment has been minimized.

Show comment
Hide comment
@TomDeWitt

TomDeWitt Nov 14, 2013

Additionally I found that I get the same error when attempting to navigate to any of my reports that are utilizing the ReportViewer control in an aspx page even though it is deployed to IIS or if it is run from my development studio via IIS Express.

Additionally I found that I get the same error when attempting to navigate to any of my reports that are utilizing the ReportViewer control in an aspx page even though it is deployed to IIS or if it is run from my development studio via IIS Express.

@CGijbels

This comment has been minimized.

Show comment
Hide comment
@CGijbels

CGijbels Nov 14, 2013

Collaborator

@TomDeWitt when using IISExpress?

Collaborator

CGijbels commented Nov 14, 2013

@TomDeWitt when using IISExpress?

@TomDeWitt

This comment has been minimized.

Show comment
Hide comment
@TomDeWitt

TomDeWitt Nov 14, 2013

@CGijbels yes when using IISExpress.

@CGijbels yes when using IISExpress.

@CGijbels

This comment has been minimized.

Show comment
Hide comment
@CGijbels

CGijbels Nov 14, 2013

Collaborator

@TomDeWitt wow that is another story, do you think you can create a sample project or steps to reproduce starting from a new project, so that we can reproduce this issue?

Collaborator

CGijbels commented Nov 14, 2013

@TomDeWitt wow that is another story, do you think you can create a sample project or steps to reproduce starting from a new project, so that we can reproduce this issue?

@TomDeWitt

This comment has been minimized.

Show comment
Hide comment
@TomDeWitt

TomDeWitt Nov 14, 2013

@CGijbels I can do that. Where would you like me to put the project at?

@CGijbels I can do that. Where would you like me to put the project at?

@CGijbels

This comment has been minimized.

Show comment
Hide comment
@CGijbels

CGijbels Nov 14, 2013

Collaborator

@TomDeWitt create a repository on your Github account and commit the code in there and give us the link to that repository, then can we take it locally and check it out

thanks for your help with this!

Collaborator

CGijbels commented Nov 14, 2013

@TomDeWitt create a repository on your Github account and commit the code in there and give us the link to that repository, then can we take it locally and check it out

thanks for your help with this!

@TomDeWitt

This comment has been minimized.

Show comment
Hide comment
@TomDeWitt

TomDeWitt Nov 14, 2013

@CGijbels I used this project:

http://weblogs.asp.net/rajbk/archive/2010/05/09/creating-an-asp-net-report-using-visual-studio-2010-part-1.aspx

and then added the Glimpse Core and Glimpse ASP.NET via NuGet and once they are installed I get the error.

@CGijbels I used this project:

http://weblogs.asp.net/rajbk/archive/2010/05/09/creating-an-asp-net-report-using-visual-studio-2010-part-1.aspx

and then added the Glimpse Core and Glimpse ASP.NET via NuGet and once they are installed I get the error.

@bmavity

This comment has been minimized.

Show comment
Hide comment
@bmavity

bmavity Nov 14, 2013

It's change, and people don't like change. :) I need to save up my energy for more important battles.

The bottom line is that I can't just drop this into my app and test it out. Now I have additional steps that I have to take before I then have to battle my team to agree to the change. I know you are just trying to understand so you can make an informed decision, and the bottom line is that it's just not worth it right now for me to make the effort. Maybe our team is not your target audience and Glimpse is not for our situation. That would be ok and would not hold me back from trying it in the future. :)

bmavity commented Nov 14, 2013

It's change, and people don't like change. :) I need to save up my energy for more important battles.

The bottom line is that I can't just drop this into my app and test it out. Now I have additional steps that I have to take before I then have to battle my team to agree to the change. I know you are just trying to understand so you can make an informed decision, and the bottom line is that it's just not worth it right now for me to make the effort. Maybe our team is not your target audience and Glimpse is not for our situation. That would be ok and would not hold me back from trying it in the future. :)

@CGijbels

This comment has been minimized.

Show comment
Hide comment
@CGijbels

CGijbels Nov 14, 2013

Collaborator

@bmavity thanks for the feedback, I can imagine that it can be hard to move someone's cheese ;-)

Another quick question, what is the target framework you are running against? 3.5? 4.0? 4.5?

Collaborator

CGijbels commented Nov 14, 2013

@bmavity thanks for the feedback, I can imagine that it can be hard to move someone's cheese ;-)

Another quick question, what is the target framework you are running against? 3.5? 4.0? 4.5?

@bmavity

This comment has been minimized.

Show comment
Hide comment
@bmavity

bmavity Nov 14, 2013

We're using framework 4.0

bmavity commented Nov 14, 2013

We're using framework 4.0

@CGijbels

This comment has been minimized.

Show comment
Hide comment
@CGijbels

CGijbels Nov 14, 2013

Collaborator

@TomDeWitt alright, after jumping over some hurdles to make that sample project from the url work on my machine, I can see the serialization error on the page with the ReportViewer even when running in IISExpress and full blown IIS

But when I added another page that does not use the ReportViewer it works as expected.

So I investigated a little bit deeper and by looking at the generated HTML by the ReportViewer we can see an exception stacktrace that points us to some kind of Microsoft.ReportingServices.RdlExpressions.ExpressionHostObjectModel.ReportExprHost instance that is being loaded into another AppDomain, most likely to make sure that generating reports happens in another AppDomain instead of in the application's AppDomain to make sure it is isolated, at least that is what I conclude from the disassembled code below:

internal static ReportExprHost LoadExprHost(byte[] exprHostBytes, string exprHostAssemblyName, bool includeParameters, bool parametersOnly, OnDemandObjectModel objectModel, List<string> codeModules, AppDomain targetAppDomain)
      {
        System.Type expressionHostLoaderType = typeof (ReportRuntime.ExpressionHostLoader);
        ReportRuntime.ExpressionHostLoader remoteEHL = (ReportRuntime.ExpressionHostLoader) null;
        RevertImpersonationContext.RunFromRestrictedCasContext((ContextBody) (() => remoteEHL = (ReportRuntime.ExpressionHostLoader) Activator.CreateInstance(targetAppDomain, expressionHostLoaderType.Assembly.FullName, expressionHostLoaderType.FullName).Unwrap()));
        return remoteEHL.LoadExprHostRemoteEntryPoint(exprHostBytes, exprHostAssemblyName, includeParameters, parametersOnly, objectModel, codeModules);
      }

which in effect will trigger the same exception as the one we see when using the VS Dev Server.

Which brings us back from where we were, and will basically remove the two options we defined above, because

  • no matter what target framework version you use (I tested with NET4.5 as well) the ReportViewer will always fail due the the way it works
  • and the assumption that VS Dev Server isn't used or is rarely used in a project targetting NET4.5 doesn't apply either since it fails in IISExpress and IIS because of the ReportViewer control

I was thinking that you can configure Glimpse to bypass calls made to the Reserved.ReportViewerWebControl.axd , but unfortunately for that policy to work, it needs access to the current HttpContext, which will result in adding the System.Web.HttpContextWrapper to the CallContext, which will result in the original exception.

I'll see if we can find a way to avoid this

@dahlbyk @nikmd23 @avanderhoorn what do you guys think?

Collaborator

CGijbels commented Nov 14, 2013

@TomDeWitt alright, after jumping over some hurdles to make that sample project from the url work on my machine, I can see the serialization error on the page with the ReportViewer even when running in IISExpress and full blown IIS

But when I added another page that does not use the ReportViewer it works as expected.

So I investigated a little bit deeper and by looking at the generated HTML by the ReportViewer we can see an exception stacktrace that points us to some kind of Microsoft.ReportingServices.RdlExpressions.ExpressionHostObjectModel.ReportExprHost instance that is being loaded into another AppDomain, most likely to make sure that generating reports happens in another AppDomain instead of in the application's AppDomain to make sure it is isolated, at least that is what I conclude from the disassembled code below:

internal static ReportExprHost LoadExprHost(byte[] exprHostBytes, string exprHostAssemblyName, bool includeParameters, bool parametersOnly, OnDemandObjectModel objectModel, List<string> codeModules, AppDomain targetAppDomain)
      {
        System.Type expressionHostLoaderType = typeof (ReportRuntime.ExpressionHostLoader);
        ReportRuntime.ExpressionHostLoader remoteEHL = (ReportRuntime.ExpressionHostLoader) null;
        RevertImpersonationContext.RunFromRestrictedCasContext((ContextBody) (() => remoteEHL = (ReportRuntime.ExpressionHostLoader) Activator.CreateInstance(targetAppDomain, expressionHostLoaderType.Assembly.FullName, expressionHostLoaderType.FullName).Unwrap()));
        return remoteEHL.LoadExprHostRemoteEntryPoint(exprHostBytes, exprHostAssemblyName, includeParameters, parametersOnly, objectModel, codeModules);
      }

which in effect will trigger the same exception as the one we see when using the VS Dev Server.

Which brings us back from where we were, and will basically remove the two options we defined above, because

  • no matter what target framework version you use (I tested with NET4.5 as well) the ReportViewer will always fail due the the way it works
  • and the assumption that VS Dev Server isn't used or is rarely used in a project targetting NET4.5 doesn't apply either since it fails in IISExpress and IIS because of the ReportViewer control

I was thinking that you can configure Glimpse to bypass calls made to the Reserved.ReportViewerWebControl.axd , but unfortunately for that policy to work, it needs access to the current HttpContext, which will result in adding the System.Web.HttpContextWrapper to the CallContext, which will result in the original exception.

I'll see if we can find a way to avoid this

@dahlbyk @nikmd23 @avanderhoorn what do you guys think?

@TomDeWitt

This comment has been minimized.

Show comment
Hide comment
@TomDeWitt

TomDeWitt Nov 14, 2013

@CGijbels thank you for the update.

@CGijbels thank you for the update.

@CGijbels

This comment has been minimized.

Show comment
Hide comment
@CGijbels

CGijbels Nov 14, 2013

Collaborator

It seems that using the UriPolicy, even when it removes the System.Web.HttpContextWrapper instance from the CallContext, to ignore calls to Reserved.ReportViewerWebControl.axd is not going to cut it, since the error already occurs on the page containing the ReportViewerControl when it is being rendered (it does work if that page is added to the list of requests to ignore, but then you might miss out on other things you want to diagnose)

So maybe there is a way to intercept the PreRender method of the ReportViewer control to temporary remove the System.Web.HttpContextWrapper instance from the CallContext before the PreRender starts and add it back when the PreRender ended, and all of this in such a way that it does not mean we need to add a reference to the assembly containing the ReportViewerControl.

Anyway this is something that @avanderhoorn might answer, since he worked on the Glimpse.WebForms package.

Collaborator

CGijbels commented Nov 14, 2013

It seems that using the UriPolicy, even when it removes the System.Web.HttpContextWrapper instance from the CallContext, to ignore calls to Reserved.ReportViewerWebControl.axd is not going to cut it, since the error already occurs on the page containing the ReportViewerControl when it is being rendered (it does work if that page is added to the list of requests to ignore, but then you might miss out on other things you want to diagnose)

So maybe there is a way to intercept the PreRender method of the ReportViewer control to temporary remove the System.Web.HttpContextWrapper instance from the CallContext before the PreRender starts and add it back when the PreRender ended, and all of this in such a way that it does not mean we need to add a reference to the assembly containing the ReportViewerControl.

Anyway this is something that @avanderhoorn might answer, since he worked on the Glimpse.WebForms package.

@jspraul

This comment has been minimized.

Show comment
Hide comment
@jspraul

jspraul Nov 14, 2013

Using CallContext is going to fall apart at scale anyway (circa 2010).

http://www.wintellect.com/blogs/jeffreyr/logical-call-context-flowing-data-across-threads-appdomains-and-processes

an ASP.NET request, when under load, can become "thread agile": in other words, ASP.NET will suspend a
thread, and move it to another thread without context or TLS for that matter. ASP.NET does move items in the
HttpContext.Current.Items dictionary from one thread to the next. So, proper code to keep the LCC concept
invariant across ASP.NET and non-ASP.NET application must be cognizant of the execution context

It might be time to take a look at how the MvcMiniProfiler stores state server-side (HttpRuntime.Cache).

https://github.com/MiniProfiler/dotnet/blob/master/StackExchange.Profiling/Storage/HttpRuntimeCacheStorage.cs

jspraul commented Nov 14, 2013

Using CallContext is going to fall apart at scale anyway (circa 2010).

http://www.wintellect.com/blogs/jeffreyr/logical-call-context-flowing-data-across-threads-appdomains-and-processes

an ASP.NET request, when under load, can become "thread agile": in other words, ASP.NET will suspend a
thread, and move it to another thread without context or TLS for that matter. ASP.NET does move items in the
HttpContext.Current.Items dictionary from one thread to the next. So, proper code to keep the LCC concept
invariant across ASP.NET and non-ASP.NET application must be cognizant of the execution context

It might be time to take a look at how the MvcMiniProfiler stores state server-side (HttpRuntime.Cache).

https://github.com/MiniProfiler/dotnet/blob/master/StackExchange.Profiling/Storage/HttpRuntimeCacheStorage.cs

@TomDeWitt

This comment has been minimized.

Show comment
Hide comment
@TomDeWitt

TomDeWitt Nov 21, 2013

@CGijbels @avanderhoorn Are there any updates to this issue?

@CGijbels @avanderhoorn Are there any updates to this issue?

@CGijbels

This comment has been minimized.

Show comment
Hide comment
@CGijbels

CGijbels Nov 21, 2013

Collaborator

@TomDeWitt For now it is still no support for VS Web Dev, but I guess you're wondering about the ReportViewerControl issue?

Collaborator

CGijbels commented Nov 21, 2013

@TomDeWitt For now it is still no support for VS Web Dev, but I guess you're wondering about the ReportViewerControl issue?

@TomDeWitt

This comment has been minimized.

Show comment
Hide comment
@TomDeWitt

TomDeWitt Nov 21, 2013

@CGijbels I was wondering about the ReportViewerControl. I don't have any issues with moving to IIS Express.

@CGijbels I was wondering about the ReportViewerControl. I don't have any issues with moving to IIS Express.

@avanderhoorn

This comment has been minimized.

Show comment
Hide comment
@avanderhoorn

avanderhoorn Nov 21, 2013

Member

I think the short term fix we will add in the next drop is for you to be
able to turn off Glimpse Async support. That way if you are using VS Web
Dev or Reporting Service controls, you can just disable this feature.
Longer terms we are looking at how we can carry the required context
through the logical call context better.

On Thu, Nov 21, 2013 at 7:15 AM, TomDeWitt notifications@github.com wrote:

@CGijbels https://github.com/CGijbels I was wondering about the
ReportViewerControl. I don't have any issues with moving to IIS Express.


Reply to this email directly or view it on GitHubhttps://github.com/Glimpse/Glimpse/issues/632#issuecomment-28992309
.

Member

avanderhoorn commented Nov 21, 2013

I think the short term fix we will add in the next drop is for you to be
able to turn off Glimpse Async support. That way if you are using VS Web
Dev or Reporting Service controls, you can just disable this feature.
Longer terms we are looking at how we can carry the required context
through the logical call context better.

On Thu, Nov 21, 2013 at 7:15 AM, TomDeWitt notifications@github.com wrote:

@CGijbels https://github.com/CGijbels I was wondering about the
ReportViewerControl. I don't have any issues with moving to IIS Express.


Reply to this email directly or view it on GitHubhttps://github.com/Glimpse/Glimpse/issues/632#issuecomment-28992309
.

@jspraul

This comment has been minimized.

Show comment
Hide comment
@jspraul

jspraul Nov 21, 2013

I'm new to the project so please don't give my opinion too much weight, but the less the HttpContext is used the better. It should only be used to read the ASP.NET-specific metadata being reported and then (separately) to generate the various views. The sooner it is no longer used as a global variable the more re-usable the entire project will be.

I've skipped around through the code but couldn't figure out why the context was required for the async stuff after 10 minutes... I will see what breaks when I just pull the changeset above out of a .NET 3.5 Glimpse build.

Thanks for your work on this project!

jspraul commented Nov 21, 2013

I'm new to the project so please don't give my opinion too much weight, but the less the HttpContext is used the better. It should only be used to read the ASP.NET-specific metadata being reported and then (separately) to generate the various views. The sooner it is no longer used as a global variable the more re-usable the entire project will be.

I've skipped around through the code but couldn't figure out why the context was required for the async stuff after 10 minutes... I will see what breaks when I just pull the changeset above out of a .NET 3.5 Glimpse build.

Thanks for your work on this project!

@mheimann

This comment has been minimized.

Show comment
Hide comment
@mheimann

mheimann Dec 18, 2013

Hi all,

I've scanned across the thread regarding this issue and to be perfectly honest I do not yet grasp all the technical details, so please bear with me :-).

I have seen this error message in one of our projects after upgrading to Glimpse.Core v1.8.0 and Glimpse.AspNet v1.6.0, when using Glimpse.Core v1.7.0 and Glimpse.AspNet v1.5.0 we're not seeing this issue and Glimpse works like a charm (as expected).

The interesting thing is that we are developing on a full IIS (more specifically IIS 7.5) and I'm only seeing this issue when our Ninject kernel is being constructed. We are only using Ninject in a few parts of the application, the rest of it is unfortunately relatively legacy and free of dependency injection. Here's the relevant part of the stacktrace:

[SerializationException: Type 'System.Web.HttpContextWrapper' in assembly 'System.Web.Abstractions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' is not marked as serializable.]
   System.AppDomain.CreateInstanceAndUnwrap(String assemblyName, String typeName) +0
   Ninject.Modules.AssemblyNameRetriever.GetAssemblyNames(IEnumerable`1 filenames, Predicate`1 filter) in c:\Projects\Ninject\ninject\src\Ninject\Modules\AssemblyNameRetriever.cs:50
   Ninject.Modules.CompiledModuleLoaderPlugin.LoadModules(IEnumerable`1 filenames) in c:\Projects\Ninject\ninject\src\Ninject\Modules\CompiledModuleLoaderPlugin.cs:81
   Ninject.Modules.ModuleLoader.LoadModules(IEnumerable`1 patterns) in c:\Projects\Ninject\ninject\src\Ninject\Modules\ModuleLoader.cs:60
   Ninject.KernelBase..ctor(IComponentContainer components, INinjectSettings settings, INinjectModule[] modules) in c:\Projects\Ninject\ninject\src\Ninject\KernelBase.cs:100
   Ninject.StandardKernel..ctor(INinjectModule[] modules) in c:\Projects\Ninject\ninject\src\Ninject\StandardKernel.cs:46

The application is running inside IIS v7.5 using the .NET2 runtime and we're working with .NET Framework v3.5. So since you all seem to only have this issue using the DevWebServer of Visual Studio, I was wondering if anyone has seen the behaviour I described above?

I could try and assemble a minimalistic project that reproduces this issue, that way I could also make sure that not another part of our system is to blame.

Cheers as always and keep up the good work,
Mark

Hi all,

I've scanned across the thread regarding this issue and to be perfectly honest I do not yet grasp all the technical details, so please bear with me :-).

I have seen this error message in one of our projects after upgrading to Glimpse.Core v1.8.0 and Glimpse.AspNet v1.6.0, when using Glimpse.Core v1.7.0 and Glimpse.AspNet v1.5.0 we're not seeing this issue and Glimpse works like a charm (as expected).

The interesting thing is that we are developing on a full IIS (more specifically IIS 7.5) and I'm only seeing this issue when our Ninject kernel is being constructed. We are only using Ninject in a few parts of the application, the rest of it is unfortunately relatively legacy and free of dependency injection. Here's the relevant part of the stacktrace:

[SerializationException: Type 'System.Web.HttpContextWrapper' in assembly 'System.Web.Abstractions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' is not marked as serializable.]
   System.AppDomain.CreateInstanceAndUnwrap(String assemblyName, String typeName) +0
   Ninject.Modules.AssemblyNameRetriever.GetAssemblyNames(IEnumerable`1 filenames, Predicate`1 filter) in c:\Projects\Ninject\ninject\src\Ninject\Modules\AssemblyNameRetriever.cs:50
   Ninject.Modules.CompiledModuleLoaderPlugin.LoadModules(IEnumerable`1 filenames) in c:\Projects\Ninject\ninject\src\Ninject\Modules\CompiledModuleLoaderPlugin.cs:81
   Ninject.Modules.ModuleLoader.LoadModules(IEnumerable`1 patterns) in c:\Projects\Ninject\ninject\src\Ninject\Modules\ModuleLoader.cs:60
   Ninject.KernelBase..ctor(IComponentContainer components, INinjectSettings settings, INinjectModule[] modules) in c:\Projects\Ninject\ninject\src\Ninject\KernelBase.cs:100
   Ninject.StandardKernel..ctor(INinjectModule[] modules) in c:\Projects\Ninject\ninject\src\Ninject\StandardKernel.cs:46

The application is running inside IIS v7.5 using the .NET2 runtime and we're working with .NET Framework v3.5. So since you all seem to only have this issue using the DevWebServer of Visual Studio, I was wondering if anyone has seen the behaviour I described above?

I could try and assemble a minimalistic project that reproduces this issue, that way I could also make sure that not another part of our system is to blame.

Cheers as always and keep up the good work,
Mark

@CGijbels

This comment has been minimized.

Show comment
Hide comment
@CGijbels

CGijbels Dec 18, 2013

Collaborator

@mheimann The situation you are dealing with is exactly the same problem we are having with the VS Dev Server or with the ReportViewer control or when .NET Remoting is involved.

The problem is that when a call is made into another AppDomain, items stored in the CallContext are being serialized and deserialized into the other AppDomain, hence resulting in an exception when there are items stored in the CallContext that can't be serialized, which is the case with the System.Web.HttpContextWrapper

So this is another use case where this CallContext fix to support async is more or less blowing up in our face :-(

So to summarize for anybody reading this issue, we currently have the following issues for Glimpse v1.8:

  1. Visual Studio Dev Server is not supported
  2. ReportViewer control will only work with the workarounds mentioned above (basically temporarily removing and restoring the non serializable item from the CallContext)
  3. .NET Remoting calls cross AppDomains and/or machines will fail if you can't adapt the proxy to do more or less the same as with the ReportViewer workarounds
  4. Using Ninject

And the last 3 will fail no matter whether you use IIS Express or a Full blown IIS

We'll have to find another solution, that's for sure. We are working on v2 where a lot will be changed, so maybe that issue will be solved at the same, or put otherwise, we'll have to make sure that issue is properly solved with v2 and hopefully sooner as well.

Collaborator

CGijbels commented Dec 18, 2013

@mheimann The situation you are dealing with is exactly the same problem we are having with the VS Dev Server or with the ReportViewer control or when .NET Remoting is involved.

The problem is that when a call is made into another AppDomain, items stored in the CallContext are being serialized and deserialized into the other AppDomain, hence resulting in an exception when there are items stored in the CallContext that can't be serialized, which is the case with the System.Web.HttpContextWrapper

So this is another use case where this CallContext fix to support async is more or less blowing up in our face :-(

So to summarize for anybody reading this issue, we currently have the following issues for Glimpse v1.8:

  1. Visual Studio Dev Server is not supported
  2. ReportViewer control will only work with the workarounds mentioned above (basically temporarily removing and restoring the non serializable item from the CallContext)
  3. .NET Remoting calls cross AppDomains and/or machines will fail if you can't adapt the proxy to do more or less the same as with the ReportViewer workarounds
  4. Using Ninject

And the last 3 will fail no matter whether you use IIS Express or a Full blown IIS

We'll have to find another solution, that's for sure. We are working on v2 where a lot will be changed, so maybe that issue will be solved at the same, or put otherwise, we'll have to make sure that issue is properly solved with v2 and hopefully sooner as well.

@mheimann

This comment has been minimized.

Show comment
Hide comment
@mheimann

mheimann Dec 18, 2013

@CGijbels Thanks for the insights, Ninject is indeed creating a temporary AppDomain for automatically loading extension modules. See https://github.com/ninject/ninject/blob/master/src/Ninject/Modules/AssemblyNameRetriever.cs#L44-L61.

We're working around this now by constructing the Ninject kernel in another way (LoadExtensions set to false causes Ninject to skip the temporary AppDomain creation):

var settings = new NinjectSettings() { LoadExtensions = false };
_container = new StandardKernel(settings, new Module1(), new Module2());

This way we have to manually instantiate the modules in the Ninject extensions we use (which is only Ninject.Extensions.Factory right now). I am not 100% sure we can go down this path but we'll try for now in order to test-drive the new WebForms features of Glimpse. Just wanted to let you guys know :).

Cheers,
Mark

@CGijbels Thanks for the insights, Ninject is indeed creating a temporary AppDomain for automatically loading extension modules. See https://github.com/ninject/ninject/blob/master/src/Ninject/Modules/AssemblyNameRetriever.cs#L44-L61.

We're working around this now by constructing the Ninject kernel in another way (LoadExtensions set to false causes Ninject to skip the temporary AppDomain creation):

var settings = new NinjectSettings() { LoadExtensions = false };
_container = new StandardKernel(settings, new Module1(), new Module2());

This way we have to manually instantiate the modules in the Ninject extensions we use (which is only Ninject.Extensions.Factory right now). I am not 100% sure we can go down this path but we'll try for now in order to test-drive the new WebForms features of Glimpse. Just wanted to let you guys know :).

Cheers,
Mark

@dahlbyk

This comment has been minimized.

Show comment
Hide comment
@dahlbyk

dahlbyk Dec 18, 2013

Contributor

Adding a config toggle sounds increasingly attractive. If someone doesn't beat me to it, I'll try to take care of it after Christmas.

Contributor

dahlbyk commented Dec 18, 2013

Adding a config toggle sounds increasingly attractive. If someone doesn't beat me to it, I'll try to take care of it after Christmas.

@avanderhoorn

This comment has been minimized.

Show comment
Hide comment
@avanderhoorn

avanderhoorn Dec 18, 2013

Member

Sounds great! The other thing that could be worth trying is only putting
the inner dictionary that we are actually storing the data that we want to
carry around instead of the whole of httpcontext.current.

On Wed, Dec 18, 2013 at 10:55 AM, Keith Dahlby notifications@github.comwrote:

Adding a config toggle sounds increasingly attractive. If someone doesn't
beat me to it, I'll try to take care of it after Christmas.


Reply to this email directly or view it on GitHubhttps://github.com/Glimpse/Glimpse/issues/632#issuecomment-30852847
.

Member

avanderhoorn commented Dec 18, 2013

Sounds great! The other thing that could be worth trying is only putting
the inner dictionary that we are actually storing the data that we want to
carry around instead of the whole of httpcontext.current.

On Wed, Dec 18, 2013 at 10:55 AM, Keith Dahlby notifications@github.comwrote:

Adding a config toggle sounds increasingly attractive. If someone doesn't
beat me to it, I'll try to take care of it after Christmas.


Reply to this email directly or view it on GitHubhttps://github.com/Glimpse/Glimpse/issues/632#issuecomment-30852847
.

@CGijbels

This comment has been minimized.

Show comment
Hide comment
@CGijbels

CGijbels Dec 18, 2013

Collaborator

@avanderhoorn I guess you're only speaking about the Context.Items collection, but unfortunately we also need keep track of the Response object, the Request object, the User object and lastly the Application object and those objects aren't serializable either and to make it even worse, we have no clue about what other plugins are storing into the Context.Items collection for their processing, so even only storing the Context.Items might fail

Collaborator

CGijbels commented Dec 18, 2013

@avanderhoorn I guess you're only speaking about the Context.Items collection, but unfortunately we also need keep track of the Response object, the Request object, the User object and lastly the Application object and those objects aren't serializable either and to make it even worse, we have no clue about what other plugins are storing into the Context.Items collection for their processing, so even only storing the Context.Items might fail

@dahlbyk

This comment has been minimized.

Show comment
Hide comment
@dahlbyk

dahlbyk Dec 18, 2013

Contributor

we have no clue about what other plugins are storing into the Context.Items collection for their processing, so even only storing the Context.Items might fail

Good point

Contributor

dahlbyk commented Dec 18, 2013

we have no clue about what other plugins are storing into the Context.Items collection for their processing, so even only storing the Context.Items might fail

Good point

@MacDennis76

This comment has been minimized.

Show comment
Hide comment
@MacDennis76

MacDennis76 Dec 19, 2013

I seem to have encountered a similar issue when using the Sitecore CMS in combination with Sitecore Glimpse, the installation of Sitecore packages now fails:

ERROR Installation failed: System.Runtime.Serialization.SerializationException: Type 'System.Web.HttpContextWrapper' in assembly 'System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' is not marked as serializable.
at System.AppDomain.CreateInstanceAndUnwrap(String assemblyName, String typeName)
at Sitecore.Install.Files.FileInstaller.CommitProcessor.CreateWorker()
at Sitecore.Install.Files.FileInstaller.CommitProcessor.ProcessOperations(String taskId, IEnumerable1 operations) at Sitecore.Install.Installer.InstallPackage(String path, Boolean registerInstallation, ISource1 source, IProcessingContext context)
at Sitecore.Install.Installer.InstallPackage(String path, ISource`1 source, IProcessingContext context)
at Sitecore.Shell.Applications.Install.Dialogs.InstallPackage.InstallPackageForm.AsyncHelper.b__0()
at Sitecore.Shell.Applications.Install.Dialogs.InstallPackage.InstallPackageForm.AsyncHelper.CatchExceptions(ThreadStart start)

Glimpse.Core: 1.8.0
Glimpse.Ado: 1.7.0
Glimpse.AspNet: 1.6.0
Glimpse.EF5: 5.0.0
Glimpse.WebForms: 1.0.2
Sitecore.Glimpse.Core: 0.4.0
Sitecore.Glimpse: 0.4.0

Target Framework: .NET 4.5
IIS: 7.5 (not express)
Sitecore CMS: 6.6

After disabling Glimpse.AspNet.HttpModule in the web.config, Sitecore then works as expected.

I seem to have encountered a similar issue when using the Sitecore CMS in combination with Sitecore Glimpse, the installation of Sitecore packages now fails:

ERROR Installation failed: System.Runtime.Serialization.SerializationException: Type 'System.Web.HttpContextWrapper' in assembly 'System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' is not marked as serializable.
at System.AppDomain.CreateInstanceAndUnwrap(String assemblyName, String typeName)
at Sitecore.Install.Files.FileInstaller.CommitProcessor.CreateWorker()
at Sitecore.Install.Files.FileInstaller.CommitProcessor.ProcessOperations(String taskId, IEnumerable1 operations) at Sitecore.Install.Installer.InstallPackage(String path, Boolean registerInstallation, ISource1 source, IProcessingContext context)
at Sitecore.Install.Installer.InstallPackage(String path, ISource`1 source, IProcessingContext context)
at Sitecore.Shell.Applications.Install.Dialogs.InstallPackage.InstallPackageForm.AsyncHelper.b__0()
at Sitecore.Shell.Applications.Install.Dialogs.InstallPackage.InstallPackageForm.AsyncHelper.CatchExceptions(ThreadStart start)

Glimpse.Core: 1.8.0
Glimpse.Ado: 1.7.0
Glimpse.AspNet: 1.6.0
Glimpse.EF5: 5.0.0
Glimpse.WebForms: 1.0.2
Sitecore.Glimpse.Core: 0.4.0
Sitecore.Glimpse: 0.4.0

Target Framework: .NET 4.5
IIS: 7.5 (not express)
Sitecore CMS: 6.6

After disabling Glimpse.AspNet.HttpModule in the web.config, Sitecore then works as expected.

@CGijbels

This comment has been minimized.

Show comment
Hide comment
@CGijbels

CGijbels Dec 19, 2013

Collaborator

@MacDennis76 We'll add it to the list :-(

Collaborator

CGijbels commented Dec 19, 2013

@MacDennis76 We'll add it to the list :-(

@avanderhoorn

This comment has been minimized.

Show comment
Hide comment
@avanderhoorn

avanderhoorn Dec 19, 2013

Member

@MacDennis76 Just to confirm, you are developing with full IIS?

On Thu, Dec 19, 2013 at 10:02 AM, Christophe Gijbels <
notifications@github.com> wrote:

@MacDennis76 https://github.com/MacDennis76 We'll add it to the list :-(


Reply to this email directly or view it on GitHubhttps://github.com/Glimpse/Glimpse/issues/632#issuecomment-30934966
.

Member

avanderhoorn commented Dec 19, 2013

@MacDennis76 Just to confirm, you are developing with full IIS?

On Thu, Dec 19, 2013 at 10:02 AM, Christophe Gijbels <
notifications@github.com> wrote:

@MacDennis76 https://github.com/MacDennis76 We'll add it to the list :-(


Reply to this email directly or view it on GitHubhttps://github.com/Glimpse/Glimpse/issues/632#issuecomment-30934966
.

@MacDennis76

This comment has been minimized.

Show comment
Hide comment
@MacDennis76

MacDennis76 Dec 19, 2013

@avanderhoorn Yes, that's correct. IIS 7.5, 64bits, Windows 7.

@avanderhoorn Yes, that's correct. IIS 7.5, 64bits, Windows 7.

@CGijbels

This comment has been minimized.

Show comment
Hide comment
@CGijbels

CGijbels Dec 19, 2013

Collaborator

@avanderhoorn it doesn't matter, from the moment you see something like this System.AppDomain.CreateInstanceAndUnwrap in the stacktrace then you have an issue

Collaborator

CGijbels commented Dec 19, 2013

@avanderhoorn it doesn't matter, from the moment you see something like this System.AppDomain.CreateInstanceAndUnwrap in the stacktrace then you have an issue

@avanderhoorn

This comment has been minimized.

Show comment
Hide comment
@avanderhoorn

avanderhoorn Dec 19, 2013

Member

We are getting close to wanting to release the next version. We need to make a decision on what to do.

It looks like we have a few choices:

  1. Leave everything as is till we get a better solution
  2. Put logic in place to try and only put in the logical call context what we think we need
    • This could have all sorts of sides effects which we don't know yet in the current v1.x version
  3. Put in a config switch which allows people to turn the functionality on or off if its causing them issues

Untimely, I think option 2 will be the winner but to get the reliability we need, it will be something that we can tackle in the v2 timeframe (we have already started work on this there).

Hence, I think option 3 is the best course for the time being. Does anyone have any thoughts or objections on this thought process?

Member

avanderhoorn commented Dec 19, 2013

We are getting close to wanting to release the next version. We need to make a decision on what to do.

It looks like we have a few choices:

  1. Leave everything as is till we get a better solution
  2. Put logic in place to try and only put in the logical call context what we think we need
    • This could have all sorts of sides effects which we don't know yet in the current v1.x version
  3. Put in a config switch which allows people to turn the functionality on or off if its causing them issues

Untimely, I think option 2 will be the winner but to get the reliability we need, it will be something that we can tackle in the v2 timeframe (we have already started work on this there).

Hence, I think option 3 is the best course for the time being. Does anyone have any thoughts or objections on this thought process?

@CGijbels

This comment has been minimized.

Show comment
Hide comment
@CGijbels

CGijbels Dec 19, 2013

Collaborator

@avanderhoorn option 2 doesn't seem a valid option because once a thread switch is done (out of control of ASP.NET runtime that is) you're on your own...

option 3 might work, but can you check what other changes were made in that same PR, because switching the callcontext usage on or off, might be a no go with regards to other changes made (sql stuff...), either way conditionally including or excluding that async PR seems to be the only option for the time being

v2 should have a solution for this, since it makes extensive use of async

Collaborator

CGijbels commented Dec 19, 2013

@avanderhoorn option 2 doesn't seem a valid option because once a thread switch is done (out of control of ASP.NET runtime that is) you're on your own...

option 3 might work, but can you check what other changes were made in that same PR, because switching the callcontext usage on or off, might be a no go with regards to other changes made (sql stuff...), either way conditionally including or excluding that async PR seems to be the only option for the time being

v2 should have a solution for this, since it makes extensive use of async

@avanderhoorn

This comment has been minimized.

Show comment
Hide comment
@avanderhoorn

avanderhoorn Dec 19, 2013

Member

Agreed. Obviously we will need to test things to make sure that things like
the SQL async stuff still works, but it seems like the only choice to me.

On Thu, Dec 19, 2013 at 11:06 AM, Christophe Gijbels <
notifications@github.com> wrote:

@avanderhoorn https://github.com/avanderhoorn option 2 doesn't seem a
valid option because once a thread switch is done (out of control of
ASP.NET runtime that is) you're on your own...

option 3 might work, but can you check what other changes were made in
that same PR, because switching the callcontext usage on or off, might be a
no go with regards to other changes made (sql stuff...), either way
conditionally including or excluding that async PR seems to be the only
option for the time being

v2 should have a solution for this, since it makes extensive use of async


Reply to this email directly or view it on GitHubhttps://github.com/Glimpse/Glimpse/issues/632#issuecomment-30940894
.

Member

avanderhoorn commented Dec 19, 2013

Agreed. Obviously we will need to test things to make sure that things like
the SQL async stuff still works, but it seems like the only choice to me.

On Thu, Dec 19, 2013 at 11:06 AM, Christophe Gijbels <
notifications@github.com> wrote:

@avanderhoorn https://github.com/avanderhoorn option 2 doesn't seem a
valid option because once a thread switch is done (out of control of
ASP.NET runtime that is) you're on your own...

option 3 might work, but can you check what other changes were made in
that same PR, because switching the callcontext usage on or off, might be a
no go with regards to other changes made (sql stuff...), either way
conditionally including or excluding that async PR seems to be the only
option for the time being

v2 should have a solution for this, since it makes extensive use of async


Reply to this email directly or view it on GitHubhttps://github.com/Glimpse/Glimpse/issues/632#issuecomment-30940894
.

@CGijbels

This comment has been minimized.

Show comment
Hide comment
@CGijbels

CGijbels Dec 19, 2013

Collaborator

I agree, conditionally excluding the changes of the async PR which are by default included

A simple "Glimpse:DisableAsyncSupport" app setting will do

Collaborator

CGijbels commented Dec 19, 2013

I agree, conditionally excluding the changes of the async PR which are by default included

A simple "Glimpse:DisableAsyncSupport" app setting will do

@avanderhoorn

This comment has been minimized.

Show comment
Hide comment
@avanderhoorn

avanderhoorn Dec 19, 2013

Member

Sounds good to me. We are looking at getting this release out tomorrow, do
you have time today/tonight to do this? If no no worries, I'll get into it.
Let me know.

On Thursday, December 19, 2013, Christophe Gijbels wrote:

I agree, conditionally excluding the changes of the async PR which are by
default included

A simple "Glimpse:DisableAsyncSupport" app setting will do


Reply to this email directly or view it on GitHubhttps://github.com/Glimpse/Glimpse/issues/632#issuecomment-30943080
.

Member

avanderhoorn commented Dec 19, 2013

Sounds good to me. We are looking at getting this release out tomorrow, do
you have time today/tonight to do this? If no no worries, I'll get into it.
Let me know.

On Thursday, December 19, 2013, Christophe Gijbels wrote:

I agree, conditionally excluding the changes of the async PR which are by
default included

A simple "Glimpse:DisableAsyncSupport" app setting will do


Reply to this email directly or view it on GitHubhttps://github.com/Glimpse/Glimpse/issues/632#issuecomment-30943080
.

@CGijbels

This comment has been minimized.

Show comment
Hide comment
@CGijbels

CGijbels Dec 19, 2013

Collaborator

@avanderhoorn I'm not home tonight (the day part is already over here ;-)) and tomorrow neither so I can't do this

Collaborator

CGijbels commented Dec 19, 2013

@avanderhoorn I'm not home tonight (the day part is already over here ;-)) and tomorrow neither so I can't do this

@avanderhoorn

This comment has been minimized.

Show comment
Hide comment
@avanderhoorn

avanderhoorn Dec 19, 2013

Member

Not a problem. I'll talk this one on.

On Thursday, December 19, 2013, Christophe Gijbels wrote:

@avanderhoorn https://github.com/avanderhoorn I'm not home tonight (the
day part is already over here ;-)) and tomorrow neither so I can't do this


Reply to this email directly or view it on GitHubhttps://github.com/Glimpse/Glimpse/issues/632#issuecomment-30947208
.

Member

avanderhoorn commented Dec 19, 2013

Not a problem. I'll talk this one on.

On Thursday, December 19, 2013, Christophe Gijbels wrote:

@avanderhoorn https://github.com/avanderhoorn I'm not home tonight (the
day part is already over here ;-)) and tomorrow neither so I can't do this


Reply to this email directly or view it on GitHubhttps://github.com/Glimpse/Glimpse/issues/632#issuecomment-30947208
.

@avanderhoorn

This comment has been minimized.

Show comment
Hide comment
@avanderhoorn

avanderhoorn Dec 19, 2013

Member

I've added the necessary switch to check for the presence of an appsetting with the key Glimpse:DisableAsyncSupport. If this is present and set to true, it wont use the logical context. I've run some tests and things look pretty good even in async scenarios when this is disabled.

If someone can verify this workaround who has this this issues that would really help.

Lastly, I've closed this issue for the time being as we know that this general problem is something we need to solve for v2 and this is all we are going to do in the v1.x timeframe unless there are more major problems.

Member

avanderhoorn commented Dec 19, 2013

I've added the necessary switch to check for the presence of an appsetting with the key Glimpse:DisableAsyncSupport. If this is present and set to true, it wont use the logical context. I've run some tests and things look pretty good even in async scenarios when this is disabled.

If someone can verify this workaround who has this this issues that would really help.

Lastly, I've closed this issue for the time being as we know that this general problem is something we need to solve for v2 and this is all we are going to do in the v1.x timeframe unless there are more major problems.

@dahlbyk

This comment has been minimized.

Show comment
Hide comment
@dahlbyk

dahlbyk Dec 20, 2013

Contributor

Another thing I had considered, which I may yet submit for your consideration, is wrapping the wrapper in something that implements ISerializable with the sole purpose of throwing a more useful error message (known limitation, sorry - please set Glimpse:DisableAsyncSupport = true) should this type of serialization be attempted.

Contributor

dahlbyk commented Dec 20, 2013

Another thing I had considered, which I may yet submit for your consideration, is wrapping the wrapper in something that implements ISerializable with the sole purpose of throwing a more useful error message (known limitation, sorry - please set Glimpse:DisableAsyncSupport = true) should this type of serialization be attempted.

@avanderhoorn

This comment has been minimized.

Show comment
Hide comment
@avanderhoorn

avanderhoorn Dec 20, 2013

Member

Makes a lot of sense. If you can get to it sooner rather than later that
would be really cool.

On Fri, Dec 20, 2013 at 12:49 AM, Keith Dahlby notifications@github.comwrote:

Another thing I had considered, which I may yet submit for your
consideration, is wrapping the wrapper in something that implements
ISerializable with the sole purpose of throwing a more useful error
message (known limitation, sorry - please set Glimpse:DisableAsyncSupport =
true) should this type of serialization be attempted.


Reply to this email directly or view it on GitHubhttps://github.com/Glimpse/Glimpse/issues/632#issuecomment-30990308
.

Member

avanderhoorn commented Dec 20, 2013

Makes a lot of sense. If you can get to it sooner rather than later that
would be really cool.

On Fri, Dec 20, 2013 at 12:49 AM, Keith Dahlby notifications@github.comwrote:

Another thing I had considered, which I may yet submit for your
consideration, is wrapping the wrapper in something that implements
ISerializable with the sole purpose of throwing a more useful error
message (known limitation, sorry - please set Glimpse:DisableAsyncSupport =
true) should this type of serialization be attempted.


Reply to this email directly or view it on GitHubhttps://github.com/Glimpse/Glimpse/issues/632#issuecomment-30990308
.

@mudnug

This comment has been minimized.

Show comment
Hide comment
@mudnug

mudnug Dec 23, 2013

I have verified that the latest available nuget release fixes the issue for us when we add

  <appSettings>
    <add key="Glimpse:DisableAsyncSupport" value="true" />
  </appSettings>

Otherwise our web api hosted on IIS Express returns

{"message":"An error has occurred.","exceptionMessage":"Type 'System.Web.HttpContextWrapper' in assembly 'System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' is not marked as serializable.","exceptionType":"System.Runtime.Serialization.SerializationException","stackTrace":"..."}

mudnug commented Dec 23, 2013

I have verified that the latest available nuget release fixes the issue for us when we add

  <appSettings>
    <add key="Glimpse:DisableAsyncSupport" value="true" />
  </appSettings>

Otherwise our web api hosted on IIS Express returns

{"message":"An error has occurred.","exceptionMessage":"Type 'System.Web.HttpContextWrapper' in assembly 'System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' is not marked as serializable.","exceptionType":"System.Runtime.Serialization.SerializationException","stackTrace":"..."}
@avanderhoorn

This comment has been minimized.

Show comment
Hide comment
@avanderhoorn

avanderhoorn Dec 26, 2013

Member

Thanks for letting us know!

Member

avanderhoorn commented Dec 26, 2013

Thanks for letting us know!

@davidfowl

This comment has been minimized.

Show comment
Hide comment
@davidfowl

davidfowl Apr 27, 2014

Hey guys, I stumbled across this thread when trying to solve the same problem and @loudej found a solution. If you wrap the object in an ObjectHandle it just works. It'll never ask to serialize the underlying type. You can deprecate that flag now 😄

Hey guys, I stumbled across this thread when trying to solve the same problem and @loudej found a solution. If you wrap the object in an ObjectHandle it just works. It'll never ask to serialize the underlying type. You can deprecate that flag now 😄

@avanderhoorn

This comment has been minimized.

Show comment
Hide comment
@avanderhoorn

avanderhoorn Apr 27, 2014

Member

@davidfowl thanks a lot for the input!!!

For v2 we ended up solving this problem by trying to store the least amount of data in the Logical CallContext. We thought that this might be safest solution given that we are operating with other peoples objects and have no idea what they are putting in it.

This lead to the development of CallContextCurrentGlimpseRequestIdTracker which tries to avoid the issue by basically only store a guid in there. In an asp.net context this gets us past the async issues but not past the hoping across threads that occurs throughout the request lifetime.

To get past this, for ASP.NET, we leverages HttpContext.Items to travel across the threads. We do this in AspNetCurrentGlimpseRequestIdTracker.

Finally the part that actually stores the data is ActiveGlimpseRequestContexts.

Full credit for all this work and going through the various edge cases is @CGijbels. A fair amount of work went into getting this right.

Member

avanderhoorn commented Apr 27, 2014

@davidfowl thanks a lot for the input!!!

For v2 we ended up solving this problem by trying to store the least amount of data in the Logical CallContext. We thought that this might be safest solution given that we are operating with other peoples objects and have no idea what they are putting in it.

This lead to the development of CallContextCurrentGlimpseRequestIdTracker which tries to avoid the issue by basically only store a guid in there. In an asp.net context this gets us past the async issues but not past the hoping across threads that occurs throughout the request lifetime.

To get past this, for ASP.NET, we leverages HttpContext.Items to travel across the threads. We do this in AspNetCurrentGlimpseRequestIdTracker.

Finally the part that actually stores the data is ActiveGlimpseRequestContexts.

Full credit for all this work and going through the various edge cases is @CGijbels. A fair amount of work went into getting this right.

@JoeBrockhaus

This comment has been minimized.

Show comment
Hide comment
@JoeBrockhaus

JoeBrockhaus Dec 4, 2014

I'm running into this issue with a plugin framework that is a small part of our site. Is the final solution to this the configuration element for turning async support off?

I'm running into this issue with a plugin framework that is a small part of our site. Is the final solution to this the configuration element for turning async support off?

@kemmis

This comment has been minimized.

Show comment
Hide comment
@kemmis

kemmis Dec 29, 2014

I have the same question as @JoeBrockhaus. Is there no solution for this other than to disable async support?

kemmis commented Dec 29, 2014

I have the same question as @JoeBrockhaus. Is there no solution for this other than to disable async support?

@dahlbyk

This comment has been minimized.

Show comment
Hide comment
@dahlbyk

dahlbyk Dec 31, 2014

Contributor

Pre-v2, disabling async is the only option. You can follow v2 progress in #738.

Contributor

dahlbyk commented Dec 31, 2014

Pre-v2, disabling async is the only option. You can follow v2 progress in #738.

@matthid matthid referenced this issue in Antaris/RazorEngine Apr 10, 2015

Closed

RazorEngine conflicts with Glimpse? #268

kevinobee added a commit to kevinobee/Sitecore.Glimpse that referenced this issue Aug 18, 2015

@kevinobee kevinobee referenced this issue in kevinobee/Sitecore.Glimpse Aug 19, 2015

Open

Error activating ILogManager in Sitecore 8 sites #27

@jtkech

This comment has been minimized.

Show comment
Hide comment
@jtkech

jtkech Dec 8, 2015

@davidfowl just having the same issue while contributing on another project (Orchard cms). This when using the CallContext Logical Data to carry workcontext data among thread switching (e.g when async code), and when using this through a command shell that uses cross domain call...

You gave me the solution, as you said it just works with ObjectHandle, many thanks.

Best

jtkech commented Dec 8, 2015

@davidfowl just having the same issue while contributing on another project (Orchard cms). This when using the CallContext Logical Data to carry workcontext data among thread switching (e.g when async code), and when using this through a command shell that uses cross domain call...

You gave me the solution, as you said it just works with ObjectHandle, many thanks.

Best

@tomasr tomasr referenced this issue in Microsoft/ApplicationInsights-SDK-Labs Feb 13, 2017

Merged

Fix for WcfOperationContext serialization error #93

@lmolkova lmolkova referenced this issue in Microsoft/ApplicationInsights-dotnet-server Jun 7, 2017

Closed

DiagnosticSource.dll not found exception in RoleEnvironment.Changed #613

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment