.Net Reflector could not resolve Reflector.CrossNet

May 10, 2010 at 3:15 AM

Hi, I will greatly appreciate some help.

I have had issues with getting started and am getting the error; ".Net Reflector could not resolve Reflector.CrossNet". The Relector version is 6.1.0.11 and all CrossNet projects have compiled successfully.
All steps up to 4.5 at http://crossnet.codeplex.com/wikipage?title=started&referringTitle=Overview (see red, bolded text in extract below).

  • Run Reflector.exe, select .NET 2.0 runtime version (it should not matter but never know).
    1. Go in View -> AddIns, and add Reflector.CrossNet to the list of add-ins.
    2. If you regularly use Reflector make sure that the optimization mode is set to .NET 2.0 (not 3.0+).
    3. Close Reflector.exe.
    4. Open the command prompt (run cmd.exe) and go in the folder where Reflector.exe is located (and the 2 other dlls).
    5. Type: Reflector.exe /select:Reflector.CrossNet /crossnet:C:\TempFolder\Reflector.CrossNet\Example.xml
    6. This will show Reflector UI for few seconds and should close it after a short beep.
    7. If you go in CrossNetBenchmark folder you should see the C++ sources updated.

    So far, I have discovered that the first part of the command should include the Reflector.CrossNet.dll like so; "Reflector.exe /select:Reflector.CrossNet Reflector.CrossNet.dll", but even with that, the error persists.

  • Coordinator
    May 11, 2010 at 3:32 AM

    Thanks a lot for the feedback!

    So it appears that with a more recent version of Reflector (I guess due to some refactoring by Red-gate) the behavior of Reflector is different.

    When using the version from Mid-February, I do get the same annoying error message, but it actually does not change the behavior of the code. If you put a breakpoint in the method of Provider (in the Project CrossNetParser/Net), the methods are actually executed. However there is a much bigger issue. Assembly.GetTypes() does not work, it dies because of some unknown token .NET token (huh!?! some sort of protection?).

    This last issue prevents the creation of the service provider that give access to the Reflector API. As of today, this is a blocking item :(. I'll talk to some people at red-gate to see if this can be resolved. I suppose that you could use an older version of Reflector - assuming that auto-update has been deactivated with the switch to red-gate (I have some in my archives but I don't know if legally I can give you access to them).

    Unfortunately I don't have an ETA. Sorry about that, I will keep you posted.

    Regards,

    Olivier

    May 11, 2010 at 6:22 PM
    Edited May 11, 2010 at 6:22 PM

    Thanks for that.

    I have some older versions of Reflector hanging about, so I'll give them a whirl and see it all goes well while I await your feedback. Its a bit cheeky of Redgate to change things that way, I wonder how many other Reflector add-ins have been so mercilessly broken.

    …Diversion, but, another thing; you’ve got a really great product in the making. Have you considered weaning the project completely off Reflector and perhaps, going with stuff like expression trees and open source components like SharpDevelop's NRefactory? A lot more work, but there is no AOT for C# .NET; add on a compiler and you are well poised to be the first.

    Coordinator
    May 12, 2010 at 1:38 AM

    Ok, so good news, the support is much better than before, so I had an answer within hours.

    I just tested and I have things working again... (although because I am in the middle of adding support to gcc, so I have unrelated compiler errors in the generated C++ code. So not sure it is 100% generated correctly yet).

    The parameter "/select:Reflector.CrossNet" is not necessary anymore. Actually now, it creates some issues, so you can remove it. I will update the setup wiki page.

    To fix the crash that I had, you need to replace the method CrossNet.Net.Provider.Initialize() in the project CrossNetParser, like this:

    public static void Initialize()

    {

        sServiceprovider = new Reflector.ApplicationManager(null);    // Concrete types are not obfuscated anymore, so we can create them directly

        sAssemblyManager = (IAssemblyManager)sServiceprovider.GetService(typeof(IAssemblyManager));

        sTranslatormanager = (ITranslatorManager)sServiceProvider.GetService(typeof(ITranslatorManager));

    }

    Let me know how it goes, but now that was back on track.

    >> I wonder how many other Reflector add-ins have been so mercilessly broken.

    That impacted only CLI usage, which was not officially supported at the time anyway. I may have been one of the rare add-in to really need it. :) Although the errors in the XML file are not reported, so best at first is to run under Visual Studio and exceptions turned on in case you don't have the expected output.

    >>…Diversion, but, another thing; you’ve got a really great product in the making. Have you considered weaning the project completely off Reflector and perhaps, going with stuff like expression trees and open source components like SharpDevelop's NRefactory? A lot more work, but there is no AOT for C# .NET; add on a compiler and you are well poised to be the first

    Thanks you for the kind words. I thought about it several times but 3 years ago there was not that many API allowing that. (Reflector was the only serious one I found). Things may be different now. Given that Mono is not a great solution for X360, PS3 and Wii. And it not officially possible anymore for iPhone and iPad, I guess CrossNet has still some use :). If only a game studio wanted to help the dev of CrossNet :).

    Cheers,

    Olivier