为什么我生成后XCOPY总是复制previous版本(或挂起)? [英] why does my post-build xcopy always copy the previous version (or hang)?

查看:542
本文介绍了为什么我生成后XCOPY总是复制previous版本(或挂起)?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有创造的DLL解决方案和生成后XCOPY是将它们复制到另一个解决方案消耗他们的目标文件夹。我注意到,所有的似乎是很好,但实际上XCOPY总是复制previous版本,而不是刚建成之一。
这是个案的 A

I have a solution which creates DLLs and a post-build xcopy that copies them to a target folder where another solution consumes them. I have noticed that all seems to be well but in fact the xcopy always copies the previous version instead of the freshly built one. This is Case A.

更加古怪(但可能相关的):当我切换到一个批处理文件来完成构建挂XCOPY。 ()最后,如果我在批处理文件中使用一个简单的复制命令构建成功,但同样,错误的版本被复制。 ( C

Even weirder (but possibly related): when I switched to a batch file to do the xcopy the build hangs. (B) And, finally, if I use a simple copy command in the batch file the build is successful, but again, the wrong version gets copied. (C)

下面是拼图的碎片:

案例的 A 直接在生成后:

xcopy "$(ProjectDir)bin\Debug\PIC_TextBrowser.dll" "$(SolutionDir)..\ToolBox\ToolBox\bin\Debug\" /Y /I

案例的,一个批处理文件xcopy.bat 拨打从生成后ED:

Case B, a batchfile xcopy.bat call ed from the post-build:

xcopy "PIC_TextBrowser.dll" "D:\P\C#13\ToolBox\ToolBox\ToolBox\bin\Debug\" /Y /I

案例 C ,一个批处理文件xcopy.bat 拨打从生成后ED:

Case C, a batchfile xcopy.bat call ed from the post-build:

copy "PIC_TextBrowser.dll" "D:\P\C#13\ToolBox\ToolBox\ToolBox\bin\Debug\" /Y 

在.csproj的文件看起来像这样的目标:

The targets in the .csproj file look like this:

  <Target Name="BuildPlugins">
    <CSC Sources="PI_base.cs;PIC_TextBrowser.cs" TargetType="library" OutputAssembly="$(OutputPath)PIC_TextBrowser.dll" EmitDebugInformation="true" />
  </Target>
  <Target Name="AfterBuild" DependsOnTargets="BuildPlugins">
  </Target>
  <PropertyGroup>
    <PostBuildEvent>call xcopy.bat
</PostBuildEvent>

貌似生成后事件并不像的的',因为我以为。任何想法,比其他一起生活呢??

Looks like the post-build event is not quite as 'post' as I thought. Any ideas, other than to live with it??

推荐答案

这是在VS防爆preSS的错误2012年和2013年的(见下面编辑)

It's a bug in VS Express 2012 and 2013. (see Edit below)

OK,你不相信它,我也不,所以我们都在良好的公司。

OK, you don't believe it and neither do I, so we're all in good company..

但是,你还能怎么解释这些结果:

But how else can you explain these findings:

我已经写了两个小工具,从内置的文件中提取提取时间毫秒,也从当时的postbuild事件的开始和结束。这是必要的,因为这古怪情况下是秒级​​。

I have written two tiny tools to extract the extract time to milliseconds from the files that are built and also from the time the 'postbuild' event starts and ends. This was necessary, as this weirdness happens below the seconds level.

这些工具基本上都是单行,控制台机应用(timeMS)在批处理文件中使用,简单地做:

The tools are basically one liners, a console appliction (timeMS) to be used in the batch file, that simply does:

    Console.WriteLine(DateTime.Now.ToString("HH:mm:ss:fff"));

和一个WinForms程序,为每个文件拖放到它:

and a winforms program that for each file dropped onto it does:

tb_fileData.Text += file +  "\t" +   
   File.GetLastWriteTime(file).ToString("HH:mm:ss:fff") + "\r\n";

不是很大空间的错误为止。 (OK,著名的遗言之一,我承认..)

Not a lot of room for errors so far. (OK, one of the famous last words, I grant..)

然后我修改被调用的批处理文件生成后是这样的:

Then I modified the batch file that gets called in the post-build like this:

echo post-build starts > time.txt
timeMS.exe >> time.txt
xcopy "PIC_Clock.dll" "D:\P\C#13\ToolBox\ToolBox\ToolBox\bin\Debug\" /Y /I
echo post-build ends  >> time.txt
timeMS.exe >> time.txt

和这里的结果:

D:\P\C#13\ToolBox\PIClasses\PIClasses\bin\Debug\PIC_Clock.dll   17:25:56:132
D:\P\C#13\ToolBox\ToolBox\ToolBox\bin\Debug\PIC_Clock.dll       17:21:30:778

post-build starts 
17:25:55:929
post-build ends  
17:25:55:960

第一个文件是新的版本,这是没有做过/复制完成之前释放到文件系统;这样的过程中,始终XCOPY复制旧的版本,这是一个在第二行,建有几分钟前..

The first file is the new build, which is not done/released to the file system before the copying is done; so of course, the xcopy always copies the old version, which is the one in the second line, built a few minutes earlier..

再次测试了我这十几倍,既有设置:与SUCESSFUL构建之后'时,生成刷新项目输出(或任何英文版本称之为..)

Again, I tested this about a dozen times, with both settings: 'After sucessful build' and 'When build refreshes the project output' (or whatever the English version calls it..)

因此​​,无论它是一个错误或功能,但在任何情况下,我不认为我很明白。

So either it's a bug or a feature, but in any case I don't think I quite understand..

修改

OK,大概不会的真正的错误;这里是帮我摆脱困境:该文件的csproj提供了更多的 possibilties 比在属性页选项生成的事件。在这里,您可以更改目标名称来自= AfterBuild AfterCompile 你瞧,现在新版本被复制。嗯,我是独着这一切???

OK, probably not really a bug; here is what helped me out: the csproj file offers more possibilties than the options in the property page for build events. Here you can change the Target Name= from "AfterBuild" to "AfterCompile" and lo and behold, now the new version gets copied. Hm, am I alone with all this???

这是现在的csproj的样子:

This is how the csproj looks now:

  <Target Name="BuildPlugins">
    <CSC Sources="PIC_Clock.cs" TargetType="library" OutputAssembly="$(OutputPath)PIC_Clock.dll" EmitDebugInformation="true" />
  </Target>
  <Target Name="AfterCompile" DependsOnTargets="BuildPlugins">
  </Target>
  <PropertyGroup>
    <PostBuildEvent>x_copy.bat
</PostBuildEvent>

这篇关于为什么我生成后XCOPY总是复制previous版本(或挂起)?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆