PackageReference doesn't work on .NET 4.5.2 console app

[clairernovotny]

In VS 2017 RC2

Create a new .NET 4.5.2 console app. Manually add a PackageReference to the csproj and compile. You get the following error:

1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\NuGet\15.0\Microsoft.NuGet.targets(162,5): error : Your project.json doesn't have a runtimes section. You should add '"runtimes": { "win": { } }' to your project.json and then re-run NuGet restore.

[emgarten]

@onovotny try adding this to your project:

<PropertyGroup>
  <RuntimeIdentifiers>win</RuntimeIdentifiers>
</PropertyGroup>

@jainaashish is the default added in the latest build task? Should the message be updated also to include non-project.json based projects.

[rrelyea]

Yes, the next RC update will have this, or similar, via targets files.
So perhaps you want to make your temporary workaround conditioned on RuntimeIdentifiers not being set?

[clairernovotny]

Okay, thanks, that worked!

[markusgud]

We had this problem too. We were changing targeting from .NET Core Project back to the VS2012 project format. For some reason there was a file obj/project.assets.json that was not deleted on "Clean Solution".

Once we deleted this file manually, the problem was gone.

[den-run-ai]

@markusgud deleting project.assets.json worked great! In my case I had both solutions open with different msbuild systems. Using one solution at a time fixes the issues.

[brucechase]

I wouldn't be so fast in deleting this error. I cannot get rid of the error from VS 15.4/C# even after following all the above steps multiple times. I am at a loss of what to do... 3 hours into this and I cannot compile the application. I have deleted the project.*.json files and project.json file; updated those files with the "win10" addition to "runtimes"; attempted to restore nuget; changed nuget files; rebooted; restarted; you-name-it. And all I get is the same error: "Your project.json doesn't have a runtimes section. You should add '"runtimes": { "win10": { } }' to your project.json and then re-run NuGet restore."

[jainaashish]

@brucechase Are you using PackageReference to manage your dependencies or project.json file? And if you were using project.json file then why will you delete that? that will cause even more troubles. Can you share your sample solution or detailed steps to repro your issue?

[brucechase]

I wasn't using project.json... until the compile error told me to to add the "win10" to it. Hell, after closing VS and restarting, I cannot even open either the solution or project file. Both lock up VS immediately now. Damn me for updating to VS to 15.4. Everything was working fine under 15.3 -- but I wanted to migrate our UWP app to .NET Standared 2.0. Everybody here cringes at the thought of updating VS or NuGet. I was the guinea pig.

…

On Thu, Oct 26, 2017 at 12:55 PM, Ashish Jain ***@***.***> wrote: @brucechase <https://github.com/brucechase> Are you using PackageReference to manage your dependencies or project.json file? And if you were using project.json file then why will you delete that? that will cause even more troubles. Can you share your sample solution or detailed steps to repro your issue? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4163 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACqR90-VDt0It8uRuJ559_NELRHyTudFks5swLl-gaJpZM4LX1uE> .

--

-------------------------------------------------- Bruce Chase 413 Inglewood Drive Westerville, OH 43081 (614) 638-8094 (cell) (614) 890-0006 (home)

[LightBender]

I just ran into this as well. If you have a old-style csproj that references a new style csproj (any project with transitive references) go to the obj folder for the old-style csproj, delete the project.assets.json file and rebuild. That worked for me.

[brucechase]

Yea -- I tried that. But now I cannot even get into the the project -- it does not appear in the solution view of VS. VS just locks up after selecting the solution or project files. I even took an older version of the project file with GIT, but VS cannot load the old project file either... Just locks up. Other VS projects start, no problem. I am about ready to remove VS and try to go back to 15.3 (VS 2017). I think the changes I made with NuGet screwed the project for good. I was attempting to move to .NET Standard 2.0 for a UWP project.

…

On Thu, Oct 26, 2017 at 7:13 PM, Adam Wilson ***@***.***> wrote: I just ran into this as well. If you have a old-style csproj that references a new style csproj (any project with transitive references) go to the obj folder for the old-style csproj, delete the project.assets.json file and rebuild. That worked for me. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4163 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACqR962JxycT5sLN-CvJZKCPrFtZiP6Wks5swRIagaJpZM4LX1uE> .

--

-------------------------------------------------- Bruce Chase 413 Inglewood Drive Westerville, OH 43081 (614) 638-8094 (cell) (614) 890-0006 (home)

[jainaashish]

Is it possible for you to share your project file removing private data? And it looks like your issue is different than what this issue is about so please log a separate issue with all the details.

[brucechase]

This is a massive project. Xamarin -- The project produces output for UWP, iOS, Mac, Android, Silverlight, etc. I am going to clean the project off the HD and pull from GIT once more. I updated Windows to Fall Creator's Edition (or whateve it is called). I am hoping that maybe that will help. If that all fails, I will see if I can get permission for you on GitHub. The MSFT's Xamarin team has permission since we were doing a very good job of finding bugs in that.

…

On Thu, Oct 26, 2017 at 8:54 PM, Ashish Jain ***@***.***> wrote: Is it possible for you to share your project file removing private data? And it looks like your issue is different than what this issue is about so please log a separate issue with all the details. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4163 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACqR93dvi_MOPYcHJecf-U9kuQ6LrHEIks5swSnMgaJpZM4LX1uE> .

--

-------------------------------------------------- Bruce Chase 413 Inglewood Drive Westerville, OH 43081 (614) 638-8094 (cell) (614) 890-0006 (home)

[evil-shrike]

I'm having the same error in my solution with mixed old and new style csproj while I build it via msbuild (as building via dotnet doesn't work for VSSDK-projects). Please see details here:
https://developercommunity.visualstudio.com/content/problem/138372/vsix-cant-build-solution-with-mixed-style-csproj-p.html

UPDATE:
adding

<PropertyGroup>
  <RuntimeIdentifiers>win</RuntimeIdentifiers>
</PropertyGroup>

into EVERY (old-styled) csproj helps me!

[brucechase]

I finally have VS 2017 (15.4) running correctly with NuGet. The problem appears to have been VS. It took some convoluted steps in order to completely uninstall VS and reinstall it. Essentially, VS was not completely uninstalling correctly. Here is the link that helped with the uninstall errors: https://developercommunity.visualstudio.com/content/problem/49854/i-cant-repair-the-visual-studio-2017.html

…

On Fri, Oct 27, 2017 at 7:41 AM, Sergei Dorogin ***@***.***> wrote: I'm having the same error in my solution with mixed old and new style csproj while I build it via msbuild (as building via dotnet doesn't work for VSSDK-projects). Please see details here: https://developercommunity.visualstudio.com/content/ problem/138372/vsix-cant-build-solution-with-mixed-style-csproj-p.html — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4163 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACqR91zydI2YK58y_opHRAShW3_67GEZks5swcFsgaJpZM4LX1uE> .

--

-------------------------------------------------- Bruce Chase 413 Inglewood Drive Westerville, OH 43081 (614) 638-8094 (cell) (614) 890-0006 (home)

[rianjs]

I don't know why this was closed. It's still a problem.

[shoff]

Huge problem still for me trying to convert a project to use PackageReference from packages.config. Lot's of Method XXX of interface XXX does not implement method etc etc. When obviously they do.

[304NotModified]

I wouldn't be so fast in deleting this error. I cannot get rid of the error from VS 15.4/C# even after following all the above steps multiple times. I am at a loss of what to do... 3 hours into this and I cannot compile the application. I have deleted the project.*.json files and project.json file; updated those files with the "win10" addition to "runtimes"; attempted to restore nuget; changed nuget files; rebooted; restarted; you-name-it. And all I get is the same error: "Your project.json doesn't have a runtimes section. You should add '"runtimes": { "win10": { } }' to your project.json and then re-run NuGet restore."

I've still the same problem.

<PropertyGroup>
  <RuntimeIdentifiers>win</RuntimeIdentifiers>
</PropertyGroup>

Won't fix it for me :(

also clean bin, obj etc folders, still this error

update: closed as duplicate, where is the duplicate?

update2: this worked for me: git clean -fxd

[jainaashish]

@304NotModified when it's throwing error for win10 then you would need to add <RuntimeIdentifiers>win10</RuntimeIdentifiers> to resolve this instead of just win.

Besides with latest visual studio 2017 15.6 you shouldn't need to explicitly set this workaround. If you're still seeing this issue with latest VS, then please provide more details:

• VS version
• Type of project where you see this issue (UAP or full desktop framework)
• Run msbuild /pp:pp.txt command from developer command prompt on this failing csproj file and share the pp.txt file.

[304NotModified]

I had the problem with 15.6.5 and 15.6.6

It was .net class library.

If the issue is back, I will post the pp command log.

[flcdrg]

I was getting this error on our build server. It seems to be related to the fact that the particular build agent had the following entries in the system PATH environment variable:

C:\Program Files (x86)\MSBuild\14.0\Bin
C:\Program Files (x86)\MSBuild\

Removing them (and rebooting the agent) appears to have resolved the problem. Another build agent (that didn't have these in PATH was not experiencing this issue)