Congrats on aquiring .NET Reflector.

NOW FREE THE CODE!

The fact that Reflector is obfuscated is not just ironic, but a bit sad. There have been a few times where I would have loved to poke around inside to see how things are done, but although Reflector helps you snoop around in other people's code, you can't see what's going on in reflector itself!

Free the code not just for the irony, but because it makes coding plugins harder than it needs to be.

Which reminds me, document the plugin api!
Will
0

Comments

8 comments

  • TigerShark
    You're absolutely right. I never understood why Lutz hid the implementation details from us... I did however manage to make some sense out of the obfuscated code, but it would be so much nicer to see it in the original form...

    I don't see any reason for releasing the code, just don't obfuscate the assemblies.
    TigerShark
    0
  • Peter Ritchie
    Agreed. Please OSS Reflector.
    Peter Ritchie
    0
  • Omari
    Yes, make it open source.
    Omari
    0
  • TigerShark
    Why should they release the code? I see no need for this. Red Gate acquired Reflector to work on it, not to make it Open Source. That's at least not what I understand of it.

    We have the perfect tool for disassembling assemblies, but just not the tool itself. All Red Gate have to do is to avoid obfuscating the source when they release a new version of Reflector, which I hope they do (avoid I mean) :)
    TigerShark
    0
  • Peter Ritchie
    Why should they release the code? The same reason why they should stop obfuscating it, of course. If it's not obfuscated and it's free, why not let the community contribute to it? They don't need to open it up to anyone who wants to commit; but they can at least accept patches. If someone encounters a bug, finds the problem, fixes, and provides a patch; that's that much less work they have to do.
    Peter Ritchie
    0
  • Peter Ritchie
    Simply look at all the change requests... Simply put Reflector up on CodePlex, let people add issues, and the community can provide patches for those issues. If red-gate decides they don't want to put the patch in the trunk, so be it; but at least the people who do want that patch can download it and use it. If they do decide to integrate the patch, then they didn't have to work on that feature.
    Peter Ritchie
    0
  • dnm
    I'm in favor of not obfuscating Reflector. My recollection is that early versions of Reflector that I used were not obfuscated. I forget when that changed, but I think it was around late 2002 or early 2003. I'd be happy for a source code release, of course, but my understanding is that Red Gate plans to develop a commercial version of Reflector.

    This hasn't been said explicitly anywhere that I've seen yet (though I've hardly scoured the forums), I've just read Lutz's email announcing the hand-off. However, in that email, the language Lutz used was that Red Gate would "continue to provide the free community version" of Reflector. This implies Red Gate is considering releasing a non-free commercial version.

    A compromise might involve not obfuscating the community version of Reflector (and still not releasing the source code), but obfuscating the commercial version, with license terms to match (i.e. it is OK to reverse engineer and inspect the community version, but not the commercial version).

    In the short term, I don't think the free community version and any potential commercial version would be significantly different such as to protect Red Gate from competition, and thus, open sourcing the community version code wouldn't be in their best interest. Depending on the nature of the changes made to a commercial version, that could change. Otherwise, if they were to open source the community version now, they'd almost certainly have to do under a license which prevented someone from making a competing product to their commercial version. This would almost certainly not make open source advocates terribly happy, so not a big win for Red Gate.
    dnm
    0
  • avidtrober
    It's obsufucated to protect the intellectual property.

    It appears barely more than the UI is managed (.Net) while the rest is unmanaged, e.g. http://msdn.microsoft.com/en-us/library/ms404384.aspx.

    I'm guessing the windbg debugger symbols APIs are used in order to know the exact variable names of assemblies. I've noticed it builds some name for the variables if the assemblies are not accessible. (But, I've never FileMon'd Reflector or debugged it to know for sure).

    You can download Rotor, http://research.microsoft.com/sscli/, to see how many things work in the CLR.

    It's pretty much (advanced) programming knowledge how to build a .Net Reflector. It's just too much of a pain to do it when .Net Reflector was free. If it starts costing, count on it, another free one will pop up.
    avidtrober
    0

Add comment

Please sign in to leave a comment.