Problems attaching to explorer.exe process

[PhilJohnson]

I am using VS2003 to create a C# dll that uses shell namespace extensions.

I need to debug my code but it is running in the explorer.exe process and when I open my namespace extension from My Computer so its running, then try to attach to the explorer.exe process with VS2003 I get the message....

"Unable to attach to the process."

Any suggestions are really welcome because I really need to see what is happening inside my code.

Thanks,

Phillip

 

[JurkMonkey]

Wha?!

Why are you attaching to explorer.exe?

What are you trying to do? You can directly invoke Shell commands either using PInvoke or via the command line (cmd.exe)

http://www.ubuntu.com/

 

[PhilJohnson]

Im trying to create something that appears as an icon in My Computer that you can browse like a folder/file system but which maps to business objects running on the server.

Is it possible to create something like this using PInvoke?

If it is, do you have any decent links or tutorials?

I'm currently trying to use this sample framework....

http://www.codeplex.com/namespaceextension

 

[chiph]

Do you have admin rights on the machine? Are you a member of the debuggers group?

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[PhilJohnson]

Thanks for the help guys, I got this though.....

The explorer process will load the com interop layer in the latest version of .net installed on the machine (in my case 2.0) even though my dll is then running in version 1.1... so you can't attach the debugger process from VS 2003 onto the 2.0 CLR.

SO, here is how I got around it...

Create a file called explorer.exe.config with settings to use .net 1.1, Explorer will then run the com interop layer in version 1.1 which is the same version as my dll and I can debug.

Hope this helps others who experience this problem!

Phil

 

[chiph]

I just remembered that Raymond Chen wrote a blog entry saying not to write shell extensions in managed code for this very reason.

http://blogs.msdn.com/oldnewthing/archive/2006/12/18/1317290.aspx

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[phinoppix]

Thanks for posting the link chiph. Though the blog post is a bit old, still very timely. Now I understand the limitations of managed shell extension.

I read from one of JK's comments that IE should not have problems loading managed browser extensions with multiple frameworks installed since it gets to decide which framework version to load (that is, implicitly the latest, or explicitly via config map). However, since an IE browser extension can also run when running explorer, does IE run as in-process, thus gets loaded in explorer's process? If it does, then the limitations would extend to browser extensions as well.


tia

 

[chiph]

I don't know for sure, but I believe you are correct -- when viewing web content from Windows Explorer, it gets loaded in as a library and not an executable, so this same thing could happen in that case.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[PhilJohnson]

Hi guys, I appreciate there are issues using C# with shell extensions, but the issues I faced were due to behaviour of com interop and not shell extension specific.....

The same issue would occur on an asp.net 1.1 website if the first page browsed to was not asp.net (i.e. html) and contained an activex control written in .net 1.1.... the com interop layer defaults to the newest version of .net installed (which could be 2.0) but then when somebody browses to an asp.net page (which is 1.1) the com interop layer has already loaded 2.0 into the process and it will fail... even if you have set all your configurations to load in 1.1, the com interop layer will load in the newest version of .net (if one is not already loaded in the process, which might be 1.1).....

This Hanselminutes show describes this behaviour in detail....

http://www.hanselminutes.com/default.aspx?showID=69

Like I say, there may be other good reasons not to use shell extensions with C#, but I would just put this down as some strange default behaviour of com interop.