Silverlight xap file not being copied to ClientBin

2019-02-16 18:09发布

问题:

We're developing a ASP.Net Web Application project that has a Silverlight 2.0 component. We've referenced the silverlight project in the web application properties, and the xap file is being copied to the ClientBin folder of the Web application when we build locally.

The problem is that when we build this on our build server (which is using CruiseControl.Net, though I don't think that's relevant) the xap file isn't being copied. The strange thing is that this was working, but something has broken it and we can't figure out what.

Anybody seen this before?

回答1:

Sorted!

Not quite sure why, but it turns out we had an out-of-date version of Microsoft.WebApplications.targets on the build server - the version we had didn't have the CopySilverlightApplications task in it. To fix the problem, I copied the two files from the C:\Program Files\MSBuild\Microsoft\VisualStudio\v9.0\WebApplications folder to the same location on the build server. Now everything works as it should.

Now if only I could find out which installer should have updated those files...



回答2:

I found the following tag in my project file fixed it:

<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>

e.g.

<PropertyGroup>
  <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />

Maybe VSToolsPath is set before this point on my local machine, but not on the build server.



回答3:

I just had a similar issue where some files weren't being built/moved to my dev server. The issue ended up being permission as I manually deleted a folder. For some reason, the Network Service account and permissions weren't being inherited by the newly recreated folder.