cspack行为从不同的MSBuild [英] cspack behaviour differs from msbuild

问题描述

使用Visual Studio 2012，Azure的SDK 2.1，我试图找出创建的文件夹CSX在蔚蓝的模拟器中运行的最佳方式。我的理解是，CSX文件夹不会创建，直到我打包Azure项目。我可以从Visual Studio手动创建一个包，但是这不是一个自动构建的选项。另一种选择是创建一个使用的MSBuild命令行包。这似乎递给，因为它实际上将做构建一个耗费更多的时间不仅仅是重新包装有点重。

Using Visual Studio 2012, Azure SDK 2.1, I am trying to figure out the best way to create the csx folder for running in the azure emulator. My understanding is that the csx folder is not created until I package the Azure project. I can create a package manually from Visual Studio, but this is not an option for an automated build. The other option is to create the package using the msbuild command line. This seems a bit heavy handed as it will actually do a build which is more time consuming than just repackaging.

所以，我认为cspack可能是一个更轻量级的选择。然而，当我打电话cspack使用以下命令行：

So, I thought that cspack might be a more lightweight option. However, when I call cspack with the following command line:

cspack.exe ServiceDefinition.csdef中/ COPYONLY

cspack.exe ServiceDefinition.csdef /copyOnly

我得到的错误：需要指定角色MyProjWeb的虚拟路径网络/的物理目录

I get the error: Need to specify the physical directory for the virtual path 'Web/' of role MyProjWeb.

不过，使用时的MSBuild我不会做这样的事情。我读了一堆东西有关指定物理目录和部分，它可以造成混乱。所以，我想preFER不使用它，除非绝对必要的，特别是因为我不需要从建筑的MSBuild时注明。

But, I don't do anything like that when using msbuild. I have read a bunch of things about specifying the physical directory and some of the confusion that it can cause. So, I would prefer not to use it unless absolutely necessary, especially since I don't need to specify this when building from msbuild.

所以，我的主要问题是什么是的MSBuild这样做cspack没有做，我如何做同样的cspack？
我的另一个问题是，什么是产生在蔚蓝的模拟器测试CSX文件夹中的最简单的方法？

So, my main question is what is msbuild doing that cspack is not doing and how do I do the same with cspack? My other question is, what is the easiest way to generate the csx folder for testing in the azure emulator?

编辑 - 分辨率

我以为我会放下我怎么解决了这个位置的情况下，它可以帮助别人。大回答我的问题（感谢Chandermani和其他一些阅读）是CSPack与/ COPYONLY基本上是根据一定的规则看上XCOPY到一个文件夹结构。如果不使用/ COPYONLY它，然后也做花式拉链创建一个包。不抱怨，它是好的，它是简单的，但它是很好的在一开始就知道这一点。你可以用它为蔚蓝它不依赖于什么可以在Visual Studio中，例如建造任何包装一个PHP的网站。使用的MSBuild只有复制的好处是属于你的网站部署的一部分文件。

I thought that I would put down how I resolved this here in case it helps someone else. The big answer to my question (thanks to Chandermani and some other reading) is that CSPack with /copyOnly is basically a fancy xcopy to a folder structure according to some rules. If not using /copyOnly it then also does a fancy zip to create a package. Not complaining, it is fine that it is simple, but it is good to know this at the outset. You can use it for packaging anything for azure it is not tied to what can be built in Visual Studio, e.g. a PHP site. Using msbuild has the added benefit of only copying that files that are part of your web site deployment.

所以，我发现当我CSPack工作，并在MVC项目文件夹指出的是，它复制一切，包括源文件。这不是我想要的。我能找到解决的办法是先包，那么网站在打包文件指向CSPack。如果你这样做了这条路再<一个href=\"http://iainhunter.word$p$pss.com/2011/08/31/automating-azure-1-4-packaging-using-msbuild-and-cspack/\"相对=nofollow>这个链接是因为它描述它一步一步非常有价值的。

So, what I found when I got CSPack working and pointed at the mvc project folder is that it copied everything including source files. Which is not what I wanted. The solution that I could find is to first package the web site then point CSPack at the packaged files. If you do down this path then this link is very valuable as it describes it step by step.

那么，这是不是有在Web项目将文件打包，一个MSBuild后的步骤，然后后续工序的在我的Azure项目以cspack它还是在我的Azure项目创建一个MSBuild后步骤包（做cspack仅为包括我的网络部署文件的利益）。那么，它似乎简单，更容易出错，只是有一个职位一步，让的MSBuild做繁重。所以，在我的Azure项目后工序是一样的东西：

So, it was either having an msbuild post-step in the Web project to package the files and then a post-step in my Azure project to cspack it or to have an msbuild post-step in my azure project to create the package (do cspack with the benefit of only including my web deployment files). Well, it seemed simpler and less error prone to just to have the one post step and let msbuild do the heavy lifting. So, the post step in my azure project is something like:

"C:\Program Files\Microsoft SDKs\Windows Azure\Emulator\csrun.exe" /devfabric:shutdown > NUL
"C:\Program Files\Microsoft SDKs\Windows Azure\Emulator\csrun.exe" /devstore:shutdown > NUL
if $(ConfigurationName) == Debug set CONSTANTSPARAMETER=DEBUG
if $(ConfigurationName) == Release set CONSTANTSPARAMETER=
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe $(ProjectDir)$(ProjectFileName) /t:clean;publish /p:Configuration=$(ConfigurationName) /p:TargetProfile=cloud /p:OutputPath=bin\Cloud$(ConfigurationName) /p:VisualStudioVersion=11.0 /p:overwritereadonlyfiles=true /p:DefineConstants="%CONSTANTSPARAMETER%" /verbosity:minimal /p:PostBuildEvent=

前两行关闭的计算和存储模拟器。

The first two lines shut down the compute and storage emulator.

接下来的两行设置preprocessor常数。我发现，当使用的MSBuild建行＃如果DEBUG不再发生作用。我认为这是一个创建包时DEBUG被剥离的安全防护。我只使用由自动构建系统创建的软件包，因此它是安全的，我保持不变DEBUG

The next two lines set the preprocessor constants. I found that #if DEBUG was no longer taking effect when built using the msbuild line. I think that this is safety protection that DEBUG is stripped when creating a package. I only ever use the package that is created by an automated build system, so it is safe for me to keep the DEBUG constant.

实际的msbuild线具有多个开关。我将描述异常的：

The actual msbuild line has a number of switches. I'll describe the unusual ones:

/ P：PostBuildEvent =

/p:PostBuildEvent=

如果我们不设置postBuildEvent为空，然后同样的后工序会越来越称为永远。和不断...

If we don't set the postBuildEvent to empty then the same post step will keep getting called forever. And ever...

/p:VisualStudioVersion=11.0

/p:VisualStudioVersion=11.0

在微软的那些家伙聪明使人们有可能与两个Visual Studio 2010和2012年。这是伟大的开放项目，但是当你在命令行中运行的MSBuild可以带来巨大的悲伤，并最终与讨厌的MSB4019错误消息，因为它是在寻找的Azure工具错了Visual Studio的文件夹。

Those clever guys at Microsoft made it possible to open projects with both Visual Studio 2010 and 2012. Which is great, but can bring great sadness when you run msbuild from the command line and end up with nasty MSB4019 error messages because it is looking in the wrong Visual Studio folder for the Azure tools.

此外，请注意，我用的云廓线。由于我只有CSX文件后，感到它似乎不有所作为我是否使用本地或云在这一点上。当我在Azure上运行我指定ServiceConfiguration.Local.cscfg。

Also, note that that I use the cloud profile. Since I am only after the csx files it doesn't seem to make a difference whether I use local or cloud at this point. When I run in azure I specify ServiceConfiguration.Local.cscfg.

编辑：在最后我把这个出来后工序，并把我的自动生成。我的本意是，从我的开发机器的测试将是相同作为我的自动生成，但后工序耗时过长而这意味着我在调试器下运行时，意见从OBJ文件夹，而不是该凸出文件夹源有做动态变化时，整个复制。

In the end I took this out of the post step and put in my automated build. My original intention was that running the tests from my dev machine would be the same as my automated build, but the post step took too long and the views were sourced from the obj folder rather than the proj folder when running under the debugger which meant I had to copy across when making changes on the fly.

悬而未决的问题

它仍然将是很好理解的MSBuild如何做的事情，以减少摩擦的知识在这一领域涉足的时候。它创建一个包的网站，并把它传递给CSPack？或者它解析项目文件，然后通过一些疯狂的参数CSPack？此外，当你在调试器中运行Azure项目，在模拟器中运行，只有在CSX文件夹（而不是图像等）的二进制文件。它是如何做到的？这将是巨大的，看到在Azure构建管道图片说明一些与显示生命周期一路部署。这可能也解释了为什么有二进制文件的两个副本。此外，如果Visual Studio中有一个像packageOnBuild项目标志的选项做了COPYONLY或创建一个包的Azure项目，这将是一个容易许多。我看到吃剩的蛋糕是没有意义的。 修改有可以添加到一个的csproj设置DeployOnBuild

It would still be good to understand how msbuild does things to reduce knowledge friction when dabbling in this area. Does it create a package for the website and pass it to CSPack? Or does it parse the project files and then pass some crazy arguments to CSPack? Also when you run an azure project in the debugger, it runs in the emulator with only the binaries in the csx folder (not the images, etc). How does it do that? It would be great to see some description with pictures of the Azure build pipeline with that showed the lifecycle all the way to deployment. That might also explain why there are two copies of the binaries. Also, this would have been a whole lot easier if Visual studio had a project flag like packageOnBuild for the Azure project with options to do a copyOnly or to create a package. I see no point in uneaten cake. There is a DeployOnBuild setting that can be added to csproj.

最后，正如我所说的这整个目的是为了让我能在这样我可以我的dev的机器上运行我的单元测试点和仿真CSX文件夹。我做了构建机上正规包装所以不要真的需要它在Visual Studio中。所以，我真的不希望任何东西打包，并希望有实现这一切更简单的方法。

Finally, as I mentioned the whole purpose of this is to get a csx folder that I can point the emulator at so that I can run my unit tests on my dev machine. I do the formal packaging on a build machine so don't really need it in Visual Studio. So, really I don't want to package anything and was hoping that there was an easier way of achieving all this.

推荐答案

由于MSBuild的使用蔚蓝的项目文件进行构建，它可以衍生出很多的信息，形成项目文件。

Since msbuild uses the the azure project file to perform the build, it can derive a lot of information form the project file.

有关cspack，假设的作用code已被编译并可以进行包装。由于cspack不依赖于项目文件，它需要为网络\\ workerrole项目code路径的明确信息。该csdef文件不包含任何此类信息。我建议，如果你想使用cspack。看它的文档并尝试创建一个包部署模拟器从命令行（COPYONLY选项）。一旦你找到了正确的语法在构建脚本，您可以将其嵌入。

For cspack, the assumption is the role code has been compiled and is available for packaging. Since cspack does not depend upon project file, it needs a explicit information for the code path of the the web\workerrole project. The csdef file does not contain any such information. I suggest if you want to use cspack. Look at its documentation and try to create a package for emulator deployment from command line (CopyOnly option). Once you find the correct syntax you can embed it in you build script.

这篇关于cspack行为从不同的MSBuild的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！