保护Excel工作簿中的代码？ [英] Protecting Code in an Excel Workbook?
问题描述
这些项目中的代码有多受保护？在C＃中反思相同的问题仍然适用于这些工作簿项目？如果是这样，这些类型的工作簿是否有混淆工具？
要添加到这个问题 - 什么是好的'VBA？如果我们要去VBA路线，有没有办法保护这个代码？
正如其他答案所建议的，VBA Excel 2003（.xls）中的安全性有缺陷;一个密码只是有点烦恼，最常见的不是为开发者本人。即使VBA在Excel 2007+（.xlsx）中的安全性要好得多，更不用说几个世纪以来没有看到改进的VBA IDE（尽管没有这样真正的使用正确的VBE加载项... ）。
解决方案可能是将您的VSTO项目调用的单独库中的敏感代码写入;而不是复杂的公式，您可以公开显示为黑盒子（即公式功能的抽象）的函数;如果没有源代码，那么它的实现方式是不可用的），而没有dll的工作簿无法计算（在$ {code> #NAME？全部）
例如，不是 =某些专有的公式返回Smurf ，用户将看到 = Smurf（SomeTableColumnName，SomeRangeName，SomeRangeReference，SomeCellReference）。当然，这是以性能为代价的，所以我只会为那些 重要的东西保护。
我认为一个用户设法从这样的图书馆提取专有的公式，值得离开他们 - 在那个和Alt + F11之间，有一个步骤;专有代码与任何其他.net程序集一样保护。
更新
仍然没有使用任何第三方库，如果专有代码不需要需要 Excel互操作性，一个更好的解决方案可能是创建函数在VBA中（即在Excel中保留Excel Interop 部分），只传递原始类型（VBA Integer => .net Int16 ; VBA Long => .net Int32 ，字符串等。）到COM可见库，甚至不需要使用Excel互操作;它将是COM互操作而不是Excel互操作，并且性能命中将显着降低，尽管仍然存在（它仍然是.net托管代码说话到非托管COM）。
VBA代码的职责是读取和写入工作表，COM可见库的作用是通过VBA代码传递的值实现计算;当然，VBA代码可以方便地访问用户（Alt + F11），但是他们又无法访问实际的计算实现。然后VBA代码可以受密码保护，没有DLL的计算结果将是 0 或 #VALUE！，取决于VBA代码的实现方式。
关键是将Excel专用于Excel 并拥有。网络库可以在没有引用Excel互操作程序集的情况下拾取它 - 例如，VBA函数将获取单元格引用，获取其值（可能验证它）并将其传递给.net程序集，这将返回另一个基本类型VBA将返回到Excel。
另一个好处是，具有专有计算的库代码可以重用，如果您曾经将Excel工作簿转换为一个Web应用程序。
I want to produce an Excel workbook that will contain proprietary formulas and other intellectual property. I will most likely produce this workbook in Visual Studio 2010 with C#.
How protected is the code within these projects? Do the same problems with reflection in C# still apply to these workbook projects? If so, are there obfuscation tools specifically for these types of workbooks?
To add to this question - what about good 'ole VBA? Is there a way to protect that code too if we were to go the VBA route?
As other answers have suggested, VBA security in Excel 2003 (.xls) is flawed; a password is only a little annoyance, most often than not for the developper himself. IMHO you're absolutely better off with VSTO, even if VBA security in Excel 2007+ (.xlsx) is much better, not to mention the VBA IDE which hasn't seen improvements in centuries (although no so true with the right VBE add-in...).
A solution could be to write the sensible code in a separate library which your VSTO project calls; instead of intricate formulas you could expose functions which would appear as "black boxes" (i.e. an abstraction of the formula's functionality); how it's implemented is just not available to anyone without the source code), and without the dll the workbook couldn't be calculated (would be #NAME? all over the place).
For example, instead of =some proprietary formula returning a Smurf, users would see =Smurf(SomeTableColumnName, SomeRangeName, SomeRangeReference, SomeCellReference). Of course this comes at a performance cost, so I would only do this for stuff that's really important to protect.
I think a user that manages to extract the proprietary formulas from such an on-the-side library, deserves to leave with them - between that and Alt+F11, there's quite a step; the proprietary code is as "protected" as any other .net assembly is.
UPDATE
Still without using any 3rd-party libraries, if the proprietary code does not need Excel interoperability, a perhaps better solution could be to create the function in VBA (i.e. leave the Excel interop part within Excel) and only pass primitive types (VBA Integer => .net Int16; VBA Long => .net Int32, strings, etc.) to a COM-visible library which doesn't even need to use Excel interop; it will be COM interop instead of Excel interop and the performance hit would be significantly reduced, though still present (it remains .net managed code "talking" to unmanaged COM).
The VBA code's responsibility would be to read and write to/from the worksheets, and the COM-visible library's role would be to implement the calculations to be made out of the values passed by the VBA code; of course the VBA code would be easily accessible to the user (Alt+F11), but again they couldn't access the actual calculation implementation. And then the VBA code could be password-protected, and the calculation results without the DLL would be either 0's or #VALUE!, depending on how the VBA code is implemented.
The key is to leave Excel-specifics in Excel and have the .net library pick up where it can without referencing Excel interop assemblies - for example, the VBA function would take a cell reference, grab its value (perhaps validate it) and pass it to the .net assembly, which would return another primitive type that VBA would return to Excel.
Another plus is that the library code with the proprietary calculations could be reused, if you ever were to "convert" the Excel workbook into, say, a Web application.
这篇关于保护Excel工作簿中的代码？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
