ILSpy
ILSpy copied to clipboard
icsharpcode
Detect default namespace when exporting an assembly as csproj
the AssemblyInfo info in the decompiled app contains these attrs:
[assembly: Debuggable(DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints)]
[Assembly: CompilationRelaxations(8)]
[Assembly: RuntimeCompatibility(WrapNonExceptionThrows:=True)]
Which cause troubles when debugging the app as if the app is in Release / optimized mode. Either remove them, or show us a hint to erase them. I lost a lot of time, and didn't get the reason until I asked folks in Roslyn .
I de-compiled SB.exe , which is the IDE for the Small Basic programming language. With these attrs, the project is optimized, although I am using it in Debug Mode, so Putting Breaks points sometimes fails, and some breakpoints are ignored, making tracing and debugging nearly impossible.
Yes, but, are you recompiling the assembly before debugging? ILSpy does not offer any binary editing capabilities... hiding attributes in the ILSpy output won't make them go away in the assembly... so, it would be easier to understand why you are asking for this, if you described your use case in detail...
ILSpy saves the decompiled project. It can easily modify the file before saving it.
ILSpy can show a dialog to ask us before saving the project, if we want to comment out these attrs, and give info about what happens if not.
We had a bit of internal back-and-forth on this one. Current thinking: no, we expressly want to export the "original" (like with decompilation where we strive to get a near-identical version back), this "changing the code" should be a post-processing step after the export.
I think exported code should be optimized for Debugging, while it is expected that most decompiled assemblies are optimized for Release. Keeping this as it is will cause a lot of suffering fpr most of the users. I am using .NET wince day 1, and I never aware of such attrs, s, what about beginners? Besides, you have more things to optimize in the project file, such as removing path hints for .NET class lib, that can cause issues on win x64.
For documentation purposes, this attribute has come up earlier https://github.com/icsharpcode/ILSpy/issues/1422#issuecomment-464372115
Note that we actually already have such a transform for project decompilation: https://github.com/icsharpcode/ILSpy/blob/08de8416f5de0fdeb779ddd5c20d7a635608e75f/ICSharpCode.Decompiler/CSharp/Transforms/EscapeInvalidIdentifiers.cs#L81-L104
It seems that the pattern has changed and is no longer recognized properly, so yes, this is actually a bug. Sorry, for the inconvience...
@VBAndCs as this is now a bug, would you be able to provide an assembly were this bug is reproducible? I have tried with some assemblies, but cannot reproduce the bug.
If you do not want to share the assembly publicly, please send it to [email protected]. Thanks!
I am using ILSpy version 6.2.1.6137, but converted the project to VB.NET in a next step. And I checked again, and I got:
[assembly: Debuggable(DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints)]
[assembly: CompilationRelaxations(8)]
[assembly: RuntimeCompatibility(WrapNonExceptionThrows = true)]
I am decompiling Microsoft Small Basic. You can install it (only 7 mega): https://download.microsoft.com/download/3/6/8/3684D9A0-C25C-4F50-96E2-2BB1DFA146E7/SmallBasic.msi Try SB.exe or any dll in the installation folder.
Thanks.
Seems to work on my machine... not sure what's going on...
fyi, I am using ILSpy version 7.0.0.6295-preview2
Can you try the latest v7p2 compared to your currently installed v6.2.1?
I am using win7 x32. Does this matter?
No, that should not make a difference.
v7p2 works. Thanks.
But, as you thankfully kept the folder structure, you kept the root name space in this structure.
Microsoft.SmallBasic is the root name space in this case, and should not have folders "Microsoft\SmallBasic", and the Properties Folder should be combined with the Microsoft\SmallBasic\Properties folder.
Thanks.
Microsoft.SmallBasic is the root name space in this case, and should not have folders "Microsoft\SmallBasic", and the
PropertiesFolder should be combined with theMicrosoft\SmallBasic\Properties folder.
How should we detect the root namespace of the assembly? Would be nice, if you could suggest an algorithm for this.
How should we detect the root namespace of the assembly? Would be nice, if you could suggest an algorithm for this.
Let's talk about WPF as it has an indication:
1- look for any xaml file, say x.xaml (by the way, this v7p2 doesn't retrieve .xaml files! You should fix that.
2. look for the class with the same name X.cs.
3. Search for 'x.xaml", UriKind.Relative);'. This is where xaml file is loaded.
4. look for the path loded. For example: "/SB;component/mainwindow.xaml".
5. match component/mainwindow.xaml with the actual path of xaml file Microsoft\SmallBasic\mainwindow.xaml'. The componentpart here matchesMicrosoft\SmallBasic. This is the root namespace. 6. As a double check, be sure that there is no file umder the folder Microssoft' and it only contains folders. Suppose windows has folder 1 and SmallBasic folder. All folders will be in the root of the solution, except SmallBasic, which all contents will move out to the root of the solution.
(by the way, this v7p2 doesn't retrieve .xaml files! You should fix that.
I just tested this using PresentationFramework.Aero.dll, BAML files are correctly translated back to XAML.
@siegfriedpammer I tested using Small Basic (SB.EXE) and I see no xaml files.
The directory where xaml files are put is derived from the path given in the resource name.