How to disable .NET Reflector’s auto-update feature

At the request of Red-Gate I have removed the contents of this post.

See below for the comment where I was politely reminded that the ‘free’ version of .NET Reflector is, to use the Free Software Foundation definition, ‘free’ as in ‘free beer’, not as in ‘free speech’.

  And for those of you who are wondering if the auto-update and auto-delete feature(s) can be disabled, the answer is yes and fairly easily (as of version 6.6.0.30).  Of course with the introduction of the open-source ILSpy I have to ask who cares ?

Update 6/2/2011

  RedGate announced that v6.8 of .NET Reflector, without the expiration date, will be made available to ‘current users’.  This post by Neil David (RedGate CEO) attempts to explain the reasoning behind their previous abhorrent behavior.  However, while on the surface it might look and feel like an honest attempt to ‘make things right’ it still feels like little more than another attempted marketing spin.  Why ? well for one thing, they are NOT making any of the v6.x versions available for download.  Posts on their forum from annoyed users pretty much explain the situation. 

   Well fear not RedGate, the wonders of the Internet will help out your disenfranchised target market where you apparently willnotcannot.  A quick google search for Reflector.6.6.0.30.zip yields a copy persisted for all time (or you can submit a comment and I will email you a copy ~2.05 meg zip).  So to those of you who are looking to get your ‘free license’ but don’t have a copy of the zip lying around, download the zip, extract it, and run Reflector.exe.  Because the version is immediately ‘out of date’ you will see a very confusing dialog box on startup saying:

This is the last free version of .NET Reflector which will expire May 30.
Do you want to download a free 14 day trail of version 7 ?

Clicking ‘Yes’ will perform the update and finally allow you to enter an email address to create a license key.  All of the steps are spelled out in this post from a RedGate forum.

   For those who want to verify the contents of the zip before running anything.

  1. Extract the contents of the zip into a temporary folder on your machine
  2. Download the fciv.exe tool avilable from Microsoft
  3. Verify the SHA1 hash of the extracted Reflector.exe before running it. 

Here is the SHA1 hash of Reflector.exe v 6.6.0.30

547e75ef960e5a6b7104df553f1b5401e9044f18

    The SHA1 hash above was generated using fciv.exe run against the Reflector.exe which I extracted from the original zip as downloaded from Redgate.com earlier this year(2/13/2011); good thing some of us are digital packrats. 

 

This entry was posted in Uncategorized. Bookmark the permalink.

17 Responses to How to disable .NET Reflector’s auto-update feature

  1. Bart Read says:

    Hi Bill,

    I’m glad that you’re a fan of .NET Reflector, and that you’ve found it useful over the years.

    I’m also sorry that the auto-update feature has caused you problems in more recent times. I’ve obviously written about this in detail elsewhere (http://www.simple-talk.com/community/blogs/bart/archive/2010/04/12/90624.aspx) so I’m not going to rehash the issue here. Suffice to say that the redirect to our website was a *temporary* *measure* only. I would have preferred to do this by some other means but our lawyers sprung this on us right before release so we were out of options, and we ended up having to do it despite knowing full well it was going to annoy a lot of people, whilst providing no tangible benefit to anyone.

    Let me assure you that beyond this we have made no changes to the update mechanism for the free tool – if we had, I would have told you. You can see that the deletion existed as far back as 2006 (it does not affect Pro, BTW): http://channel9.msdn.com/forums/Coffeehouse/207147-Reflector-removes-itself/.

    Now, as it happens, we are considering alternatives to the present auto-update mechanism, and whilst I can’t tell you what we’ll eventually do I can assure you that *all* options are being considered.

    In the meantime, whilst I completely understand your frustration, I must regretfully point out that your post is in violation of our license agreement, so we’d be very grateful if you could please remove it.

    If you have any further feedback, please feel free to contact me directly.

    Kind regards,

    Bart

  2. Anonymous says:

    Seems Bart is saying if you do this then you will violate the agreement. Doesn’t seem like there’s anything wrong with publishing how to do it.

    • wnmoran says:

      He said ‘your post is in violation of our licensing agreement’. I believe you are right that it could probably be debated, however something tells me that would NOT be a a friendly exchange so it’s just not worth it.

  3. RichardD says:

    What a surprise – RedGate demand that you take this post down, then start demanding money from users of the free version. What a bunch of crooks.

    • wnmoran says:

      I completely agree. Once the changes I described were applied, the resulting ‘hacked’ version was functionally identical to what they are now charging $35. A version with no time-bombs and no forced updates, something that just worked.

      • RichardD says:

        Given their total lack of respect for their users, would you consider re-releasing this information? Or at least giving us a hint? 🙂

      • wnmoran says:

        The way by which I figured out the ‘time-bomb’ and auto-delete was a bit involved, so just hinting at it won’t do you much good. However here are some thoughts for you to ponder:

        1 ) RedGate creates a product called ‘SmartAssembly’ which obfuscates .NET assemblies.
        2 ) The ‘SmartAssembly’ features page says that it not only obfuscates the IL but also ‘Encodes strings in your assemblies to hide important information like passwords, SQL requests, serial numbers, login information.’
        3 ) Base64 is an encoding which can represent text and binary data
        4 ) .NET assemblies store strings as resources
        5 ) Many tools exist which deobfuscate obfuscated assemblies. Results from a google search indicate that information about one such tool can be found here: http://rongchaua.net/blog/desmart-deobfuscator-for-smartassembly/ and can be downloaded here: http://rongchaua.net/Web/Tool/DeSmart.zip.
        6 ) 7Zip is an AWESOME zip/unzip utility to use when other zip/unzip tools have problems opening zip files.
        7 ) Imperical evidence shows that .NET Reflector will run without network access, and also determines that it is ‘out of date’ without network/INET access.
        8 ) The .NET DateTime structure represents date/time and provides methods to compare DateTime instances
        9 ) Imperical evidence shows that .NET Reflector displays the ‘out of date’ message box on startup
        10 ) Imperical evidence shows that .NET Reflector auto-deletes itself if it is out of date.
        11 ) An application cannot delete itself.
        12 ) Temporary files are NOT cleaned up automatically. So any temporary file created, text, executable, whatever, will remain in the temporary location where it was created
        13 ) The Process class is used to create and run a Process.

      • RichardD says:

        Thanks – I think I see what’s going on.

        The current version is set to start nagging on 30 April @ 1:02:03 AM, and expire on 30 May @ 1:02:03 AM.

        There’s a check against an on-line version file, but only once the nag date has passed.

        Hopefully, using the RunAsDate “tweak” [1] should avoid the time-bomb.

        [1] http://www.codeproject.com/Lounge.aspx?msg=3756986#xx3756986xx

      • wnmoran says:

        Well, if you read a ZDNet interview here you can read the following quote from the interview with Greg Tillman:

        .NET Reflector actually has always had a 6 month expiration date built in to each version.

        Kinda sums it up right there 😉

      • RichardD says:

        Yes, but there’s a difference between a six month expiration date to force you to get the latest *free* version and a six month expiration date which forces you to pay.

        Greg and his RedGate cronies seem to have forgotten this, and instead spend their time bleating that Lutz added the expiration date, so it’s not their fault.

        I have to assume they’re either in dire financial straits or run by a bunch of evil despotic crooks.

      • wnmoran says:

        The point of my previous comment was that they are stating fairly clearly that the ‘expiration date’ is embedded in the executable.

        In response to your comment I completely agree. A more appropriate course of action could have been to provide one last ‘update’ to the current ‘free’ version which removed the time-bomb and forced-update. After which, no support/updates etc. would be provided, effectively ‘end-of-life’ing the ‘free’ version but leaving it functional. Then remove the ‘free’ moniker from that product line and simply market it as what it is – the low-end in their Reflector line (.NET Reflector, .NET Reflector VS, and .NET Reflector VSPro) as described here. From that point onward they would obtain business like every other company; provide enough value that it compels people to purchase the product.
        To me it’s clear that other ways existed for them to get ‘out’ of the ‘free’ business without abandoning the community that they were ‘commited’ to supporting, however those ways didn’t include a ‘payday’.

  4. Bobby says:

    Well, RedGate shot itself in the foot by trying to charge $35 for a program which is ridiculously easy to write. There’s already a free, open-source replacement to this program called “ILSpy”:

    http://wiki.sharpdevelop.net/ilspy.ashx

    Looks and works exactly the same as the good old original Lutz Roeder .NET reflector. And it’s just as free!

    A few years from now nobody will know who Red Gate is…

    • wnmoran says:

      Obviously I agree that RedGate made a bad move. I believe their mistake was they, effectively, tried to extort the community to pay for .NET Reflector. On those grounds, if you want to bash RedGate go ahead bash away. However, saying that such a program (.NET Reflector, ILSpy, or otherwise) is ‘rediculously easy to write’ is both incorrect and disrespectful of Lutz Roeder and the SharpDevelop folks. Many people are under the incorrect assumption that you can just use the functionality from the System.Reflection namespace to get this behavior; well you can’t. Sure, it can be used to approximate some of the functionality, however it is not the same by any stretch.

  5. kornman00 says:

    My biggest issue is that there is already a base of developed add-ins for Reflector. Now, while free alternatives to RedGate’s baloney may arise, those alternatives may not have add-in support, delayed add-in support, or the particular add-ins people are use to using.

    http://reflectoraddins.codeplex.com/ lists many add-ins for Reflector. However, not all of the listed add-ins are maintained in the codeplex repo (so not all could potentially be ported). For instance, I like to use the CppCliLanguage add-in, but it’s external to the codeplex project.

    So if a “certain someone” wanted to “relay” some redacted information via email to a person responding to this blog, I’m sure that person would be very thankful of the “certain someone”.

    • wnmoran says:

      I agree, support (or lack there-of) for existing .NET reflector plugins will be an adoption issue of any up-and-coming Reflector replacement. And even if it does offer a plug-in architecture, the incompatibilities between the two architectures will probably make porting existing Reflector plug-ins a bit of a challange.

  6. Anonymous says:

    The problem here is the fact that RedGate have forgot that the software is targeted towards programmers who are clever enough to know how to work around paying for the software. Well done RedGate, carry on saying you are the best employer to work for because if you treat your customers like this then I suspect you treat your staff worse.

Leave a comment