2011年初开始做一个项目，开始体验使用微软网站发布工具来发布网站。在服务器端安装发布服务后，可以在Visual Studio界面中右键点击Web项目，再点发布，第一次填好发布设置，以后就可以实现一键发布，虽然还有不少高级功能没有用到，不过已经方便得不敢相信了。敏捷开发的一个要素不就是每日构建吗，开发过程中，每天下班前Check In代码（Visual Studio装了 Anksvn插件 )，再发布到服务器上，连一分钟都不用。
具体步骤这里不介绍了，大家有兴趣可以看下 Scott Guhire的博客 。顺便说一下，那个WebPlatform Installer要比我当时逐个网上搜索下载方便多了，却要你先安装.Net 2.0，明显无理要求嘛，我只装了.Net 4.0。只要把安装包文件提取出来，再改下其config文件让其兼容4.0就可以了。
按计划过年前，要发布Beta版本，几名领导会来观看演示。可就在演示前，出现了麻烦，站点怎么也部署不上去了。出现下面的错误：
折腾了一个多小时，终于想到之前发布都是成功的，可能因为在上线前一天，改了很多东西。于是我在给我帮忙的实习生电脑上试了下，上面的代码还是旧的，结果她那边可以发布成功。我拿到旧代码，在本机同样成功。其实本来直接将站点手工复制到服务器上也没什么大不了，但我这个人比较爱钻牛角尖，既然排除了的发布工具或服务器端突然秀逗的原因，那就只能是代码的原因。于是采用折半排除大法，排除一部分文件在项目外，再尝试发布。直到最后，才找到罪魁祸首－正是web.config文件。有点出乎意料，原以为这个文件不用编译，直接复制就可以。
原因也找到了，是前一天将web.config的<appsettings>加了许多项，很多项中含有转义字符如“><&”之类，删掉这些项就可以了，然后把web.config手工拷到服务器网站根目录下。
演示进行得比较顺利，领导们接着又提出了几项新功能。过年回来后，尽管忙得不可开交，而我还一直纠结着这个令人摸不着头脑的错误。
随着站点部署上线，开发告一段落，我终于腾出手来，想把这个问题搞个水落石出。
首先要找到Microsoft.Web.Publishing.Tasks这个程序集，和一般.Net Framework程序集的不同，它是在C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\Web目录下。根据错误信息，用Reflector翻出了ParameterizeTransformXml.Execute方法。
bool
flag =
true
;
IXmlTransformationLogger logger =
new
TaskTransformationLogger(
base
.Log,
this
.StackTrace);
XmlTransformation transformation =
null
;
XmlTransformableDocument xmlTarget =
null
;
try
{
logger.StartSection(SR.GetString(
"BUILDTASK_TransformXml_TransformationStart"
,
new object
[] {
this
.Source }),
new object
[0]);
xmlTarget = OpenSourceFile(
this
.Source,
this
.sourceIsFile);
logger.LogMessage(SR.GetString(
"BUILDTASK_TransformXml_TransformationApply"
,
new object
[] {
this
.Transform }),
new object
[0]);
transformation = OpenTransformFile(
this
.Transform,
this
.transformIsFile, logger);
this
.storageDictionary.TokenFormat =
this
.TokenFormat;
this
.storageDictionary.UseXpathToFormParameter =
this
.UseXpathToFormParameter;
transformation.AddTransformationService(
this
.storageDictionary.GetType(),
this
.storageDictionary);
flag = transformation.Apply(xmlTarget);
if
(flag)
{
logger.LogMessage(SR.GetString(
"BUILDTASK_TransformXml_TransformOutput"
,
new object
[] {
this
.Destination }),
new object
[0]);
this
.resultXml = SaveTransformedFile(xmlTarget,
this
.Destination,
this
.destinationIsFile);
}
}
catch
(
XmlException
exception)
{
Uri
uri =
new
Uri
(exception.SourceUri);
//错误抛出源
logger.LogError(uri.LocalPath, exception.LineNumber, exception.LinePosition, exception.Message,
new object
[0]);
flag =
false
;
}
一目了然，这个方法处理异常的代码出现了的逻辑问题。项目已经上线，我目的已不是让远程发布顺利完成，而是找到真正的错误原因。XmlException是从哪里抛出的呢？对于我这种只用IDE调试的菜鸟来说，有点麻烦。
马上想到的，是用一个程序加载此程序集，通过抛出异常的InnerException属性的堆栈，应该能找到异常源。问题是怎么启动这个程序集，我乡下人，怕黑不喜欢研究命令行。这里我找到一个不错的借口，即使找到异常源，也没法去调试（这不是.Net Framework一部分，没有源代码下载的）。
要想调试代码，还得求助于Reflector。不过这个程序集估计有几万行代码，不能指望代码导出来，想把它改得编译通过有点悬。所以争取只导出最少的，与错误相关的代码。既要定位到异常源，还要获悉源方法的上下文变量。束手无策的看了两天源代码，终于决定从IL入手。在园子里，看过多位朋友写过如何改造VSPaste插件，既然同是.Net程序集，我应该也可以在ParameterizeTransformXml.Execute方法中塞一点东西，曝光其一些运行时的真相。
临渊羡鱼，不如退而结网。耐下性子，学了几天IL语法基础，练了几个示例，然后准备开刀了。由于reflector导出的IL也有问题，所以手术刀还是用ildasm工具，直接转储就可以了。会生成三个文件，扩展名为res和resources的两个不用管，只打开扩展名il的那个文件，有4兆多，所以还是用一个给力点的文本编辑器吧，我用的是NotePad++。
找到Execute方法，我选了几个可能的关键点，分别插入了一段IL代码，来将下一个函数调用的参数值保存到日志文件中。代码可以先用C#写好，在Reflector中查看编译的程序集，把IL复制过去，再根据上下文修改下如何获取要保存的参数即可。比如这行代码：xmlTarget = OpenSourceFile( this .Source, this .sourceIsFile)，对应的IL是：
IL_0042: ldarg.0
IL_0043: call instance string Microsoft.Web.Publishing.Tasks.ParameterizeTransformXml::get_Source()
IL_0048: ldarg.0
IL_0049: ldfld bool Microsoft.Web.Publishing.Tasks.ParameterizeTransformXml::sourceIsFile
IL_004e: call class Microsoft.Web.Publishing.Tasks.XmlTransformableDocument Microsoft.Web.Publishing.Tasks.ParameterizeTransformXml::OpenSourceFile(string,bool)
在其前面插入:
ldstr "D:\\pub.log"
//
将字符串加载到栈上
ldarg.0
//
加载自己(this)的引用到栈上
call instance string Microsoft.Web.Publishing.Tasks.ParameterizeTransformXml::get_Source()
//读取属性到栈上
ldstr "[Source]\r\n"
call string [mscorlib]System.String::Concat(string, string)
//
将栈顶的两个字符串合并成一个（原来栈有三个变量，现为两个）
call void [mscorlib]System.IO.File::AppendAllText(string, string)
//记录日志，现在
栈被清空
ldstr "D:\\pub.log"
ldarg.0
ldfld bool Microsoft.Web.Publishing.Tasks.ParameterizeTransformXml::sourceIsFile
//读取字段
box bool
//装箱
ldstr "[sourceIsFile]\r\n"
call string [mscorlib]System.String::Concat(object, object)
call void [mscorlib]System.IO.File::AppendAllText(string, string)
小心冀冀花了半天，修改完保存，用ilasm命令进行编译，又修正一些错误，基本都复制多或少一块造成的。编译成功后，将原位置的Microsoft.Web.Publishing.Tasks.dll文件备份后替换掉，在Visual Studio中发布，却又报错了，说“签名不匹配”，无法加载dll。
赶紧又一顿搜索，将程序集IL中.hash语句删除，再编译，替换，重启VS，发布，果然成功了！还是显示原来的错误，不过刚才嵌入的IL代码，如同打入敌人堡垒内部的同志，通过log文件中，成功地送出了致命的情报。
运气非常好，因为日志文件中只多了两行，说明还就是OpenSourceFile方法出错了。Source属性正是网站项目web.config文件的绝对路径，sourceIsFile值为True。在Reflector中进入OpenSourceFile方法，更简单，只有聊聊几行：
private static
XmlTransformableDocument OpenSourceFile(
string
sourceFile,
bool
isSourceFile)
{
XmlTransformableDocument document2;
try
{
XmlTransformableDocument document =
new
XmlTransformableDocument
{
PreserveWhitespace =
true
};
if
(isSourceFile)
{
document.Load(sourceFile);
}
else
{
document.LoadXml(sourceFile);
}
document2 = document;
}
catch
(
XmlException
exception)
{
throw
exception;
}
catch
(
Exception
exception2)
{
throw new
Exception
(SR.GetString(
"BUILDTASK_TransformXml_SourceLoadFailed"
,
new object
[] { exception2.Message }), exception2);
}
return
document2;
}
追踪到了XmlTransformableDocument的Load方法，目标精确已够，可以收网抓捕喽。接着可以建一个测试工程，就把这个类，以及与其相关的类代码，从Reflector中拷贝出来。看上去代码量也不少，不过有些比如说是用来写Xml，可以直接去掉。编译通过后，F5调试运行。终于，剥开重重迷雾后，这次看到异常的庐山真面目：XmlAttributePreservationDict类ReadPreservationInfo(string elementStartTag)方法抛出的XmlException-“ 有未闭合的字符串。 第 3 行，位置 47 。”
异常源找到了，接着要找原因。由于在调试状态，直接可以看到方法参数传进的值出了问题：虽然还不明白这个方法的目的，但elementStartTag不应该一个被截断的Xml节点字符串，而这个节点，正是那天导致发布失败的修改中加入的<appsettings>下的一个<add>节点。
仔细一看web.config文件中那个出错的节点，顿时让我气得不打一处来。原来对节点中属性中的Html标签中的一个尖括号，没有作转义处理。如今实习生实在是太靠不住了，差点被害死，我还特别强调过要小心转义符号啊。
当然，微软的代码肯定也有毛病，虽然转义特殊字符是标准做法，但尖括号是居于属性引号中，没理由不能正确解析。实际上，XmlTransformableDocument类的基类XmlDocument(大家都很熟悉了吧)，就不存在这种问题。
ReadPreservationInfo不是最终元凶，真正的元凶是调用它的幕后黑手，我揪它出来，给大家示众：
internal class
XmlAttributePreservationProvider
{
... ....
public
XmlAttributePreservationDict
GetDictAtPosition(
int
lineNumber,
int
linePosition)
{
if
(
this
.reader.ReadToPosition(lineNumber, linePosition))
{
int
num;
StringBuilder
builder =
new
StringBuilder
();
do
{
num =
this
.reader.Read();
builder.Append((
char
)num);
}
while
((num > 0) && (((
ushort
)num) != 0x3e));
if
(num > 0)
{
XmlAttributePreservationDict
dict =
new
XmlAttributePreservationDict
();
dict.ReadPreservationInfo(builder.ToString());
return
dict;
}
}
return null
;
}
}
这段代码不长，从个人角度说，我倾向于用一个全局的而不是局部的StringBuilder变量。导致本文问题出现在while语句的判断条件上，0x3e正是右尖括号的ASC码，以尖括号的出现作为节点结束标志，显然没有做到完全的严谨。不知道是微软的开发人员偷工减料，还是对XML的理解有点小偏差。其实，个人觉得发布网站有必重写这么多东西吗？
其实，在.Net Framework中对XML操作的核心类－XmlReader，几乎是滴水不漏。看上去命名空间一个是Microsoft，一个是System；我看到了一个是程序员，一个是大师，你感觉到了吗？
