CLR V4: Load your profiler without using the registry
One of the new features in CLR V4 is the ability to load your profiler without needing to register it first. In V2, we would look at the following environment variables:
COR_ENABLE_PROFILING=1
COR_PROFILER={CLSID of profiler}
and look up the CLSID from COR_PROFILER in the registry to find the full path to your profiler's DLL. Just like with any COM server DLL, we look for your profiler's CLSID under HKEY_CLASSES_ROOT, which merges the classes from HKLM and HKCU.
We mostly follow the same algorithm in V4, so you can continue registering your profiler if you wish. However, in V4 we look for one more environment variable first:
COR_PROFILER_PATH=full path to your profiler's DLL
If that environment variable is present, we skip the registry look up altogether, and just use the path from COR_PROFILER_PATH to load your DLL. A couple things to note about this:
- COR_PROFILER_PATH is purely optional. If you don't specify COR_PROFILER_PATH, we use the old procedure of looking up your profiler's CLSID in the registry to find its path
- If you specify COR_PROFILER_PATH and register your profiler, then COR_PROFILER_PATH always wins. Even if COR_PROFILER_PATH points to an invalid path, we will still use COR_PROFILER_PATH, and just fail to load your profiler.
- COR_PROFILER is always required. If you specify COR_PROFILER_PATH, we skip the registry look up; however, we still need to know your profiler's CLSID, so we can pass it to your class factory's CreateInstance call.
Comments
Anonymous
October 15, 2010
This is a nice improvement, but we have to support both 32 bit and 64 bit processes. Right now using the CLSID approach 32 bit processes are able to find the 32 bit DLL and 64 bit processes can find the x64 dll. I'd love to avoid the problems with the registry, but I need at least two environment variables. Is there any way to support both 32 & 64 bit processes using the COR_PROFILER_PATH variable?Anonymous
October 15, 2010
Hi, Saxon. Great point. I enourage you to post this on social.msdn.microsoft.com/.../threads so the profiling API team can get into a discussion on this with you.