UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
 
   Reply to this topicStart new topic
> Decomplie Tools, Any Versions    
 
   
JonSmith
post Jan 13 2020, 07:58 AM
Post#1


UtterAccess VIP
Posts: 4,064
Joined: 19-October 10



Hi guys,

So I know this isn't related to the usual stuff we talk about here, but Jack indicated in the UA 2020 plan that maybe we should expand abit and muscle in on some of Stack Overflows audience tongue.gif

What I am looking for is a tool I can automate that will decompile .net assemblies (mostly .dll files built in C#).

The use case is we have 'packages' containing software robots to do certain tasks and the libraries in them change from version to version. Its been very tricky to get details of all the changes for all the libraries before we push them into production (yes we have a source code repository and version control).
Right now the best manual way I have found is a combination of a library inspector tool called Dot Peek that can decompile the code and export it back into a Visual Studio project and then running a text comparison tool on the output.
Problem is I cannot seem to find a way to interact with Dot Peek programattically so I'm looking for alternatives.
Go to the top of the page
 
jleach
post Jan 13 2020, 10:53 AM
Post#2


UtterAccess Administrator
Posts: 10,366
Joined: 7-December 09
From: St. Augustine, FL


Hi Jon - not 100% sure it fits your required use case, but Scott Hanselman wrote about a few tools to do this aside from dotPeek (although I'm surprised JetBrains doesn't offer commandline support for dotPeek - they're usually reasonable well featured).

https://www.hanselman.com/blog/WhatsBetterT...ileNETCode.aspx

Here's another: https://github.com/icsharpcode/ILSpy

Telerik has one as well, and they're generally pretty solid: https://github.com/telerik/justdecompileengine

(also, I moved this to the C# board)

--------------------
Jack D. Leach
Founder & CEO
Dymeng Services Inc.
Business Software Solutions
Go to the top of the page
 
JonSmith
post Jan 13 2020, 04:43 PM
Post#3


UtterAccess VIP
Posts: 4,064
Joined: 19-October 10



Awesome Jack. I'll check out those links tomorrow, they look promising.
Thanks for moving, I did look for a C# forum but must not have been thorough enough.

Agreed regarding JetBrains, perhaps its just really obscurely documented but I cannot find it. Especially considering its a standalone tool and not integrated into Visual Studio you'd think this would be a no brainer.
Go to the top of the page
 
jleach
post Jan 14 2020, 05:34 AM
Post#4


UtterAccess Administrator
Posts: 10,366
Joined: 7-December 09
From: St. Augustine, FL


I'd be interested to learn more about what you're doing - some examples of why you're decompiling and reconstructing, etc.

Do you/your team own the files you're decompiling? (e.g., do they exist in a repo you have control of?). Seems like something that might be better handled through some sort of automated build tool, or perhaps adding a version/attachment interface to the target dlls (then maybe hosting on a local nuget repo for easy consumption and dependency management?)

Just curious if there's a better way in general, but not quite sure what it is you're actually working with.

--------------------
Jack D. Leach
Founder & CEO
Dymeng Services Inc.
Business Software Solutions
Go to the top of the page
 
JonSmith
post Jan 14 2020, 06:54 AM
Post#5


UtterAccess VIP
Posts: 4,064
Joined: 19-October 10



QUOTE
Just curious if there's a better way in general, but not quite sure what it is you're actually working with.


There is most certainly much much better ways. Sadly we have blocking issues in our team, namely an architect, who is vetoing things like using nuget packages.
This is all related to software robotics.
The result is we have, for example, a project for an application, say SAP (made by us), then another project for a process that uses SAP. This is an oversimplification of the simplest process we have. Its only easy for us to use our source control logs to check the changes for the process version, to check the SAPapplication.dll version changes we first need to determine what version it is now and what version it was in the last build uploaded to our prod environment.
When you have a package that contains one process and 4-5 libraries maintained by us elsewhere in our repository with an independent version number to tracking becomes a nightmare.

So what I do instead is say I dont care what versions my repository has as I dont have the time to cross check it all. I take the package on prod and compare the newest package, if you decomplie the dll's back into source code you end up with two folders full of the various projects and files which can then be checked in a simple diff check in one big batch. So its a one size fits all approach to any of our setups.

Its a total workaround but sadly I have to be pragmatic, we aren't allowed to use branches either due to architect veto again so this isnt an isolated example. I just do the best I can to make my life as easy as possible.
Go to the top of the page
 


Custom Search


RSSSearch   Top   Lo-Fi    19th January 2020 - 07:38 AM