search

projectkudu / kudu

Kudu is the engine behind git/hg deployments, WebJobs, and various other features in Azure Web Sites. It can also run outside of Azure.
Apache License 2.0
3.12k stars 655 forks source link

Kudu fails to build a project using RIA services #453

Closed MatthewSteeples closed 11 years ago

MatthewSteeples commented 11 years ago

RIA services uses a custom msbuild task to generate code for the Silverlight Project. This is located in the assembly named Microsoft.ServiceModel.DomainServices.Tools.dll. I've set up the project so that it obtains these files from NuGet (using the RIAServices.Server package) and created a GitHub repository to demonstrate this (and to test it easier) at https://github.com/MatthewSteeples/KuduRiaTest.

The targets file is referenced by a relative path to the packages directory (the same as the dependency dlls) and the project is set to restore NuGet packages on build (with NuGet included in the repository). For some reason it looks like it's not able to find the targets file.

The error that I get when building this is shown below.

Command: deploy.cmd
Handling .NET Web Application deployment.
C:\DWASFiles\Sites\riatest\VirtualDirectory0\site\repository\RiaSample.Web\RiaSample.Web.csproj(163,3): error MSB4019: The imported project "C:\DWASFiles\Sites\riatest\VirtualDirectory0\site\repository\packages\RIAServices.Server.4.2.0\tools\Microsoft.Ria.Validation.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
An error has occurred during web site deployment.
Handling .NET Web Application deployment.
C:\DWASFiles\Sites\riatest\VirtualDirectory0\site\repository\RiaSample.Web\RiaSample.Web.csproj(163,3): error MSB4019: The imported project "C:\DWASFiles\Sites\riatest\VirtualDirectory0\site\repository\packages\RIAServices.Server.4.2.0\tools\Microsoft.Ria.Validation.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
davidebbo commented 11 years ago

Related (but a bit different) to this one

MatthewSteeples commented 11 years ago

Actually I've just worked out why this one fails by cloning the repository into a fresh directory and starting again with it. The reason is that when the csproj file is parsed for the first time the .targets file does not exist. This is because it's pulled down as part of the NuGet package restore the first time the solution is built. There's a chicken and egg scenario going on though because the solution can't be built because this targets file doesn't exist. Adding the .targets file to source control (rather than relying on NuGet) fixes this bug, and reveals the issue referenced in the link above.

davidebbo commented 11 years ago

I see. Indeed, starting with clean clone on local machine is a good way to make sure that everything is in a good state, and sometimes the working clone as extra non-committed files which can mask issues.