我最近一直在做的事情是在我的代码解决方案中添加一个额外的项目,并以编程方式在其中进行构建。该项目最后构建,然后自行启动。
我能做的很酷的事情就是运行我创建的ILMerge自动化类来自动执行合并,如果我只是给它一个项目文件夹,在我的程序集信息中增加版本号,在我想要的地方复制文件等等等。在我看来,这里的可能性是无穷无尽的。我正在使用的一个示例 - 我有一个相当大的框架库,我将使用我们的一个应用程序进行部署,但我们不希望单独包含所有dll(有像20)。此外,我不需要库中的每个类用于此应用程序,因此将其修剪下来是有意义的。在图书馆的后期制作项目中,我正在这样做......
outputDirectory = new DirectoryInfo(@"...postbuildmerges\output");
solutionDirectory = new DirectoryInfo(@"...mainSolutionDirectory");
#region Web Lib
List<string> webLibraryNames = new List<string>
{
"Lib.Configuration",
"Lib.Web",
"Lib.Data",
"Lib.Utilities",
"Lib.Threading"
};
List<string> AllNeededAssemblies = new List<string>();
webLibraryNames.ForEach((libname) =>
{
foreach (string assembly in GetLibraryAssemblies(libname))
if (AllNeededAssemblies.Exists((assemblyName) => Path.GetFileName(assemblyName) == Path.GetFileName(assembly)) == false)
AllNeededAssemblies.Add(assembly);
});
SharpMergeAutomator.Merge(
@"...path to primary assembly...",
AllNeededAssemblies.ToArray(),
"...desired output file...",
//merges xml documentation
true);
#endregion
这个后期构建项目是一个好方法吗?这是不必要的复杂吗?有没有更好的办法?人们通常会这样做吗?
答案 0 :(得分:2)
MSBuild是构建的脚本语言,它可以轻松地迭代文件夹树,对任何你喜欢的文件过滤器提交动作等等。你应该在我想要的MSBuild脚本中做这些事情,因为当一个新的.net出来了,它很可能仍然是构建的脚本语言,你不必更改构建脚本以使用新的.net,而你在代码中做的构建工作就越多,这就是你的代码。我必须重写为文件和事情已经移动。此外,使用MSBuild,您可以默认记录日志以及大量内置内容。
此外,还有许多社区任务可以轻松用于ILMerge之类的事情: http://code.google.com/p/ilmerge-tasks/wiki/HowToUse