如何反编译ASP.NET/C#Web应用程序

如何反编译ASP.NET/C#Web应用程序,c#,asp.net,decompiling,C#,Asp.net,Decompiling,我刚刚继承了一个源代码早已丢失的web应用程序(最初编写于2010年,现已搁置)。应用程序有几个与应用程序本身相关的.dll程序集,例如“applicationCORE.dll”、“applicationBI.dll”、“applicationDATA.dll”和“application.dll” 我看到了,建议的工具(只是反编译)非常出色,为我反编译的第一个程序集创建了一个.sln和.csproj文件。我的问题是如何将通过反编译创建的各种项目与已编译的web应用程序文件(.aspx)合并。此外

我刚刚继承了一个源代码早已丢失的web应用程序(最初编写于2010年,现已搁置)。应用程序有几个与应用程序本身相关的.dll程序集,例如“applicationCORE.dll”、“applicationBI.dll”、“applicationDATA.dll”和“application.dll”

我看到了,建议的工具(只是反编译)非常出色,为我反编译的第一个程序集创建了一个.sln和.csproj文件。我的问题是如何将通过反编译创建的各种项目与已编译的web应用程序文件(.aspx)合并。此外,如何解析.aspx文件中的引用,即引用不再存在的代码隐藏文件,例如“default.aspx”引用“default.aspx.cs”,而反编译器创建“default.cs”文件重命名.cs文件更安全还是应该更新引用

最后,每个dll是否会在解决方案中显示为单独的项目


我意识到这可能会被视为一个重复的问题,但似乎没有在线资源指导开发人员完成整个过程。

按照David的建议,我成功地从反编译程序集运行了应用程序。下面是我让它工作的过程

  • 我已经使用反射器(在试用中)将各种程序集反编译成项目
  • 我在VisualStudio中创建了一个空白的Web表单应用程序
  • 我通过visual studio将
    .aspx
    页面从网站添加到项目中
  • 然后添加反编译的“application.dll”项目中的.cs文件(因为这是解决方案中的网站项目。必须重命名某些文件以匹配“.aspx.files”中的
    codebeard
    引用
  • 然后将每个附加项目(例如
    applicationCore.dll
    )添加到解决方案中
  • 每个项目的引用都需要更新,对新添加项目的引用必须添加到启动项目中
  • 由于该网站是很久以前建立的,因此出现了1000个语法错误。解决这些错误的最简单方法是使用记事本++和查找和替换。为了安全起见,我通过跟踪Visual Studio中的错误,而不是批处理查找和替换,逐个文件完成了此操作
  • 在尝试构建时,我注意到缺少所需程序集的错误,因此我将子项目的构建输出目录更改为web项目的
    bin
    文件夹
  • 我从原始网站的web.config添加了连接字符串和设置。我逐行添加,以确保没有破坏任何内容,以便跟踪每次添加的结果
  • 最后,我有一个成功的建设
  • 附加步骤 还有一些语法错误,我认为这是由于反编译过程造成的。需要添加一些外部引用,并且由于项目的使用年限而略有更改,例如
    asp:AjaxScriptControl
    更改为
    asp:ScriptControl
    (使用Nuget添加包后)。我还必须为该应用程序安装Crystal Reports,并且必须购买Telerik许可证,因为正在使用UI组件(尽管我会在使用该应用程序时考虑是否可以使用开放/本机替代方案)

    我已使用凭据登录(我必须设置正确的起始页)并尝试了一些基本的CRUD操作。有一些愚蠢的问题必须解决,例如,身份验证无法正常工作,如果访问受保护的页面,也没有重定向,但与我最初遇到的问题相比,这些问题相对较小


    我必须说的是,每个错误都是通过本网站上的问题和答案解决的!这些都是在不到6个小时内完成的。

    不确定“合并各个项目”是什么意思。至于文件名等框架约定,您可能必须手动更正所有这些。将足够复杂的应用程序反编译为可用的源代码是一个艰苦的过程,这是丢失源代码的代价。我怀疑每个DLL都会是它自己的项目,我无法想象有任何其他方法来构建它即使是原始源代码。抱歉,我的术语可能不正确,我指的是将web文件与不同的项目合并。从您的答复中,听起来我应该使用“application.dll”解决方案文件,手动更新引用,然后添加其他“.dll”文件生成的项目(反编译后)进入解决方案?我知道这很辛苦-在你看来,这是一条比重写看似复杂的应用程序更长的道路吗?我可能会采取创建应用程序/解决方案等的空壳的方法,作为一种“受控环境”然后手动将反编译的代码引入其中。至于什么是更长的路径,由您的组织来确定。他们希望这条路径通向何处?一个可能会工作一段时间的管道胶带解决方案?一个具有文档、可测试性和支持的企业应用程序?介于两者之间?很多都是内部的o该决定超出了实际编写的代码行。感谢您的建议,我认为该方法比我之前所想的更聪明。突然有压力要求将其作为概念证明来运行,因此在有足够的支持来重写之前,管道胶带方法可能是值得的。