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?
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...
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.
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.