How can we help you today? How can we help you today?

Red-Gate reflector has problems when used for the API

I've got a tool that is using the Reflector API by adding the reflector.exe as an assembly reference.

I upgraded to the red-gate one because the last lutz version was throwing up the stupid out of date warning and halting my command-line tool.

But I now have two worse problems:

1. (Turns out this affects the old version too). If you have the Reflector GUI running when you try to access this API:

IAssemblyManager assemblyMgr =
(IAssemblyManager)serviceProvider.GetService(typeof(IAssemblyManager));
IAssembly rAssembly = assemblyMgr.LoadFile(assembly2.CodeBase.Replace("file:///", ""));

it causes a null reference exception.

2. The _new_ problem is that when I run with the new version of reflector as an API and it hits those same lines of code above, it throws a GUI dialog box saying "The specified font size is invalid.". That happens every time those lines are hit. This did not happen before the red-gate version.

I don't get this error when I run the GUI. But it seems as if the code is obfuscated enough that I can't see why it might be throwing up this error. It is annoying because you have to click "okay" to continue and then the program works as before.
core24
0

Comments

1 comment

Sort by
  • core24
    Well, after some head-banging-on-wall (translation: lots of black-box testing and trial & error) I came across the root cause of both issues: my command-line utility arguments were being interpreted by Reflector as reflector command-line arguments even when just calling the API. Of course the code is obfuscated and hidden so I couldn't see exactly what was going on.

    For future reference: any -f: or /f: argument is interpreted by Reflector as specifying a different font. That caused the invalid font errors.

    And, -s: or /s: arguments are okay -- so long as there aren't more than one on the command-line. If there are, you will get a series of exceptions loading the AssemblyManager(), ending in a fatal TargetInvocationException.

    Once I changed both of these to different argument letters (/a: and /p: respectively), all problems went away.

    Additionally, the behaviour where running the tool while the GUI was running no longer causes any issues either. There is some hidden, internal argument parsing magic going on that would be nice to have documented...
    core24
    0

Add comment

Please sign in to leave a comment.