How would one go about trying to attach a debugger on a C# object exposed as
COM? If the thing is in-proc and I set my IIS isolation to low and I
pre-load the C# dll, would I be able to attach to inetinfo.exe and set
breakpoints?

Given this is coming out of the instantiation I may not even get to my C#
class code, but it would be worth a shot.

Thanks
Mark


""Walter Wang [MSFT]"" wrote:

Hi Mark,


Here's how I setup remote debugging to debug the C# assembly that is called
by ASP code:

Configuration:

Server "V1": Windows 2003, IIS 6.0, installed .NET 2.0
Client "H3": Windows XP, Visual Studio 2008

1. Create ClassLibrary1 on H3, enable "Make assembly COM-Visible" and
"Register for COM interop"; with Class1 as following:

namespace ClassLibrary1 {
public class Class1 {
public string Hello() { return "Hello"; }
}
}

2. Install Visual Studio Remote Debugger (you can find the installation
files from your Visual Studio 2005/2008 setup disk) on V1, configure it to
use a service account that is part of Administrators group.

3. Copy over the generated .dll, .pdb, .tlb files from H3 to V1, run
%windir%\Microsoft.NET\Framework\v2.0.50727\regasm .exe /codebase
<path_to_ClassLibrary1.dll> to register it on V1

4. Create test.asp on V1:

<% set x = CreateObject("ClassLibrary1.Class1") %>
<%= x.Hello() %>

5. Create a dummy ASP.NET 2.0 website in the same application pool as the
ASP website and create a dummy ASP.NET WebForm in it (This step is required
to make sure the IIS worker process is recogonized as a managed process to
successfully attach it in later steps)

6. Run command "iisreset" to make sure the IIS worker process is closed
first; then visit the ASP.NET 2.0 WebForm first to make sure .NET 2.0
runtime is loaded into the worker process.

7. Test test.asp in browser to make sure it works.

8. On H3, in Visual Studio, select "Debug/Attach to Process...", input "V1"
in the "Qualifier" field and click button "Refresh"; select w3wp.exe from
the list (make sure its type is shown as "Managed,x86"; then click button
"Attach".

9. Now if you add a breakpoint on the managed code and refresh the ASP page
in browser, it should hit successfully.

Without steps 5 & 6, the w3wp.exe is not shown as managed type and we
cannot make the breakpoints in managed code to be hit.


Regards,
Walter Wang (wawang (AT) online (DOT) microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

Hi Walter...

I tried using your debugging steps here, with some modification. I don't
have access to a 2003 box or IIS 6 from development. Our developers have
XP/IIS 5.1, so I set the isolation level on my dev website to low and
attached to inetinfo.exe.

I didn't get to any of the breakpoints, though, which makes me think there's
something about the assembly load that's not working properly under the ASP
environment.

I did find a few things with unrelated work, though.

In the deep, dark past someone made our release build process using Wix.
The Wix project GACs all of our dlls. When they are all in the GAC, the C#
COM objects work in ASP, too. This reinforces the concern that it's an
assembly load issue with exposing the C# as COM.

For our debug build, however, the C# COM objects are regasm'd where the sit.
In this case, the work with script from the command line but they don't
instantiate from ASP.

I found this:
http://msdn.microsoft.com/msdnmag/issues/06/03/TestRun/
a little project to map out some of the dependencies for assemblies.

Experimenting with this tool, I found that Assembly.LoadFrom(fileName)
works, but when I go through the referenced assemblies and try to load them
from the AssemblyName, it doesn't work unless the utility has all the
dependent dlls in the local dir. To be expected I guess.

Not sure where to go further with this. Obviously there's something
different happening with how IIS/ASP is instantiating the COM objects vs
script at the command line. It sounds like it's some kind of permissions
thing, but I've put IUSR_<machine> in the admin group and that didn't fix the
problem.

If you think there's some other debug step I should take for IIS 5.1 (other
than isolation low, attach to inetinfo.exe), I'd be happy to try it.

Thanks
Mark

Hi Mark,

Thanks for the update.

Please use the Assembly Binding Log Viewer to see if there's any assembly
loading issues:

#Junfeng Zhang's Windows Programming Notes : Fusion binding log and
fuslogvw.exe
http://blogs.msdn.com/junfeng/archiv.../14/72912.aspx


You might also find following blog useful about Assembly.LoadFrom and COM
interop:

#Junfeng Zhang's Windows Programming Notes : Assembly.LoadFrom
http://blogs.msdn.com/junfeng/archiv...31/423340.aspx


Regards,
Walter Wang (wawang (AT) online (DOT) microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

Hi Walter...

Thanks for the blog pointers. I've been experimenting with Fusion, as the
first link suggests. I was just looking at the 2nd blog about interpreting
Fusion results and I find that others have seen the same symptoms though
there wasn't really an answer as to why.

I turned Fusion to logging all binding events, and as people noted in the
Assembly.LoadFrom discussion, I see 2 events/logs for each COM-enabled .Net
assembly - 1 with the assembly full name, which invariably fails with the
lookup paths it tried, and a 2nd called

WhereRefBind!Host=(LocalMachine)!FileName=(assembl y.dll)

which invariably has the path from the CodeBase registry entry and says it
succeeded.

The interesting thing is that this pattern *is the same* whether the C# COM
invocation comes from the command-line executed script or from ASP. What
makes that especially interesting is that the command-line executed script
invocation *works* where the ASP blows up with an instantiation error.

I can send you the logs Fusion produced if you're interested, but there is
definitely something different in the way ASP is binding these references
compared to other ways of invocation.

Thanks
Mark


""Walter Wang [MSFT]"" wrote:

Hi Walter...

Another interesting side note... We have a C# COM object that is
instantiated from C++ code in an ISAPI filter (also in inetinfo.exe). That
invocation produces the same 2 log entries (first one saying lookup failed
and the 2nd WhereRefBind saying it succeeded).

The interesting bit is that the C++ invocation in the ISAPI filter also
succeeds in creating the object (like the commandline script) where the ASP
blows up.

More breadcrumbs leading to what seems to be a bug in how ASP
Server.CreateObject() is working when it instantiates C# com objects.

Thanks
Mark


""Walter Wang [MSFT]"" wrote:

Hi Mark,

I'm sorry that I didn't notice that you actually already mentioned you were
using Server.CreateObject instead of using CreateObject directly. One
difference between Server.CreateObject and CreateObject is that
Server.CreateObject goes through MTS (COM+). I'm not sure if you need
transaction support and requires using Server.CreateObject explicitly. If
not, maybe you could have a try to use CreateObject directly.

#Should I use CreateObject or Server.CreateObject?
http://classicasp.aspfaq.com/compone...ect-or-server-
createobject.html


Please feel free to send me the fusion log file if needed.


Regards,
Walter Wang (wawang (AT) online (DOT) microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

Hi Walter...

Thanks for the interesting article on the difference between CreateObject
and Server.CreateObject. Unfortunately, it didn't make any difference in my
situation. In ASP, either CreateObject or Server.CreateObject fails to
instantiate the C# COM while everyone else succeeds.

The Fusion log still shows the same behavior in all cases - 2 logs get
created, one for the assembly fullname, which always shows failure, and the
WebRefBind for the same dll just after saying it succeeded. We get both
these log entries whether the COM instantiation works (from C++ or with
CScript) or doesn't (ASP). It still seems like ASP is doing something
differently than all the others on the CreateObject call.

Thanks
Mark


""Walter Wang [MSFT]"" wrote:

Hi Mark,

Would you please send me the Fusion log files?

Thanks.


Regards,
Walter Wang (wawang (AT) online (DOT) microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.