Erich,
I think I might have misled you slightly. When the plugin gets called for the first time the variables aren't passed through? At least I seem to recall that's the way it works. I think that's the reason why the variable names aren't automatically pushed through. In other words there are statements in IA which when you edit them in the MSIcode window all the variables names appear selectable. To pass those into a plugin in C# you might need
another plugin that returns the variables names into a variable and then you can pass that into a C# plugin and then break them down into single names. As you can see the C# plugin might be convenient to some extent but it's not as comprehensive as those you write in Delphi or C++ which I think are the core languages used to write IA. I apologise if I've got that completely wrong.
When the same method is called the second time, the variables are passed in with their existing values and that's how I loop through them and replace the value, which is usually/sometimes/often/always (choose one or more
) null, with the stored value the plugin wants to return. The thing that puzzles me is that it all used to work okay and you've since confirmed you're using VS2013. It's just weird why it used to work but now does not. I know for sure that christ23 and me both started off using VS2010 which is why his input could be valuable.
The next thing I need to try is debugging the plugin at runtime. I don't know if you've attempted that but it can be done. It involves using the JIT debugger. Look in that project called Accessory I gave you and switch (in VS) to the project's properties. Select the Build tab, and in the Conditional compilation symbols text you'll see something like this: dontENABLEJITDEBUGGING. Remove the "dont" prefix. In the Accessory solution look at the source code in Accessory.cs at method EnableJitDebugging. The code should now appear compilable and when it gets called the System.Diagnostics.Debugger.Launch() statement should now be visible as compilable code. Copy all your assemblies and pdb files into the same location where your plugin is installed. Set a breakpoint in VS where you want to stop at. Then, when IA calls the bridge into your plugin the JIT debugger should then open a selectable dialog and which allows you to attach to the assembly you want to break at. In theory, when the bridge runs through your plugin your attached debugging session in VS should hit your VS breakpoint and from there you should be able to dig a little deeper.
I know this JIT debugging also used to work because both me and christ23 confirmed it does/did. Whether anything has changed since I last tried it well over a year ago I'm not sure. I have a Word document in which I described it for my own benefit at the time so I'll have a go later and if it still works I'll cut it down to the bare bones and let you have a copy of it for reference. I'm sort of glad I've had a chance to look at the DotNet plugin development again. Unless you discover something in the meantime, it's going to take me a little time to retrain myself.
As I once mentioned somewhere before I'm at the age where I have the memory retention of a garden slug and the keyboard dexterity of a chicken pecking the dirt for grain.
Peter. Smartly dressed, he still resembles an unmade bed.
InstallAware MVP
