How can we help you today? How can we help you today?
odalet
I'm sorry, but I am just a guest on this project. And so, I can't generate a new release on codeplex. When I find time, I may post the patched binaries on a share site (or on a gmail account). / comments
I'm sorry, but I am just a guest on this project. And so, I can't generate a new release on codeplex. When I find time, I may post the patched binaries on a share site (or on a gmail account).
0 votes
Hi Jason, There were indeed two problems in Hawkeye source code: - Reflector's window title is not any more "Lutz Roeder's .NET Reflector" byut "Red Gate's .NET Reflector". Easy to fix! - The second one is due to the fact that now, Reflector is displaying the currently loaded list. So the real window title is "Red Gate's .NET Reflector - [My list]" if a non default assembly list is loaded. This second issue is fixed in Snippy's code: instead of using the Win32 API FindWindow (which only accepts the window text), you make use of EnumWindows along with a callback that checks that the window title starts with "Red Gate's .NET Reflector". All this is sufficient to have Hawkeye work correctly. Just for your information, Hawkeye isn't using the "code://" syntax to select elements: instead it first selects the target assembly, and then it uses a "X:Name" syntax where X can be either P, E, F or M respectively for Properties, Events, Fields and Methods. And this too works correctly. It also uses a different way to select an assembly. By what I could see by - following your advice - examining the bookmarks, the assemblies are specified that way: Assembly Name:Version:Public Key Token. For his part, Hawkeye is directly specifying the complete path to a file. I don't know which way is the best. And to finish with this story. I gonna post a patch (or update the source code) on Hawkeye codeplex's site using the latest version of RemoteController. As soon as this is done, I post a message in here. PS: your post led me to install your addin into Reflector. And I don't think I'll remove it: it's pretty useful. Thank you for this. / comments
Hi Jason, There were indeed two problems in Hawkeye source code: - Reflector's window title is not any more "Lutz Roeder's .NET Reflector" byut "Red Gate's .NET Reflector". Easy to fix! - The secon...
0 votes
In fact, the result is (a little bit) better if you revert to .NET 1.0 optimizations. This way, Reflector won't try to display anonymous delegates and will revert to a .NET 1.0 syntax, (with inner classes). But because these classes are generated, their name isn't C# compliant and it won't compile. In these sort of case, I use global renamings (replacing each invalid character in a name by an underscore, and hopping I won't have collisions). For instance here the same piece of code with .NET 1.0 optimization: using &#40;Task task = Task.Create&#40;new Action&lt;object&gt;&#40;class2.&lt;ForWorker&gt;b__3&#41;, manager, options | TaskCreationOptions.SelfReplicating&#41;&#41; &#123; task.Wait&#40;&#41;; &#125; And if you go to the <ForWorker>b__3 method, you can see this: int sharedIndex; int num3; int step = this.step; do &#123; sharedIndex = this.sharedIndex; num3 = sharedIndex + step; if &#40;num3 &lt; sharedIndex&#41; &#123; num3 = 0x7fffffff; &#125; &#125; Better, isn't it? And for information, System.Threading.dll is new and not yet RTM, but so useful! It is the new Microsoft Parallel extensions for .NET Download it here: http://www.microsoft.com/downloads/deta ... laylang=en / comments
In fact, the result is (a little bit) better if you revert to .NET 1.0 optimizations. This way, Reflector won't try to display anonymous delegates and will revert to a .NET 1.0 syntax, (with inner ...
0 votes
That is not a "problem", maybe a yet missing functionality... and it exists for years. In fact, from .NET 2.0, some language constructs are just syntactic sugar and lead to IL generation when compiled. These constructs include the yield statement among others (anonymous delegates and lambdas, anonymous types, linq, ...) I think the code you've seen is the generated code for a yield. Each time you build a quick IEnumerable implementation by writing a yield return..., behind the scene (at compile time) a complete enumerator class is built. Because it is directly generated in IL (well, I suppose so), the variable and method names don't have to respect C# naming restrictions. Starting this post, I said it may be a "missing" functionality. It would be great if we could turn on an option asking Reflector to check for the C# correctness of the statements, and if not correct, to generate C# compliant (or VB compliant) names (should not be too difficult: usually these variables and methods are private or internal, and any obfuscator knows how to do this...). In the same area, some problems can arise with non C# keywords or constructs. Usually switch statements don't compile back correctly (because if some goto that jump too far away for the C# compiler. And we can find some strange blocks in try/catch/finally: a faultblock can appear... This is valid in IL, but not in C# Quoting http://gregbeech.com/blogs/tech/archive ... lters.aspx fault - This block is similar to a finally block in that is observes error state but does not modify it, however the fault block is only run when an exception occurs so can allow clean-up which would only be valid under error conditions. This cannot be implemented in either C# or VB.NET. PS: you may encounter other weird things if you decompile VB.NET code or worst (very worst) Managed C++. The latter is the most probable (with obfuscated code) cause of crashes for Reflector. / comments
That is not a "problem", maybe a yet missing functionality... and it exists for years. In fact, from .NET 2.0, some language constructs are just syntactic sugar and lead to IL generation when compi...
0 votes