-
Notifications
You must be signed in to change notification settings - Fork 519
Microsoft.DotNet.Props was not found #456
Comments
Did you install VS2017, it installs .NET Core 1.1 with it, I believe this is part of the problem. Since the projects are still on 1.0.1, since 1.1 was released so recently. Duplicate of #440 ? |
I'll try removing .NET Core 1.1 SDK and installing v1.0.1
|
Yep, removing .NET Core 1.1 SDK and installing v1.0.1 fixed it (didn't uninstall VS2017) |
The other fix is adding a global.json that tells the project to use your local 1.0.1 copy. Glad you got it fixed! @ManuelDeLeon |
I get the same error when I try to deploy to Azure App Services:
What can I do to deploy it on Azure App Services since it doesn't like the default .xproj? Edit: Just to be clear, that error is in the Azure logs. |
The error came up even after adding a global.json file? |
I then get "path too long" =/
|
@SteveSandersonMS Any ideas what could be causing this one, we figured out the 1.1 Core issue, but now he's getting path too long etc when deploying to Azure. It almost looks like some things didn't get installed properly through npm? |
Did you remember to specify a Node version for Azure to use via |
It has the default: (trying with 6.7.0) |
4.4.7 is too old. It includes NPM version 2.15.8. You need NPM >=3.0 for it to work properly on Windows. Let us know how you go with Node 6.7.0. |
Different log but it still ends up with "path too long" plus there's
|
I'm afraid I don't know why you'd still be getting the path-too-long issue if it's now actually using NPM v3.x during deployment. It makes me suspicious that maybe it's actually still using NPM 2.x. Is there any other evidence in the log to confirm what NPM version it's using? One bit of good news is that pretty soon, issues like this will no longer be a concern. The templates are changing so that you will no longer need to deploy I know that doesn't fix your immediate issue right now (since the new feature hasn't shipped yet). If you're able to repro the deployment issue in a simpler way (e.g., try just deploying a completely empty site that has nothing except your |
Is this a new upcoming feature to azure you're talking about, or to .NET Core and somehow caching node modules you want? Sounds exciting either way! |
Can't wait for it. What's the time frame we're talking about here? If it's a few weeks then I'll probably just wait. More than that and I'll probably keep banging my head against the wall. About my issue, it's definitely using a new node/npm (confirmed via Azure's command line):
But I'm still getting these two errors:
and further down:
Are either of these due to JS Services configuration? If not, how can I contact the Azure or Kudu people? Thanks for all the help. |
I'm very sorry for the trouble. As it turns out updating the node version in Azure still leaves all the deeply nested files in node_modules. It works correctly if you use a new app service and create the global.json file + set the node version from the get go. In my case I didn't know how to reset it so I had to delete the app and create it again. Thank you for your patience. |
Oh great so, just for clarity if anyone else runs into it:
Glad you got it working! |
It's just a change to the default Webpack config that prepares a completely standalone server-side prerendering bundle (like how the client-side bundle is completely self-contained). This means that at runtime, it never calls Node's We need this because (1) people continue to struggle with deploying |
I love it, that's a great idea. Yeah it seems to be a reoccurring issue :) |
That feature is published now (get the latest |
Will do, thanks again Steve! |
Windows 10 x64
node v6.7.0
npm v4.0.2
.NET Core 1.0.1 tools Preview 2
.NET Core 1.1 SDK
tsc v2.0.10 (same results with v1.8)
VS Code
VS2015
VS2017
I get the following error when I run the React generator (yarn v0.17.8):
By the way, with yarn v0.16.1 I get the following set of errors:
The text was updated successfully, but these errors were encountered: