Comments
8 comments
-
I downloaded the latest version of reflector only to find that it didn't work with mono and was quite disheartened. I am glad to see that you are still interested in supporting mono! I am looking forward to the latest version of reflector.
Thank you! -
Hi cipher,
No problem. I note that even previous versions don't work perfectly with Mono: it's relatively common for .NET Reflector to simply exit, though this might be due to the "Show PDB symbols" setting. Please see this post from Miguel for more information:
http://weblogs.asp.net/nunitaddin/archi ... 1-2-3.aspx
If you're having problems with the current 5.1.6.0 build, this might be why.
The next Mono compatible build will be 5.1.7.0, and will only work on Mono, but will be identical to 5.1.6.0 in all other ways. We'll release it at the same time as .NET Reflector 6.
Thanks,
Bart -
Reflector 6.5 should be compatible with Mono
Unstickying -
Alex.Davies wrote:Reflector 6.5 should be compatible with Mono
Unstickying
"should be", but isn't :
mono 2.8.1 exits with WARNING: The runtime version supported by this application is unavailable. Using default runtime: v2.0.50727
Where is a link to the old version 5.1.7? -
Who cares now?
Reflector is stolen from community. -
gaearon wrote:Who cares now?
Reflector is stolen from community.
Well it has to be said that I care quite a bit, it'd be good to see Redgate formally drop support, or offer some kind of lip service as to why something that fundamentally still would work except for Red gates own tinkering and obfuscation is now out of the hands of a sizable community.
I think mono support on Linux is a much better bet that support for oxygene.net dasm(IL).
Has to be said the one time I purchased a Redgate tool (SQL refactor) it worked fairly well although, no further releases, no feature enhancements. I doubt I'll ever return to make another purchase. Also noting it had a completely mental license where you had to unlicense your software before doing a computer rebuild or you could never reactivate it.
Just goes to show that Redgate cash the enterprise cheque and don't give a damn about the average developer. They should stay away from developer tools and stick to what they do best, making apparel (SQL toolbelts) -
Hi there,
Thanks for your comments about Mono support. I can confirm that support for running Reflector under Mono will be officially dropped with the release of version 7. We'd planned to make an announcement about this shortly but, since you've asked, I'm happy to provide some more detail about why this is. Incidentally, although I didn't make direct mention of it in my EA announcement I did allude to this when I described how v7 needs .NET 3.5 or later to run:
http://www.simple-talk.com/community/bl ... 96204.aspx
Obviously this news will come as a disappointment to some, but we made the decision for a couple of reasons.
Firstly, we want to keep Reflector current in terms of support for newer technologies. This may still have been possible whilst continuing to limit ourselves to .NET 1.x compatibility, but would have become increasingly difficult and would ultimately limit our ability to develop the tool in the way we'd like. Whilst Mono supports many of the technologies in later framework versions, a crucial missing link is WPF, which would have a big impact on what we could do with the UI, and also what we might be able to do to provide specific support for technologies such as Silverlight. Certainly there are things we can do without this but, as I've said, it will become increasingly difficult for us to take the tool forward as we'd like with our hands tied technologically.
This leads me onto the second reason...
It's possible none of the above would matter if Mono were in relatively widespread use throughout the Reflector community, but the final nail in the coffin was the realisation that amongst Reflector users Mono is less commonly installed (never mind used) than .NET 1.x, and we'd already taken the decision to stop supporting the latter. Due to this very low penetration amongst Reflector users I could justify neither the extra effort required to support Mono, nor the restrictions supporting it would place on future development.
Note that I'm not making any comment on the overall adoption of Mono, just its prevalence in the Reflector userbase.
Obviously any assemblies compiled with Mono (or .NET 1.x, for that matter) should continue to open fine in Reflector.
If Mono implemented WPF we might take another look at it, although there are some stability issues running on Mono, which I mentioned in an earlier post, that I think we'd need to take a look at before I'd be happy to claim official support.
I hope that clarifies matters for you and, once again, thanks for posting your feedback.
Kind regards,
Bart -
Bart Read wrote:It's possible none of the above would matter if Mono were in relatively widespread use throughout the Reflector community, Bart
I suppose you have good methods to measure this claim?
Anyway, Thanks for the reply.
So why can't Red Gate offer an old version that never times out (for mono users.)
Why are you one of the only companies that doesn't offer access to older versions of your software?
You have to understand why the community feels a bit shafted, given that even Lutz said
Red Gate will continue to provide the free community version and is looking for your feedback and ideas for future versions.
Add comment
Please sign in to leave a comment.
I'm writing because I want to give you a heads up about a problem we’ve discovered with Mono compatibility in the new version of .NET Reflector, due to be released in February.
At PDC back in November I assured the Mono guys we met that we would continue to support running on Mono with .NET Reflector 6, though not .NET Reflector Pro, since the Pro functionality is part of the Visual Studio add-in. This is still my intention in the longer term. Unfortunately just before Christmas we discovered a problem with our obfuscation that breaks compatibility with Mono in builds of .NET Reflector 6, and we can't go back to the old protection scheme due to other changes we've made.
At the end of summer last year we acquired the {smartassembly} obfuscator, and we've been using it to protect .NET Reflector for the past two months or so, which is what has caused the problem. As part of a larger batch of updates and fixes, we're going to patch {smartassembly} so that it doesn't cause compatibility problems with Mono, so this won't come up again. Unfortunately those fixes won't be available before .NET Reflector 6 is due to be released but, in the meantime, I'm anxious not to leave Mono users out in the cold, without a working build of .NET Reflector, so I propose the following:
(1) We will release .NET Reflector 6/.NET Reflector Pro in its current form, without Mono compatibility, towards the end of February.
(2) At the same time, we will release a build of .NET Reflector that will only run on Mono. This will probably be version 5.1.7.0. This will be identical to the current 5.1.6.0 release, apart from the fact that it will only work on Mono. It won’t contain any of the bug fixes we’ve added to version 6, and it obviously won’t contain any of the Pro functionality in the Visual Studio add-in, but it will do everything that the current 5.1.6.0 release can do.
(3) We’ll make both builds available from the Red Gate website, and we’ll add a sticky to our support forum about the Mono-compatible build, just in case people miss the download link on the website.
Let me emphasise that this is something I regard only as an interim solution. As soon as we’re in a position to do so, we’ll put out a 6.x build that is protected by {smartassembly}, and will work with Mono, and thus Mono users will get the benefit of the bug fixes we’ve added to the v6 release.
If you have any comments or feedback about this, please let me know.
Thanks,