I have an obfuscated executable and I want to debug the EXE. I've tried to look into the source code with the .NET Reflector. While looking into the source, an internal exception has been thrown within the .NET Reflector. So I want to get the source code or to debug the application. Are there any possibilities to debug the app or to get the source in C# syntax?
Reflector doesn't give you the source code. It gives you a reverse engineered version of what the source code might have looked like based on the actual IL. If the code has been obfuscated identifiers will make little sense, but you can still view the code using Reflector. You can dump the generated C# code from Reflector using the FileDisassembler add-in.
Related
I'm pretty new to ServiceStack, so apologies in advance if the nomenclature is not 100%.
I create a test self-hosted application and the ServiceStack Service was in the same assembly as the mainline code. All good.
I then moved the code to production use, and service now lives in a separate assembly to the main code. Initially, I have a test harness that I use to make sure everything works fine, and then a windows service that references that same assembly. Fairly sure this would be normal usage.
The test harness works fine, however for production use, I have used Fody Costura to embed the assemblies into a single executable (makes it easier to copy from dev machine to production machine was my thinking).
When using Fody Costura to embed the assembly into the executable, ServiceStack returns an error during the Init() (invalid path). I have tested this and it seems that the ServiceStack Service class needs to be in a physical assembly file that can be loaded, and not a resource.
Is there are known work around for this, or do I need to retain the code in its own assembly for ServiceStack to work?
Thanks in advance.
Craig
I'm not familiar with Fody Costura impact, but the ServiceStack.Gap project shows how you can ILMerge ServiceStack into a single cross-platform .exe.
I have a largish application that currently uses log4cxx as its logging system. However, these appears to be a dead project, and I cannot get it to work with Visual Studio 2013. As such, I am looking to move to log4net
Our project is a mixed C+/C# project, using .net 3.5, and the logging is pretty simple
What is the best way to handle this migration. Any particular problems that people would expect to see, any required changes to config files, etc.
Also, is there a simple tutorial on how to use log4net. Unless I'm misreading it, it appears to be a case of reading the source examples until you figure it out.
Is there any alternative to achieving serialising and deserialising of objects in Xamarin.iOS (Monotouch) using protobuf-net other than this method:
http://www.frictionpointstudios.com/blog/2011/3/31/using-protobuf-net-serialization-in-unity-iphone.html
Reading around some people claim they have managed it (without giving evidence), but my understanding is that [iOS JIT==NO] so does not quite make sense.
If the only possible solution is to fully AOT all relevant classes what might a suitable pre/post-build event command line be to perform this AOT for any relevant assemblies automatically?
I've heard a good number of people have success via that route, but I too can't give documented evidence.
That method is a bit out of date - I've simplified a few steps; there is a standalone pre-compile tool that should work:
create a project/assembly for the DTOs that you want to serialize that references the appropriate version of protobuf-net; presumably CoreOnly/ios, ideally with that dll set to copy into the output directory (it just makes life easier)
run
precompile "SomePath/YourDto.dll" -t:MySerializer -o:MySerializer.dll
(maybe with a mono before that to get mono to host the exe)
this should resolve the framework and compile a MySerializer.dll that you can reference, which involves zero JIT (MySerializer.dll will reference your dto dll and the version of protobuf-net that your dto dll referenced)
now reference your dto dll, the serializer dll, and the protobuf-net dll, and it should all work just by using new MySerializer().Serialize(...)
when you compile your solution, the projects should all AOT nicely
I'll be happy to offer guidance, but currently I am mac-less, so I can't check right now. If you get any problems let me know. If it can't resolve the framework, you can add -f:{path to the framework assemblies} to give it a clue.
I got protobuf-net 2 working on Xamarin-iOS by using the netstandard1.0 dll. You can get this dll by extracting the nuget package. No changes were needed.
What is the difference between native only, managed only, script only and mixed (managed and native) debugger types? They can be found in a project's properties page.
Different runtime environments have different debuggers. You are giving the choice of debugger you want to use to avoid starting one up that you'll never use and thus cutting the overhead. The debugger types are:
Managed: suitable for .NET code written in a managed language like C# or VB.NET
Native: suitable for code generated by the C or C++ compiler
Mixed: a choice you'll make when you need to debug .NET code that inter-operates with native code, common in C++/CLI projects or when you need to debug a pinvoke problem
Script: useful to debug scripting code, like Javascript, that runs in a browser
GPU: used to debug C++ AMP code that runs in a graphics card
Silverlight: used to debug Silverlight code that runs in a browser
T-SQL: used to debug stored procedures that run on SQL Server
Workflow: used to debug WF workflows
I am experimenting with ServiceStack's JSON engine. I grabbed the MonoTouch binary build, v2.20. Works fine from simulator, but from the iOS device (iPad2, iOS5) I get an exception thrown by the type initializer for JsonWriter (and not much other than that). I am using MonoTouch 5, MonoDevelop 2.8.1, and targeting iOS 5. I have disabled library linking because I am getting an error when enabled.
I created a sample and uploaded to https://github.com/t9mike/ServiceStack-JSON1.
I'm trying to determine whether the issue is my compilation options, Service Stack, or MonoTouch. Thanks in advance.
A quick partial answer that might help:
I have disabled library linking because I am getting an error when enabled.
The current (5.0) managed linker can eliminate some unused (from a static analysis point of view) code from your application. This generally occurs when using Link all option, i.e. where user code gets processed by the linker.
One alternative is using the Link SDK assemblies only that won't touch the user code (only the code shipped with MonoTouch itself will be processed by the linker).
Another alternative is adding [Preserve] attributes on your code to ensure the serializer requirements are still met after the linker has processed your code. More information about the linker and [Preserve] attributes can be found here.
The next (5.2) release of MonoTouch will include a bit more sophisticated step in the linker to ensure the basic XML serialization and DataContract requirements are not broken. Not sure if this will solve this specific case (ServiceStack JSON) but I'll have a look into it.
As for the rest of your question I'll try to build this myself and duplicate your issue.
I ended up grabbing the ServiceStack.Text sources from GitHub, version 3.0.3. I created a new MonoTouch library project. I had to tweak ServiceStack.Text/JsConfig.cs slightly to conditionalize away the System.Drawing.Color bits. I'll send a patch and MT csproj to the authors.
After using this new assembly, my sample MT app ran fine on the device. I have updated my sample at https://github.com/t9mike/ServiceStack-JSON1 with the new ServiceStack.Text dll.