看《修改代码的艺术》，这句话感触颇深。里面的场景就是我经常的行为，写着写着看到这里想重构一下，就顺手改起来，而把当前的事情抛在一边，特别是我又是个特别觉得编程就像写小说，是科学和艺术完美结合的人，看到一些代码味道不好，就忍不住想改得漂亮些。其实很多东西自己也是有体会的，但平时的工作中总是不能自觉地主动地去做。比如“测试驱动开发”，知道是个好东西，但总是养不成先写测试的习惯。增加特性和重构的两顶帽子，也知道这样是最有效率的，但总是增加特性的时候经常顺手就重构一些代码。习惯很重要，好习惯需要自己主动地去培养。

虽然平时一直要求在工作时不要把文件都CheckOut出来，而是只CheckOut所需要修改的文件，并且要在修改后及时CheckIn。但有些开发人员仍不能很好执行。因此在人员离职时常常在SourceSafe下留下很多仍然CheckOut的文件，同时也不知道本地是否有已经修改的新版本。

因此，在离职时需要检查一下是否有其仍然CHECKOUT的内容。先使用SOURCESAFE Administrator来检查一下此用户在SourceSafe 中有CheckOut权限的目录,然后对每个目录分别使用: <server>\vss\win32\ss status ＄/proj -R -U -yuser,password

此命令会记录所有被CheckOut的文件，＄/proj表示从具体的某个proj目录开始， -R 表示递归检查子目录。-U 表示只显示指定用户CheckOut的文件，user和password需要替换成离职人员的信息。当然你也可以从＄/开始检查所有的目录，但对于没有权限的目录会提示”You do not have access rights to ＄/xxxx”.

如果有显示信息，则必须要求其将所有文件都CheckIn或者Undo CheckOut，最好先比较所有文件的差异，确认后再操作。

关键环节，是在Project Settings的Post-build step处加上一个自定义命令，当然这是针对VC IDE而言的：

＄(TargetPath)

＄(TargetPath)代表编译后生成的exe文件。有了这项设置，IDE的compiler就会在编译结束之后，即刻运行本测试程序。同时输出结果会在编译器窗口输出。

在主函数main()中需要加入：

// Change the default outputter to a compiler error format outputter
runner.setOutputter( new CompilerOutputter( &runner.result(), std::cerr ) );
（相应还需要#include <cppunit/CompilerOutputter.h> ）

这样做的目的，是使输出格式和编译器的输出兼容，这样在编译器输出窗口就可以双击错误文件名和行号的那一行直接定位到错误行了。

另外，对于在外面执行的情况，可以在Project Settings的Debug中设置执行目录（因为我希望测试数据在另外一个目录，而程序在这个目录下执行）。而使用Post-build的方法不能指定执行的当前目录（谁知道？），现在我的方法是在main()中直接用SetCurrentDirectory() 进行设置。

现在在我们公司rdserver的“每日构建”页面下增加了一个“立即构建”的按钮，按此按钮可以直接激活在rdserver上的FinalBuilder，自动对工程项目进行构建，而不需要等到半夜的重编，适应一些需要立即出结果的情况。由于重编需要比较长时间，因此在激活后就可以不管它，过一阵子（现在大概10分钟左右）再重新刷新。部分人员也可以通过Email得到构建完成的通知。

这里解释后台的一些情况。关于在ASP中如何在后台调用一个应用程序，高占勇提供了一个方法 “WScript.Shell”对象， 以及相应的Run(strCommand, [intWindowStyle], [bWaitOnReturn]) 方法：

Dim oShell
Set oShell = WScript.CreateObject (“WSCript.shell”)
oShell.run “cmd /K CD C:\ & Dir”
Set oShell = Nothing

我现在用的是ASP .NET with C#, 因此直接使用了Process组件：

private void Button1_Click(object sender, System.EventArgs e)
{
string exe = @”””C:\Program Files\FinalBuilder2\finalbuilder2.exe”””;
string param= @”/n /r /e /f “”D:\jtts-builder\jtts.fbz2″””;
Process.Start(exe, param);

Label2.Text = “每日构建已激活!\n请等待邮件通知或10分钟后重新刷新此页面！”;
}

exe为执行程序名，param为参数。Start是一个静态方法，因此不需要实例化一个Process组件。

FinalBuilder2的命令行参数： /n 不显示初始窗口， /r 自动执行后面所跟脚本， /e 执行完毕自动退出， /f 忽略错误。

到这一步都很简单，但是实际在运行时FinalBuilder并不能运行下去。主要原因在于jTTS4 Daily Builder的FinalBuilder脚本中使用了SourceSafe来访问我们的代码库，而VSS Server(\\myserver)上的vss共享目录是有用户访问权限限制的。而在Windows Server 2003, IIS6中，缺省时FinalBuilder是用NETWORK_SERVICE用户执行的，因而造成错误。

解决方法是让FinalBuilder以其它具有vss目录访问权限的用户执行，具体是通过修改IIS中DailyBuilder虚拟目录的”应用程序池”(Application Pool)来实现的。

下面的内容摘自：http://doc.4kiki.net/content/1/23/200505/01/d271a7fc84170273.html

Enabling ASP.NET to run as another user on Windows XP Professional
As an Administrator, edit the attributes of the file”%INSTALLROOT%\Config\machine.config” ‘on the processModel tag, as shown:

<processModel
enable=”true”
userName=”DOMAIN\username”
password=”MyPswd2″
…
/ >

Note %INSTALLROOT% is of the form D:\WINDOWS\Microsoft.NET\Framework\v1.0.3705
Enabling ASP.NET to run as another user on Windows Server 2003
With Windows Server 2003 and IIS 6, there is a new feature named application pools. Each pool can be configured to run as a different user, provided that user has membership in the IIS_WPG group. Virtual roots can be added to an application pool, and the debugger will then be able to attach to it if the pool is running as the same user that launched the debugger. This mechanism provides an easy way to set up an alternate execution environment, safely protect user credentials, and set up additional virtual roots.

Adding and Configuring an Application Pool
Run the Management Console compmgmt.msc as an administrative user.
Expand the Services and Applications node to display the Internet Information Services, and Application Pools nodes.
Right-click the Application Pools node, choose New, and then choose Application Pool.
Type the name for the Application Pool and click OK.
Right-click on the new Application Pool and choose Properties.
Under the Identity tab, choose the Configurable option.
In the corresponding boxes, enter the User name and Password that you will be running the debugger with and click OK.
Note This account must be a member of the IIS_WPG group and have the access permissions listed above in order to run ASP.NET applications.
Setting a Virtual Root to run in an Application Pool
Run the Management Console compmgmt.msc as an administrative user
Expand the Services and Applications node to display the Internet Information Services, Web Sites, and Default Web Site nodes.
Expand the Default Web Sites node to display all of the virtual roots available.
Right-click on the virtual root to configure and choose Properties.
On the Virtual Directory tab, change the Application Pool drop-down to select the application pool running with the appropriate user identity and click OK.