Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NuGet errors when compiling on command line with UWP projects and PackageReferences #4515

Closed
twsouthwick opened this issue Feb 6, 2017 · 14 comments

Comments

@twsouthwick
Copy link

Details about Problem

NuGet product used (NuGet.exe | VS UI | Package Manager Console | dotnet.exe): msbuild

NuGet version (x.x.x.xxx): 4.0 (msbuild v 15.1.523.56541)

VS version (if appropriate): 26127.3

OS version (i.e. win10 v1607 (14393.321)): 14393.693

Worked before? If so, with which NuGet version: No

Detailed repro steps so we can see the same problem

I've switched my UWP project to use PackageReferences which now support UWP projects. However, I find that it loads fine and compiles as expected in VS. When I try to compile on command line, it fails with the following errors:

[path]\KeePassWin\KeePassWin.sln" (restore;build target) (1) ->
"[path]\KeePassWin\test\KeePassLib.Test\KeePassLib.Test.csproj" (default target) (3:5) ->
(ResolveNuGetPackageAssets target) ->
  C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\NuGet\15.0\Microsoft.NuGet.targets(19
7,5): error : The project.json is referencing the project [path]\KeePassWin\test\src\KeePass
Lib\KeePass.Models.csproj', but an output path was not specified on an item in the ProjectReferencesCreatingPackages pr
operty. [[path]\KeePassWin\test\KeePassLib.Test\KeePassLib.Test.csproj]

"[path]\KeePassWin\KeePassWin.sln" (restore;build target) (1) ->
"[path]\KeePassWin\src\KeePass.Win.Services\KeePass.Win.Services.csproj" (default target) (4:
5) ->
  C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\NuGet\15.0\Microsoft.NuGet.targets(19
7,5): error : Your project is not referencing the "UAP,Version=v10.0.10586" framework. Add a reference to "UAP,Version=
v10.0.10586" in the "frameworks" section of your project.json, and then re-run NuGet restore. 

I don't have any project.json files anymore in this project and I'm targeting the 14393 SDK not the 10586 so I'm confused why that's even showing up. Here's a link to the project in case it helps: https://github.com/twsouthwick/KeepassWin

@emgarten
Copy link
Member

emgarten commented Feb 6, 2017

@twsouthwick does it make a difference if you restore with Visual Studio vs the command line?

@twsouthwick
Copy link
Author

If I restore with msbuild /t:restore I see the same error in VS. If I clean my repo and build straight from VS, things restore fine and compile as expected.

@emgarten
Copy link
Member

emgarten commented Feb 6, 2017

@twsouthwick can you diff the project.assets.json files between the command line restore and the Visual Studio output from restore? Is there any difference?

@twsouthwick
Copy link
Author

Hmmm... I'm now getting a different error. I just upgraded to 26205 d15rel and am seeing the following:

  • I see this error when restoring from commandline
  • If I clear the repo and have VS restore, then no project.asset.json files are created

@emgarten
Copy link
Member

emgarten commented Feb 7, 2017

@twsouthwick try right clicking on the solution and selecting Restore NuGet Packages. Also make sure you have automatic package restore enabled under the Visual Studio NuGet options.

@twsouthwick
Copy link
Author

Ok - that seemed to work once I selected automatc package restore enabled; if that was disabled and I right click on the solution and select Restore NuGet packages, it does not work.

I've created a repo here that has the project.assets.json files: https://github.com/twsouthwick/NugetRestoreUwp. The first commit is adding the files from VS, the second commit is when I just restore from the commandline. It seems like it has different versions of the UWP SDK, but the order also seems off, so I'm not sure what's important there.

You'll notice that there is no change to KeePassWin (which is the UWP app and cannot be compiled for Any CPU. When I try msbuild /t:restore /p:Platform=x86 I get the following error:

  C:\Program Files (x86)\Microsoft Visual Studio\2017\Internal\Common7\IDE\CommonExtensions\Microsoft\NuGet\NuGet.targe
ts(97,5): error : Sequence contains more than one matching element [(path)\KeePass
Win.sln]

@emgarten
Copy link
Member

emgarten commented Feb 7, 2017

I tried this on VS 15.0.0-RC4+26205.0.d15rel and was unable to repro it using the develop branch.

Restore and build from the command line showed no errors. Restore and build in VS were also without errors.

msbuild /t:restore /p:Platform=x86 does cause an error for me, it looks that is the same issue as #4316

@twsouthwick
Copy link
Author

Which command are you using that works? I'm running msbuild /t:restore;build

That linked issue is one I filed earlier for a different project - hadn't realized they were similar :)

@emgarten
Copy link
Member

emgarten commented Feb 7, 2017

I'm able to repro it now. It isn't clear what the build task is expecting there.

To get the repro on the command line a clean is needed before building. On a rebuild it showed up.

@rrelyea
Copy link
Contributor

rrelyea commented Feb 13, 2017

@emgarten - thoughts on this?

@emgarten
Copy link
Member

@rrelyea this issue is similar to #4532 which @zhili1208 was investigating. There are no .xproj files in this solution however.

@rrelyea rrelyea modified the milestones: 4.0.1, 4.0 RTM Feb 13, 2017
@martinsuchan
Copy link

martinsuchan commented Jul 31, 2017

What is status of this issue? It's almost August 2017 and I just hit this issue when building our UWP app in PowerShell:. We use PackageReferences and use TargetVersion 15063 and MinVersion 14393.
msbuild version '15.1.1012.6693', NuGet Version: 4.0.0.2283

Update, it's failing with NuGet 4.0.0 but working with 4.1.0.

@emgarten
Copy link
Member

Thanks for the update @martinsuchan, it looks like this can be closed as it was fixed with #4532 in 4.1.0

@barishamil
Copy link

Having this problem after updating to creators edition then reverting changes via version control

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants