Extension code cannot run standalone, but only within ILM. To debug the code you must first attach Visual Studio to the miiserver process.
Can’t see the miiserver process?
You may have to tick options to show all processes.
ILM/MIIS installed on another machine?
You can attach to processes on remote servers, however you need to install the remote debug components on the ILM server (check your VS help for details).
It is also important to ensure that the version of the dlls on the remote server matches exactly the code you are looking at in Visual Studio.
Once you’ve successfully attached to the process you can insert breakpoints in your code, and then start a task in Identity Manager.
For total VS newbies, the following are useful:
- F10 key to step through the code,
- F5 to continue running the code until the next breakpoint,
- Quick Watch to check the value of a variable or statement,
- Add Watch to list variables you want to keep an eye on.
Breakpoints not hit
There are a number of reasons why a breakpoint may not be hit during a debug session. Here are some suggestions:
For VS2005, symbols not loaded
See Brad’s answer here.
Code not compiled with Debug option
Check you have compiled a “Debug” rather than a “Release” version of the dll.
Breakpoint in a code segment that is skipped
A rather obvious one this – if your breakpoint is in a subroutine, or inside something like an If or Select statement, also add a breakpoint that will be hit before the code branch, so you can find out why the segment isn’t being entered.
Breakpoint in the Initialize or Terminate subs
These subs are rather particular:
- ILM loads the Initialize sub once at the beginning of the first call to the dll;
- It keeps the Initialize sub in memory for 5 minutes after all calls the the dll finish;
- After the 5 minutes, ILM runs the Terminate sub, and unloads the Initialize sub.
So if your breakpoint is in the Terminate sub you will have to wait 5 minutes for it to be hit!
And if it’s in the Initialize sub, and you’re running the dll over and over again (within 5 minutes) ILM will not run it again!
You can force ILM to reload the Initialize sub by modifying and rebuilding the dll, or by restarting the MIIS service.
MA running in a seperate process
In the MA configuration, if you ticked “Run this rules extension in a seperate process”, you will not be able to debug it via the miiserver process. You would have to, somehow, attach to the seperate process while it is active. It is much simpler to just make sure this option is unticked whenever you need to debug.
Be especially aware when creating CDS extensions for Extensible MAs – they have this option ticked by default.
Provisioning (or individual dlls) turned off
Check that provisioning is enabled in Identity Manager under Tools -> Options. Also check if this installation has XML files which switch on or off individual dlls.
Error happens before the extension code starts to run
Some errors (typically involving connection to the data source) happen even before the code gets a chance to run. You should see a stopped-extension-dll-exception, and there will be more information in the Windows Application Event log.
Make use of the Preview function in ILM/MIIS to simulate a synchronization of a selected connector space object. In ILM you can now commit this preview, but for code debugging it is usually more useful to replay the sync as many times as you need to get the code right.
You can learn a lot about how ILM works by watching your code running in debug mode. It’s an essential tool for building a stable ILM environment so have fun using it!