We all know the special "shadow copy" feature of ASP.NET (where it makes a copy of a new DLL to actually use for processing, so you can update the copy in the bin dir on the fly). It seems that this feature does not work for a private assembly that is set up
as a library app in COM+. When I look at the module usage on the server, it appears that aspnet_wp is using both the shadow copy and the copy in the bin, and, as one would expect if this were true, I cannot overwrite the copy in the bin dir while ASP.NET is
running (I have to shut down IIS or kill aspnet_wp to release the lock). I noticed that when I set the COM+ app to run as a server app, the copy in the bin dir gets used/locked by dllhost, which I suppose makes sense, and you have to shut down the component
or kill that dllhost proc to update it. So it seems that the shadow copy feature for serviced components is useless. Am I missing something here? I am further confused by the statement in
Shannon Pahl's article on MSDN that says "Assemblies that use serviced components in COM+ server apps should be placed in the GAC. Assemblies that use serviced components in COM+ libraries apps may not need to be placed in the GAC (unless they are located
in different directories). The only exception is when hosting with ASP.NET-assemblies should not be placed in the GAC to enable shadow copy to operate correctly." This implies, if I read it right, that shadow copy should still work for ASP.NET apps using serviced
components. Can someone clear this issue up for me? Thanks.
Well, I do think the article is somewhat misleading in its mention of indexing service. However, the article does seem to make it pretty clear, imho, that strongly named assemblies in the bin folder are not supported for asp.net applications. I quote: "Because
strong-named assemblies are loaded as domain neutral for ASP.NET applications, do not put strong-named assemblies in the Bin folder of your ASP.NET application. Strong-named assemblies are only supported in the global assembly cache for ASP.NET." So, taking
that into account, and given that you're certainly strong naming your assembly (because of your use of EnterpriseServices), that would give some reason as to why it might not work as expected (but I have no more information on it, either, sorry)
Yup. That would seem to be indicated. It's funny that I've not seen this statement anywhere else--that strong-named private assemblies are not supported. In fact, I've read at least two books that discuss it as a viable, perhaps even preferable, option. And
that article I linked to recommeded it, and that was on MSDN. In any case, that does appear to explain what's happening, for better or worse. Thanks for pointing that out.
Ambrose
Contributor
3173 Points
638 Posts
ASPInsiders
Shadow Copy Doesn't Work for Serviced Components?
Jul 09, 2003 08:16 PM|LINK
Silverlight MVP
tomasr
Contributor
4290 Points
852 Posts
Re: Shadow Copy Doesn't Work for Serviced Components?
Sep 09, 2003 12:20 AM|LINK
tomasr@mvps.org
Ambrose
Contributor
3173 Points
638 Posts
ASPInsiders
Re: Shadow Copy Doesn't Work for Serviced Components?
Sep 09, 2003 01:39 AM|LINK
Silverlight MVP
tomasr
Contributor
4290 Points
852 Posts
Re: Shadow Copy Doesn't Work for Serviced Components?
Sep 09, 2003 02:10 AM|LINK
tomasr@mvps.org
Ambrose
Contributor
3173 Points
638 Posts
ASPInsiders
Re: Shadow Copy Doesn't Work for Serviced Components?
Sep 09, 2003 02:47 AM|LINK
Silverlight MVP