ASP.NET MVC Dotfuscator 问题
我正在尝试使用 Dotfuscator (CE) 来帮助保护我们的 ASP.NET MVC .ddl。它是一个将分发给客户的网络应用程序，我们需要一种方法来保护我们的知识产权。
问题是，一旦完成，它似乎就会破坏应用程序。到目前为止，我只在我的控制器名称空间上禁用了重命名，但现在出现了空引用异常。
有人让 Dotfuscator 与 ASP.NET MVC DLL 一起使用吗？ Google 不提供任何可能的博客文章或信息。
谢谢。
其他详细信息：
Visual Studio 2008 Professional、
Windows Vista Business x64、
注册了我的 Dotfuscator，但没有收到包含升级的 CE 版本的下载链接的电子邮件。
或者有人可以推荐一个相对便宜且可以正常工作的工具吗？
I am trying to use Dotfuscator (CE) to help protect our ASP.NET MVC .ddl. Its a web application that will be distributed to clients and we need a way to protect our IP.
The problem is that it appears to break the application once completed. I've only got so far with disabling renaming on my Controllers namespace but I'm get null reference exceptions now.
Has anyone got Dotfuscator working with ASP.NET MVC DLL's? Google provides no possible blog posts or information.
Thanks.
Other details:
Visual Studio 2008 Professional,
Windows Vista Business x64,
Registered my Dotfuscator but not had an email with a download link for the upgraded CE edition.
Or can anyone suggest a relatively cheap tool that would work properly?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为这行不通，因为 ASP.NET MVC 非常依赖反射。
我已经使用 SmartAssembly 及其具有的控制流混淆选项成功混淆了 ASP.NET MVC 应用程序。这不会更改类成员的名称，而是将方法中的代码更改为意大利面条式代码。
I don't think that will work because ASP.NET MVC relies so heavily on reflection.
I have successfully obfuscated an ASP.NET MVC application using SmartAssembly and the control-flow-obfuscation option it has. That does't change the name of your class members but instead changes the code in your methods into spaghetti code.
ASP确实如此。 NET MVC 严重依赖反射，因此您不能混淆将反射的类型或属性。然而，我认为无论如何都没有必要混淆大部分内容。您的控制器名称和操作名称已经公开，因为它们出现在 URI 中。您的演示模型本质上也是公开的，因为它们应该像您的视图一样设计，并且最终用户可以看到您的视图。
您的控制器应该非常轻量级，并且只需将存储库中的对象绑定到您的表示模型即可。因此，这里几乎没有什么知识产权可以隐藏。
您实际上想要混淆的代码可能是您的业务逻辑，它可以很容易地存在于单独的程序集中。因此，我的建议是，不要一个接一个地尝试混淆器，并尝试找到一个似乎可以工作的混淆器（除了您错过的那些错误，但您的用户稍后会发现），而是分区混淆的代码很重要，并且不太依赖于反射。
It is true that ASP. NET MVC relies heavily on reflection, and therefore you cannot obfuscate the type or properties which will be reflected. However, I would argue that there is no need to obfuscate most of this stuff anyway. Your controller names and action names are already public, since they appear in URIs. Your presentation models are essentially public as well, since they should be designed like your view, and since end-users can see your view.
Your controllers should be very lightweight, and simply bind objects from a repository to your presentation models. So there is little intellectual property to hide here.
The code you would actually want to obfuscate would presumably be your business logic, which can very easily live in a separate assembly. So my suggestion would be that rather than trying obfuscator after obfuscator, and trying to find one which seems to work (except for those bugs which you miss, but your users find later on), that you instead partition the code which is important to obfuscate and his not so dependent on reflection.