While working on my Automaton framework for build automaton with Team Foundation Server I've come upon this rather cryptic exception. It seems to happen only once in a while, something I'm able to do successfull requests without this exception.

What I have is an .ashx which returns some HTML content to my .aspx, and the .ashx is called using Xml Http javascript call (AJAX).

The error occurs when I try to read the .WorkItems property on an instance of the Changeset class.

Full exception stack:

[ArgumentException: Cannot pass a GCHandle across AppDomains.
Parameter name: handle]
System.Runtime.InteropServices.GCHandle.InternalCheckDomain(IntPtr handle) +0
System.Runtime.InteropServices.GCHandle.FromIntPtr(IntPtr value) +92
CProdStudioObjectRoot.{dtor}(CProdStudioObjectRoot* ) +87
CField.{dtor}(CField* ) +254
ATL.CComObject<CField>.Release(CComObject<CField>* ) +208
CProdStudioObjectRoot.ReleaseRegistered() +497
Microsoft.TeamFoundation.WorkItemTracking.Client.DataStore.DatastoreClass.set_CallingProcessIdentity(Int32 hCallingProcessIdentity) +335
Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItemStore.InitializeInternal() +706
Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItemStore.Microsoft.TeamFoundation.Client.ITeamFoundationServerObject.Initialize(TeamFoundationServer teamFoundationServer) +90
Microsoft.TeamFoundation.Client.TeamFoundationServer.CreateITFSObjectInstance(Type serviceType) +137
Microsoft.TeamFoundation.Client.TeamFoundationServer.GetService(Type serviceType) +241
Microsoft.TeamFoundation.VersionControl.Client.Changeset.get_WorkItemStore() +31
Microsoft.TeamFoundation.VersionControl.Client.Changeset.get_WorkItems() +24
changeset.ProcessRequest(HttpContext context) in c:\Documents and Settings\sonbje\My Documents\Visual Studio 2005\Workspaces\Automaton\Automaton\changeset.ashx:77
System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +154
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +64

This is a known bug in the work item tracking object model that is fixed in SP1. You either can or will be able to request a hotfix from customer support.

Buck

Buck Hodges wrote:

This is a known bug in the work item tracking object model that is fixed in SP1. You either can or will be able to request a hotfix from customer support. Buck

Is there an ETA for the SP1? I guess I could get the hotfix for my own company, but I doubt I can redistribute this hotfix together with my build automation software? Not many that uses it yet so I guess we can all wait for SP1, as it's just a matter of refreshing the page a few times and it works again.

Thanks for the response!

I can't say when SP1 will ship. :(

I'm not sure what the policy is with regard to redistributing a hotfix. I'd suggest asking Customer Support.

Buck

Is there a KB article associated w/ this problem. We contacted Microsoft and they are not able to give out a hotfix w/o an associated KB article.

Thanks for any info.

Kel

Is there a contact or email address for who to get a hold of about acquiring the fix?

Thank you,

Aaron

Kel Koenig wrote:

Is there a KB article associated w/ this problem. We contacted Microsoft and they are not able to give out a hotfix w/o an associated KB article. Thanks for any info. Kel

Same problem here. I couldn't find a KB article associated to this. Right now this issue prevents me from running any of my unit tests as part of the build process. If I run each of them individually through the VS2005 environment, it works fine. If I try to batch them all together (even inside of VS2005) I get this error.

Has anyone had any luck in getting this hotfix?

Thanks,
Shane

Unfortunately, the hotfix hasn't made it out yet. It got hung up on a dependency. Hopefully, it will go out in the next couple of weeks.

Buck

Okay, I'm tired of being wrong. No more guesses on when it gets out. :-(

However, here's a bit of good news. Naren (http://blogs.msdn.com/narend) posted a reference to the following blog post, http://www.goeleven.com/blog/entryDetail.aspx?entry=35. In it, the author describes how to get around the GCHandle bug. I haven't tried this, but it sounds promising.

Whenever you create an instance of the WorkItemStore class, a cache is create on the local disk. By default this local folder is located in the current users profile. This works fine whenever you use the API in a winforms application, but not for an ASP.NET application. ASP.NET applications run under the NETWORK SERVICE by default and that profile is inaccessible.

To change this default behaviour, you can set WorkItemTrackingCacheRoot property of the TeamFoundationServer instance in code or in your configuration file's appSettings section.

But, setting the cache on local disk incurs some risk to. Whenever you set the cache to a folder inside the website's virtual directory you will encounter the following error each second call to the workitem store: 'Cannot pass GCHandle across AppDomain'. This issue is caused by an unmanaged component called CProdStudio, which is cannot be reached for cleanup as it is defined in an other application domain. At first, I was quite astonished by this behaviour. I allways thought ASP.NET applications ran in a single AppDomain unless something changed to the configuration file or one of the assemblies. This seems to be only partially correct, in fact ASP.NET monitors all file changes in the application and as soon as this count hits a mere 15, it will automatically recycle and create a new AppDomain. As the workitem cache is a file store which will be target of multiple write operations, it will allmost allways cause a recycle of the AppDomain.

Getting rid of this annoying behaviour can be achieved by setting the numRecompilesBeforeAppRestart attribute of the compilation tag in your application's configuration file to a very large number or better, move the cache to a folder outside the website's virtual directory.

<

SP1 beta is out now, and it includes the fix to the GCHandle issue, according to Brian Harry's blog post.

Buck

Tried to fix the issue by setting numRecompilesBeforeAppRestart to a value of 500, but the exception still occurrs the very first time I try to expand a node in my web application which gathers work item information. The second time, it works fine.

Good to see that SP1 is out in beta and the issue have been fixed, but I think TFS SP1 beta is the first Microsoft beta I don't dare to install. Will there be a smooth upgrade path from beta to RTM?