The basic issue is that when I open the list of objects in justdecompile, most of them issue prompts like
Please specify System.Windows.Forms.1.0.5000.0 location
I would guess that if I was decompiliing an exe that was created with a .net that I currently have installed on this machine (which has vs 2008-2010-2012), I would not be seeing these prompts. How do I resolve this issue? Is it enough to install the .net 1.1 framework? Or do I need an earlier copy of vs installed?
JustDecompile looks great, thank you telerik.
8 Answers, 1 is accepted
Then I went to create a project. I found vb was not an option. Boo.
So I switched it to cs and created a project. The project does not open, the error says
Unable to read the project file 'blah.cjproj'. The blah file is not a valid project file. The project file is missing the 'VisualStudioProject' section.
Does anyone know if I fix that, will it be ok? Or is justdecompile not so great after all?
Thank you for using JustDecompile. The issue you've stumbled upon in the first place can be handled in several ways. The first, and probably easiest, is installing the framework the assembly was first built against (in your case .NET 1.1) on your machine. As installing VS2003 installs the framework DLLs, as well as the IDE, it has effectively the same result regarding JustDecompile. Another thing you can do is have the .NET 1.1 files somewhere on your machine and place the assembly you want to decompile in the same folder as the DLLs it references. This way JustDecompile will be able to locate them, even if you haven't installed the framework. This will work for locating any referenced assembly, not only framework ones.
Now about the project generation. Creating a project in VB is one of the high-priority features we're working on right now. Our goal is to be able to deliver this in the next few months, so stay tuned for updates. However, opening the project in VS2003 is something we never considered. The "Unable to read project file..." error says that the .csproj file isn't in the format supported by VS2003. JustDecompile produces .csproj files compatible with VS2010 and later so I suggest you try and open the project in a newer version of VisualStudio. You will not be able to compile your project, however, as VS2008 and later don't support targeting .NET 1.0 and 1.1. As your project will probably be converted to target .NET 2.0 or later, there might be some errors in the decompiled code, introduced by the breaking changes between the framework versions (most will be of the type "Type X doesn't exist in the namespace N" or "No such method M that takes arguments ARGS", etc.). You might have to play around with the references in your project to fix these up.
I hope I managed to answer your questions. However, don't hesitate to write us if you want to know anything more about JustDecompile.
I decompile the exe on a windows 2003 vm that has vs 2003 installed. JustDecompile does not ask for missing references, it seems ok.
I use JD to create a new project. It does that. I move the project folder to my main workstation that has vs2010 on it. The project does open, but with 38,000 errors.
I think the exe may be .net 1, as mscorlib version=1.0.5000.0?
According to you, JustDecompile has built the project in vs 2010 format. There was no sln file, only a csproj file, until I saved the solution.
I am not clear if JD simply organizes the project it creates in vs2010 format, or if it actually targets .net 4.0? The project says it targets .net 4.0, but it's failing massively.
What steps can I take to resolve this?
One thing I can suggest is that you copy the .NET 1 DLLs form the virtual machine to the copied project in your workstation and re-target the references to the system DLLs. The way Visual studio resolves, for instance the reference to System.Windows.Forms, is by seeing what assembly you want to reference by name, and if it's a framework one, target the one in the currently targeted platform. What this means is, JustDecompile decompiled your assembly targeting System.Windows.Forms v1.0.5000.0, but your VS targets System.Windows.Forms v188.8.131.52. By copying the assembly somewhere on your machine (for instance in a "References" subfolder of the created project) you can tell VS "Hey, target this particular file". Sadly, this will not work for mscorlib, as it is inferred by default by VS.
JustDecompile can do all this for you, if you have the files, but do NOT have the framework installed. As an example, if you simply copy-paste the .NET 1.0/1.1 framework folder anywhere on your workstation (for instance in the Desktop) and place the dll you try to decompile inside, all the "Use this file" referencing will be done automatically.
About the project format: in this case JustDecompile just organizes the project in the VS2010 format. VS infers it should target .NET 4.0, since this is the default value. If the projects were for .NET 2.0/3.5, JD would've indicated this in the .csproj, but since VS doesn't support older versions, we prefer not to make the project unopenable.
The number 38,000 seems really big for an average DLL. If retargeting the references doesn't lower this number significantly, please don't hesitate to write us back.
The overwhelming issue seems to be that as the decompiler composes the code, many of the function references are ambiguous.
The original developer created a lot of classes with the same name. For example
Each of those class files contain various functions of course. In the form code, those functions, as rendered by the decompiler, come out like
But vs won't build the project, it reports many errors like this:
Error 302 'mCommon' is ambiguous, imported from the namespaces or types 'MyApp.App, MyApp.SQL'
fnOne and fnTwo are in different classes. It would compile if it was like this:
To sort this out manually would be really tough since there are many many calls to the functions in the various mCommon classes.
Is there any way to coax vs into resolving these references automatically? It would seem to be a tough call since some of the classes might contain functions etc which have identical signatures. Or is there a way to have JD sort these references out better?
Thanks for pointing us these issues.
From what I can see there might be two separate problems. The first one is JustDecompile produces files with names starting with ".". The second one is obviously about type names collision. We have put a lot of effort into handling correctly in both situations. Rather unfortunately, we cannot reproduce this kind of behavior at our side. Would it be possible that you zip the assembly where that happens and send it over to me?
My e-mail address is MomchilI . Ivanov at telerik . com (spaces removed, at == @).
Thanks a bunch in advance.
I am not able to share the exe, unfortunately.
Re the file names starting with ".", that's a an error on my part (sorry!).
Not sure what options I have left.
Could you please tell us what are the two classes exact names and namespaces? Actually, could you paste just the IL code for the both the classes declarations? For example, for System.Array class that is:
.class public auto ansi abstract serializable beforefieldinit System.Array
Also, could you clarify what kind of methods fnOne and fnTwo are? I.e. static methods?