vs2010运行C#程序报错：命令行或响应文件上不能有字符“□”--已解决

   先说结论：升级到vs2017（13和15可能可以但我没试），或者解除工作电脑对响应文件（.rsp）的加密（这个我也没试，理论可以）。

接手了公司的一个图形解释软件，说是一年没维护了。结果代码从svn搞下来，一运行就报错：

报错没有行号和列号。 查询后得知error CS2032和AL1066对应此错误，ALINK表示Assembly Linker，是.NET中负责链接程序集的（al.exe）。其中“□”是ASCII码中的0-31的控制字符（用Notepad++等工具可以显示这些控制字符）。又查了查响应文件是什么：

在 C# 和 .NET 编程中，响应文件（Response File）是一种包含命令行参数的文本文件，用于简化和管理复杂的编译或构建命令。响应文件通过在命令行工具（如 csc 编译器或 dotnet CLI）的命令行参数中使用 @filename 语法来引用。

随后又在生成解决方案的日志中找详细信息，得到：

（生成详细信息的方法：工具-选项-项目解决方案-生成并运行-项目生成输出详细级别->详细或诊断）

根据日志前文，显示编译完成，无错误，所以代码应该没问题，估计是链接有问题。根据报错内容找了命令行和响应文件，日志中使用的命令行没发现非法字符，命令行中没有显式调用响应文件（调用响应文件的格式是@filename），项目文件夹中也没有发现响应文件，那错误出在哪了？

于是我让ai写了一些简单的程序，通过vs命令行手动验证al.exe是否正常工作，没有发现问题。随后又用vs命令行执行了日志中的对应内容，也正常执行了。

虽然觉得问题不会出在响应文件上，我还是测试了响应文件。具体操作就是把本应写在命令行的指令写在一个文本文件里，后缀改为.rsp，然后在命令行中调用这个响应文件即可（如al @link.rsp）。没想到一测还真测出了问题：

成功复现了报错。 我立刻想到应该是工作电脑自动加密导致的，于是新建了空白的rsp文件（空白文本文件不会自动加密，修改后就会加密），使用命令行调用，未报错；修改后（打一个空格再删掉，保存），显示已加密，再调用，果然报错了。

大概推测了vs2010出现此错误的原因：vs在处理链接过程（Assembly Linker）时，把相关的命令行指令和参数写入了一个临时的响应文件，然后使用命令行调用了这个临时响应文件，调用结束就立刻删除了，所以查不到相关的响应文件。而这个临时响应文件在写入指令后就被自动加密了，导致调用时无法正常读出指令而产生了非法字符，进而出现了这个报错。

随后我联系了管理加密的部门，反馈了问题，希望能解除相关文件的加密。结果答复是除非十分必要否则不能解除，又告诉我这个软件之前公司在维护的时候没有出过我遇到的问题。最后帮我联系了之前负责这个软件的员工，告诉我他一直是使用vs2017调试的······

于是我下载了vs2017来调试程序，果然没报错，运行成功了。。。保险起见我用vs2017的命令行尝试运行指令al @link.rsp，还是一样报错。看来是vs2017内部运行的原理改变了，猜测是省略了写指令到响应文件然后调用的过程，而是直接在命令行里输入了指令。

-----------------------------------------分割线，2024.8.13更新--------------------------------------------------

最近一直在使用vs2017调试程序，今天突然想回头再用vs2010调试一下看看这个报错能不能有别的解决方法，结果竟然能畅通无阻地运行了，没有报错。。。估计是我在vs2017中的调试过程顺便把这个影响vs2010的bug给解决了？但是中间修改的部分太多，也不能确定哪个修改起了作用（汗）。感觉比较有可能的修改是：1.注册了一个程序需要的.ocx控件；2.删除了部分本地的dll引用又重新手动添加；3.或者是vs中关于链接的一些设置，但我不确定。

保险起见又用两种vs命令行测试了加密响应文件的调用，还是报错。排除了底层原理改变的原因，估计就是以上之一了。