Kudu: Git Deployment of ASP.NET Core fails with 'error MSB1009: Project file does not exist'

[ealsur]

We have been deploying through Continuous Integration to Azure App Services for quite a bit, today, our builds are broken due to a change on the dotnet CLI.

Right now we see on Kudu that the current CLI version is 1.0.0-preview3-004056. If the App is an ASPNETCore app (xproj / project.json) it's failing to find the project.

The App Service activity log shows:

Manually running dotnet build on Kudu console shows:

Repro repo available: https://github.com/ealsur/mvpstream

[davidebbo]

Can you try adding this global.json at the root of your project?

{
  "projects": [ "src", "test" ],
  "sdk": {
    "version": "1.0.0-preview2-1-003177"
  }
}

If you don't have it, then it uses whatever is the latest Core sdk on the box, which changes over time (we now have the new Preview3, which is incompatible).

[ealsur]

Thanks David! I added the global.json to the repro repo and it worked.
On our production repo we never had a global.json file and has always been working, this might happen to other people if the CLI on Kudu is the one that's coming with the project.json > csproj migration (just a guess).

[davidebbo]

Well, the reason you never had problems is that there was no newer SDK. If you were to install the new Core sdk on your production repo, it would break as well.

Basically, not having global.json is analogous to depending on a Nuget package without specifying what version you want, and always getting the latest. It works until it stops working :)

[davidebbo]

Linking to forum thread and this StackOverflow question with the same issue.

Also, pasting the actual error as text for SEO purpose:

MSBUILD : error MSB1009: Project file does not exist

[leedjones]

So I already had a global.json file but it was targeting an older version of the SDK. I updated to the file linked to above and its still failing with the same error.

Also @davidebbo, you mention:

we now have the new Preview3, which is incompatible

can I ask, incompatible with what?

[davidebbo]

@leedjones can you share your Web App name, directly or indirectly? I'll take a look at what's going on.

The new tooling is csproj based, and incompatible with the xproj/package.json tooling. See here.

[leedjones]

thanks @davidebbo - i've created a dummy site for you: http://dummy18112016.azurewebsites.net
Many thanks :)

[davidebbo]

You have two Web Apps there, each with a slot. Can you give an additional hint as to which one has the issue? Thanks!

[leedjones]

Sorry, I should have added. Theyre all failing with the same error

[davidebbo]

@leedjones could you try something:

• Go to Kudu Console
• Go into D:\home\site\repository
• Run git clean -dxf to clean the repo
• Try deploying again

[davidebbo]

I'm still unclear what's going on, but I see another error in some of your logs:

error NU1001: The dependency Microsoft.EntityFrameworkCore.SQlite >= 1.0.0 could not be resolved.

Not sure if it's related, but I do know how to fix this one, which is a casing issue. I believe nuget made some recent changes that made it become case sensitive. In your project.json, please change (not the Sqlite casing):

"Microsoft.EntityFrameworkCore.SQlite": "1.0.0"

to

"Microsoft.EntityFrameworkCore.Sqlite": "1.0.0"

[leedjones]

Tried the git clean on both apps via the Kudu console and tested a redeployment. Failed again with the same error.
I changed the SQLite casing (not sure how the casing got mixed up like that anyway?) but that too failed.

Out of interest, and just a guess, but, I have an application setting which tells Azure which project to deploy out of a multi project solution. So I have two projects in the same solution and deploy different projects in different web apps based on the app setting. This has worked fine until two days ago; has anything changed around that?

[davidebbo]

I wouldn't think anything changes, but let me dig into that.

[davidebbo]

I don't understand what changed, but I know how you can fix it. Instead of setting PROJECT, try setting SCM_SCRIPT_GENERATOR_ARGS:

SCM_SCRIPT_GENERATOR_ARGS=--aspNetCore "FOO\src\FOO" --solutionFile FOO\FOO.sln

I replaced the name of your project by FOO here to not reveal it, so do change that.

Still trying to understand root issue, but prioritizing getting you unblocked for now.

[leedjones]

Hmmm...I have absolutely no idea how or why that fixed it, but it did!!
Thanks for the help @davidebbo - much appreciated.

Should I leave that setting in permanently now or is it just a temporary fix while the old PROJECT setting is fixed?

Thanks again 👍

[watashiSHUN]

@leedjones , I took a quick look at your kudu, your global.json should be put under D:\home\site\repository the same place where you put .git

[davidebbo]

Indeed, what @watashiSHUN says is an alternative solution.

In addition to that, we will look into what it takes to make things work directly without you needing to move your global.json to the root (which is admittedly unnatural).

Reopening to track this.

[shiranGinige]

@watashiSHUN I do have the global.json on the same repo directory still getting the issue. I have been deploying without .sln until yesterday ( VSCode with Yo ). This started today and didn't make any difference even after I added a .sln file.

[davidebbo]

@shiranGinige can you share your Web App name, directly or indirectly? Thanks.

[shiranGinige]

@davidebbo I created https://temp001.azurewebsites.net to re-pro. However, got a different error this time.

remote: GETSDKTOOLINGINFO : error : The project is configured to use .NET Core SDK version 1.0.0-preview2-003133 which is not installed
or cannot be found under the path D:\Program Files (x86)\dotnet. These components are required to build and run this project. Download
the version of .NET Core SDK specified in global.json or update the SDK version in global.json to the version that is installed. [D:\h
ome\site\repository\MyProj.xproj]

Thanks!

[davidebbo]

@shiranGinige Is that the version you specified in global.json? Try 1.0.0-preview2-1-003177 instead, as in the example above in this thread.

[shiranGinige]

@davidebbo sorry should have mentioned that before. I did try that. The result was the same.

[davidebbo]

@shiranGinige Ok, I will look at your test site temp001 later today and try to figure out what's going on.

[watashiSHUN]

@shiranGinige
this is because the dotnet cli version you specified in global.json is not installed in azure, here is the list of available ones:

I changed version on https://temp001.azurewebsites.net to 1.0.0-preview2-1-003177 as mentioned by @davidebbo, and the command failed before is now running successfully:

"D:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" "D:\home\site\repository\YOURSITE.sln" /nologo /verbosity:m /p:AutoParameterizationWebConfigConnectionStrings=false;Configuration=Release;UseSharedCompilation=false

you can verify the version and try to deploy again

[davidebbo]

Thanks @watashiSHUN. It's strange as @shiranGinige wrote

sorry should have mentioned that before. I did try that. The result was the same.

But it definitely should work with that version, and apparently it does. @shiranGinige can you try again?

[shiranGinige]

Just tried it and worked! Turns out I'm not very good with version numbers! What I had tried was "version": "1.0.0-preview2-003137" not "version": "1.0.0-preview2-1-003137" . Thanks for your help guys!

[davidebbo]

@shiranGinige Glad to hear!

[jsgoupil]

@davidebbo I might have opened a bug at the wrong place (https://github.com/dotnet/cli/issues/4804), but this msbuild/dotnet building is a giant mess on Azure...

Running msbuild with the xproj does not do the same thing on Azure vs my computer. On Azure I get plenty of typescript errors, on my computer I see that "dotnet build path/to/folder" is being executed and it builds fine.

So I went in my deployment script then replaced msbuild with that dotnet command.

But then I started to get this error mentioned in this thread "Project file does not exist".

So I replaced the dotnet build path to

cd to/path
dotnet build

Then it started to work. Same thing with publish.

[davidebbo]

@jsgoupil I would think that instead of messing with the path, all you had to do is add a global.json as described here. It's the right thing to do to make sure you declare the sdk version that you need as part of your project.

[jsgoupil]

Thanks @davidebbo. I have posted a blog post about all this stuff.
Deploying on Azure is messy with .net core http://blog.jsgoupil.com/deploying-net-core-on-azure-a-complete-mess/

[thetrav]

So, being completely new to all of this, I've created a brand new web app from .net core using:
dotnet new -t web
This doesn't create any src or test folders, everything appears to be in the root folder.

Does that mean I leave out the projects key in the global.json?
Do I need to re-structure the project the template created?

[davidebbo]

@thetrav your question is probably outside the scope of this issue, which is specific to errors people are getting when git deploying their Core apps to Azure Web Apps.

Maybe start with dotnet core forum? https://forums.asp.net/1255.aspx

[thetrav]

@davidebbo I am deploying my Core app to Azure Web Apps.
I listed the process I followed for creating the app so you could reproduce if necessary.

When I invoke git push azure master I get the same error reported in this issue:

MSBUILD : error MSB1009: Project file does not exist.

The suggested solution, global.json appears to require a specific folder structure.

When I added the suggested global.json and invoked the same git push command, I received the same error.

Worth noting I've also got the output:

Lock file has not changed. Skipping lock file write. Path: D:\home\site\repository\project.lock.json

So it's possible that your build process isn't picking up the new file due to some optimisation

[davidebbo]

@thetrav please share a test repo and we'll try to figure out why your global.json is not getting picked up. Please make sure it's at the root of the repo.

[thetrav]

@davidebbo
https://github.com/thetrav/dotnetcoretest

[davidebbo]

Your global.json has the sdk version as 1.1.0. No such version exists (sdk versions are not the same as framework versions). Please try with the exact global.json I pasted in my first reply above.

[thetrav]

Yeah that works perfectly, no folder structure changes required. Thanks for the help @davidebbo

[watashiSHUN]

Close this thread as the main issue of getting the correct version of dotnet cli is resolved, there's still some problems with finding the relevant global.json which is addressed by #2253

[dannythomas13]

@watashiSHUN putting global.json where .git is solved my issue with this but how should i know this from the documentation, I was placing it where the .sln was, thanks though!

[watashiSHUN]

@dannythomas13 kudu runs build command at repository root (@davidebbo maybe we should put this sentence in the document)
your problem would be solved if dotnet cli knows which version to launch depending on the global.json in your project/solution directory and NOT THE CURRENT (repository root). This issue is already being tracked on github, and until then we probably don't want to hack it ourselves in kudu.