|
HiGuys and Gals!
So I enumerate all managed processes this way and it showsme asp.netprocess aspnet_wp.exefor .net 2, but it doesn't show for .net 4. Should I enumberatethem differently? //30. Create Cor Publisher hr = CoCreateInstance( __uuidof( CorpubPublish ), NULL, CLSCTX_INPROC_SERVER, __uuidof( ICorPublish ), reinterpret_cast< LPVOID * >( &corDebuggerPublisher ) );
//40. Enumerate managed processes hr = corDebuggerPublisher->EnumProcesses( COR_PUB_MANAGEDONLY, &activeProcesses ); Looks like .net 4 creates it's own aspnet_wp.exe, so I see 2 of them in task manager, 1 for v4 and 1 for v2.
Thanks!
Dan All RepliesDan,
This interface can be made to work for V1, V2 and V4, but it's not the API I'd recommend using if V2 and/or V4 are installed on the machine. For any scenario requiring you to know specifically what version of the runtime is in a target process, the API is insufficient. We actually plan to remove the API at some point. In light of all that, here's my recommendation:
- If V4 is the latest runtime on the machine, use the new MetaHost APIs (the key one being EnumerateLoadedRuntimes). This will tell you which runtimes, if any, are loaded in a target process: V1 or V2 and/or V4 (Yes, there can be more than one as of V4. We call that in-process side-by-side).
- If V2 is the latest installed on the machine, you can use GetVersionFromProcess. This will tell you what version (V1x or V2), if any, is loaded in a target process.
- If V1 is the latest, use ICorPublish (as you are above).
One key difference between the first two bullets and the last is in the former two, you're looping the target processes, calling either EnumerateLoadedRuntimes or GetVersionFromProcess for each. In the latter case, it just returns you an enumeration ofall the"managed" processes on the machine. While looping through sounds like more work, either you, or the API implementation are going to have todo it. The benefit of your doing it, using the newer APIs, is that you can get more information about what runtime(s)is/are running in the target as opposed to knowing only that some version is.
Your workflow should look like this:
- Load mscoree.dll
- If this fails, no runtime is installed
- GetProcAddress on GetCLRMetaHost (in Beta2, this API name will change to CLRCreateInstance)
- If that succeeds, use the API to get an ICLRMetaHost interface
- Loop through the processes on the machine calling ICLRMetaHost::EnumerateLoadedRuntimes for each
- If one or more are loaded, you'll get an ICLRRuntimeInfo for each, which you can use to reason about the runtime(s) in the target
- If GetProcAddress for GetCLRMetaHost fails, V4 is not installed. Call GetProcAddress on GetVersionFromProcess
- If that succeeds, loop through the processes on the machine calling GetVersionFromProcess for each
- If one is loaded, it will return the version string (e.g. v1.1.4322 or V2.0.50727)
- If GetProcAddress for GetVersionFromProcess fails, V2 is not installed. CoCreateInstance CorPubPublish and use your existing code to enumerate. If any are returned, assume they're v1.x
If you're curious about how to make an ICorPublish solution work, let me know and I'll either post details in the forum or write a blog entry and point you to it (it's a much more confusing solution).For some background information, I'd recommend watching our Channel9 video "CLR 4 - Side-by-Side In-Process - What. How. Why." It should shed light on some topics I didn't explain in detail in this response; specifically, in-process side-by-side and our V4 compatibility policy (e.g. why doesn't CoCreateInstance get me a V4 version of ICorPublish).
If you don't think the proposed solution will meet your requirements, please help us understand your high-level scenario and we can offer other suggestions for a solution.
Regards, Jon
- Marked As Answer byJon LangdonMSFT, OwnerMonday, September 21, 2009 6:45 PM
- Unmarked As Answer byJon LangdonMSFT, OwnerMonday, September 21, 2009 6:51 PM
-
Thanks. I would have never guessed... My goal is very simple, it's to enumerate the running processes and attach to the one I select. I am attaching to asp.net processes cause that's the debugger I am writing primarily. Other than this simple task I also want to be able to attach to asp.net process before it actually executes anything, right when it's created. And I have no idea how to do it other than scan for processes repeadely and attach right away, hoping I cought it in time.
I appreciate it,
Dan
|