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

Ignore PROJECT.JSON when using .CSPROJ #394

Closed
bchavez opened this Issue Dec 5, 2015 · 20 comments

Comments

Projects
None yet
7 participants
@bchavez
Copy link

bchavez commented Dec 5, 2015

Hi,

I have a serious problem after upgrading to VS 2015 Update 1 RTM.

I am trying to do cross-platform development for my RethinkDB Driver for both CoreCLR/DNX and full .NET 4.5 framework.

I don't want to convert everything to a DNX build project because the CoreCLR/DNX stuff has not RTM'd. So, I'd just like to use standard RTM tools when developing the .NET 4.5 target, then, later when Visual Studio is closed, do dnu build _as a separate thing_.

When I have .CSPROJ open in Visual Studio and I try to compile, I get an error that was not here prior to Update 1:

Your project.json doesn't have a runtimes section. 
You should add '"runtimes": { "win": { } }' to your project.json and 
then re-run NuGet restore. RethinkDb.Driver

Okay... So I attempt to add:

"runtimes": { "win": { } }

Q1: why do I need this "win" tag since I'm doing cross-platform targeting with CoreCLR? I am not, in any way, targeting "windows" with CoreCLR/DNX).

So, I place the tag inside project.json, but still no dice. Now I'm getting even more errors:

Some packages are not compatible with DNXCore,Version=v5.0 (win).           0   
System.Runtime.Extensions 4.0.11-beta-23516 provides a compile-time reference assembly for System.Runtime.Extensions on DNXCore,Version=v5.0, but there is no run-time assembly compatible with win.            0   
System.Net.Primitives 4.0.11-beta-23516 provides a compile-time reference assembly for System.Net.Primitives on DNXCore,Version=v5.0, but there is no run-time assembly compatible with win.            0   

Now it looks like this new "win" runtime tag is causing even more problems. Can someone tell me why MSBUILD is so unhappy now?

Even better, can someone tell me how to force _MSBUILD + VS + NUGET_ to 🚫 STOP 🚫 probing for project.json when I have my classic .CSPROJ open? I _do not_, want project.json even being considered or looked at when I have my classic .CSPROJ open in Visual Studio. I'd prefer my PACKAGES.CONFIG considered when my classic project is open. I don't understand why the tooling from both DNX (project.json) and CSPROJ are conflicting. IMHO, these should be two completely different things at this stage.

Feel free to fork or download the project. My sources here: https://github.com/bchavez/RethinkDb.Driver

There are two solutions:

  • RethinkDb.Driver.Dnx.sln - DNX Project Solution
  • RethinkDb.Driver.sln - Classic .csproj Solution

Thanks,
Brian

@bchavez

This comment has been minimized.

Copy link
Author

bchavez commented Dec 7, 2015

Okay, I sort of solved this by downgrading .csproj Toolsversion to 4.0 (from 14.0) <Project ToolsVersion="4.0".

@weshaggard

This comment has been minimized.

Copy link
Member

weshaggard commented Dec 7, 2015

@Pilchie

This comment has been minimized.

Copy link
Member

Pilchie commented Dec 7, 2015

project.json and .csproj files are NOT two differently things. project.json is used by more than just DNX. It can also be used in conjunction with .csproj files as a replacement for packages.config, to allow .csproj files to take advantage of features like transitive dependencies, build time resolution of assets, etc.

The reason you are being prompted to add a runtime section is because the build time asset resolution is trying to copy assets from your dependencies to allow you to run, but it needs to know what assets you want to copy.

Having a project.json meant to be used for DNX in the same directory as a packages.config to be used by msbuild isn't something that's supported today, but you can have two different project.json files, one for msbuild and one for DNX. To do that, create a <projectname>.project.json (where <projectname> is the name of your .csproj. This will allow you to specify the existing framework from your .csproj, instead of of DNX.

Finally, if you are building a library and you don't want to copy runtime assets to your output directory, you can add <CopyNuGetImplementations>false</CopyNuGetImplementations> to your .csproj, in which case you won't need a runtimes section in your <projectname>.project.json.

Hope this helps.

(Also tagging @yishaigalatzer and @ericstj)

@bchavez

This comment has been minimized.

Copy link
Author

bchavez commented Dec 7, 2015

Thanks @Pilchie

be used in conjunction with .csproj files as a replacement for packages.config

Thank for explaining this: I'll migrate off packages.config

The reason you are being prompted to add a runtime section is because the build time asset resolution is trying to copy assets from your dependencies to allow you to run, but it needs to know what assets you want to copy.

If I understand correctly, then, how do I tell the build time asset resolution that I only want outputs for net45 full framework right now when I build the solution in VS2015 and not bother with any DNX stuff?

Again, thanks for your help

@bchavez

This comment has been minimized.

Copy link
Author

bchavez commented Dec 7, 2015

If I understand correctly, then, how do I tell the build time asset resolution that I only want outputs for net45 full framework right now when I build the solution in VS2015 and not bother with any DNX stuff?

Maybe, specify runtime: { "win":{}} in name.project.json, but leave it out in the root project.json?

@Pilchie

This comment has been minimized.

Copy link
Member

Pilchie commented Dec 7, 2015

I edited my markdown so that the xml doesn't disappear in in the rendered output.

Right - also, name.project.json should just have a single entry like net451 in the frameworks section.

@bchavez

This comment has been minimized.

Copy link
Author

bchavez commented Dec 7, 2015

Fantastic. Thank you. That seems to have solved everything. Once again, happily compiling! I'm sure other will find this information really useful. Just had to do one last solution wide "nuget restore" after the changes.

@bchavez bchavez closed this Dec 7, 2015

@bchavez

This comment has been minimized.

Copy link
Author

bchavez commented Dec 11, 2015

This is a bit strange. So, check this out:

  • Everything was working fine when I closed the issue. I could compile fine in VS2015 Update 1 after adding name.project.json.
  • I added one dependency on System.Threading.Timer to project.json:
"dnxcore50": {
      "dependencies": {
        //
        "System.Threading.Timer": "4.0.1-beta-23516"
      },
  • Build, but got the 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. RethinkDb.Driver
  • Ok. So, I back out and remove the line System.Threading.Timer, save, build-clean, and "Restored NuGet" packages. Even restarted Visual Studio and a _still_ get an error message.

So, now _what_ is going on? I have name.project.json with the necessary "runtime", and a project.json without any runtimes as we discussed few days ago.

I dunno, but to me it seems natural to revert my 1 line edit should get me back to where I was but I cannot back out of a 1-line edit. I cannot get rid of this error. 👎. Back to square one in this original issue.

Latest code, "name.project.json" & "project.json" files here:
https://github.com/bchavez/RethinkDb.Driver/tree/master/Source/RethinkDb.Driver

CI server's Build Error:
https://ci.appveyor.com/project/bchavez/rethinkdb-driver/build/282#L654

"C:\projects\rethinkdb-driver\Source\RethinkDb.Driver.sln" (Rebuild target) (1) ->
"C:\projects\rethinkdb-driver\Source\RethinkDb.Driver.Tests\RethinkDb.Driver.Tests.csproj" (Rebuild target) (2) ->
"C:\projects\rethinkdb-driver\Source\RethinkDb.Driver\RethinkDb.Driver.csproj" (default target) (3:2) ->
(ResolveNuGetPackageAssets target) -> 
  C:\Program Files (x86)\MSBuild\Microsoft\NuGet\Microsoft.NuGet.targets(109,5): error : Your project.json doesn't list 'win' as a targeted runtime. You should add '"win": { }' inside your "runtimes" section in your project.json, and then re-run NuGet restore. [C:\projects\rethinkdb-driver\Source\RethinkDb.Driver\RethinkDb.Driver.csproj]

    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:04.14

@bchavez bchavez reopened this Dec 11, 2015

@bchavez

This comment has been minimized.

Copy link
Author

bchavez commented Dec 11, 2015

I deleted these *.lock.json files and it seems to build again. I still think this is a symptom of a larger problem.

  1. I delete _ALL_ lock files (and ensure NO lock files exist in the build DIR), I can run

    msbuild source\RethinkDb.Driver.sln, _BUILD SUCCESS_

  2. Restore Packages from Visual Studio 2015 Update 1, generates RethinkDb.Driver.project.lock.json, and the command:

    msbuild source\RethinkDb.Driver.sln _BUILD FAIL_ with error message below:

Your project.json doesn't list 'win' as a targeted runtime. You should add '"win": { }' 
inside your "runtimes" section in your project.json, and then re-run NuGet restore.
    RethinkDb.Driver            

So, ironically, Restore Packages breaks the build. 🎱

@jasonmalinowski

This comment has been minimized.

Copy link
Member

jasonmalinowski commented Dec 19, 2015

So there's a two things there:

  1. I've filed NuGet/Home#1859 to address your immediate point that we're using the existence of the lock file to figure out whether we are looking for NuGet packages or not. In your case, the first build should fail with some sort of "you didn't restore packages" error. In your case, the build succeeded but didn't actually consume the packages you thought you referenced, so that isn't good.
  2. The error message is correct: you need to update your project.json to include that entry under runtimes. In Visual Studio 2015 RTM there was a bug that meant you could get away with win-anycpu in there, but that had many other problems. You should add the win entry, and remove win-anycpu if you don't care about building with RTM.

Since NuGet/Home#1859 is tracking the first strangeness you observed, and the second issue is addressed by updating your project.json as described, can you close this bug once you've confirmed you're unblocked?

@bchavez

This comment has been minimized.

Copy link
Author

bchavez commented Dec 19, 2015

Hi @jasonmalinowski,

  1. I have project.json with all the necessary references.
  2. I have name.project.json with the runtimes: { "win-anycpu" } and "frameworks": { "net45":{}}.

This should work. But it does not. I think it's likely due to No.1 NuGet/Home#1859. But once NuGet/Home#1859 as you suggested is fixed, I fear I will be in a state where I will no longer be able to build this project. NuGet/Home#1859 actually allows me to build the project normally _without_ failing on this "runtimes" compiler error.

@bchavez

This comment has been minimized.

Copy link
Author

bchavez commented Dec 19, 2015

Please feel free to checkout / clone the repo here:

https://github.com/bchavez/RethinkDb.Driver/tree/master/Source/RethinkDb.Driver

I have MSBuild hacks everywhere just trying to get this to build for net45 and dnx CoreCLR. All the msbuild hacks are inside this BauBild file

@jasonmalinowski

This comment has been minimized.

Copy link
Member

jasonmalinowski commented Dec 19, 2015

Read the error you're getting carefully: on Update 1, you need win as a runtime, not win-anycpu. If you change this, your error should go away. The bug I filed is simply to make sure that both of your builds would fail when you're in this broken case, not just one of them.

@bchavez

This comment has been minimized.

Copy link
Author

bchavez commented Dec 19, 2015

Ah, very nice. Thank you so very much @jasonmalinowski . Just committed the changes with your suggestion. I no longer need the *.lock hack to cross-build. Please give @jasonmalinowski MVP of the year! Thanks 👍 !

@bchavez bchavez closed this Dec 19, 2015

@jasonmalinowski

This comment has been minimized.

Copy link
Member

jasonmalinowski commented Dec 19, 2015

Also, another possible solution: if you really never want your csproj reading any project.json file anywhere, you can just set <ResolveNuGetPackages>false</ResolveNuGetPackages> in your .csproj file and that'll turn this all off.

@bchavez

This comment has been minimized.

Copy link
Author

bchavez commented Dec 19, 2015

Awesome! There is so much valuable information in this issue undoubtedly someone will find this info very useful. Again, thank you and to everyone for their input in helping unblock this issue.

Mpdreamz added a commit to elastic/elasticsearch-net that referenced this issue Jan 21, 2016

Side by side compilation of msbuild and dnx projects
* msbuild src\Elasticsearch.sln build now works again. No longer suffers
from noisy neighboor syndrom because unreferenced project.json files
trigger all kinds off nuget msbuild targets to kickin. ty @bchavez for
opening Microsoft/msbuild#394 !

* Opening src\Elasticsearch.sln in visual studio builds and compiles but
sadly NCrunch has some DNX integration (yay!) that I can't figure out
how to circumvent yet:

> Your DNX runtime installation is either corrupt or is not supported by
> this version of NCrunch
>	at nCrunch.Compiler.DnxIntegration.DnxRuntime..ctor(String

* Opening src\elasticsearch-net.sln still succesfully compiles using the
dnx toolchain

* our FAKE build scripts still build using the new chain succesfully
@Konard

This comment has been minimized.

Copy link

Konard commented Feb 29, 2016

Is there a way not to ignore project.json by adding project-name.project.json:

{
  "runtimes": { "win": { } },
  "frameworks": { "net45": { } }
}

but use packages.config for csproj projects? So both can share same code, but each project (csproj and xproj) will have different nuget configuration?

@Konard

This comment has been minimized.

Copy link

Konard commented Feb 29, 2016

Also, another possible solution: if you really never want your csproj reading any project.json file anywhere, you can just set false in your .csproj file and that'll turn this all off.

There is also strange behaviour if <ResolveNuGetPackages>false</ResolveNuGetPackages> is set in csproj but project-name.project.json removed:

------ Discover test started ------
An error occurred while reading file 'C:\Users\Константин\Desktop\LinksPlatform\Platform\Platform.WindowsAPI\Platform.WindowsAPI.project.json': Could not find file 'C:\Users\Константин\Desktop\LinksPlatform\Platform\Platform.WindowsAPI\Platform.WindowsAPI.project.json'.
========== Discover test finished: 0 found (0:00:00,5070015) ==========

After this solution is to reload project again, but why it happens in the first place?

Konard added a commit to Konard/LinksPlatform that referenced this issue Feb 29, 2016

enricosada added a commit to enricosada/suave that referenced this issue Apr 7, 2016

workaround msbuild restore error on VS 2015
on msbuild compile of Suave.csproj project

```
Your project is not referencing the ".NETFramework,Version=v4.5" framework. Add a reference to ".NETFramework,Version=v4.5" in the "frameworks" section of your project.json, and then re-run NuGet restore
```

ref Microsoft/msbuild#394

enricosada added a commit to enricosada/suave that referenced this issue Apr 7, 2016

workaround msbuild restore error on VS 2015
on msbuild compile of Suave.csproj project

```
Your project is not referencing the ".NETFramework,Version=v4.5" framework. Add a reference to ".NETFramework,Version=v4.5" in the "frameworks" section of your project.json, and then re-run NuGet restore
```

ref Microsoft/msbuild#394

theimowski added a commit to theimowski/suave that referenced this issue Apr 12, 2016

workaround msbuild restore error on VS 2015
on msbuild compile of Suave.csproj project

```
Your project is not referencing the ".NETFramework,Version=v4.5" framework. Add a reference to ".NETFramework,Version=v4.5" in the "frameworks" section of your project.json, and then re-run NuGet restore
```

ref Microsoft/msbuild#394

theimowski added a commit to theimowski/suave that referenced this issue Apr 13, 2016

workaround msbuild restore error on VS 2015
on msbuild compile of Suave.csproj project

```
Your project is not referencing the ".NETFramework,Version=v4.5" framework. Add a reference to ".NETFramework,Version=v4.5" in the "frameworks" section of your project.json, and then re-run NuGet restore
```

ref Microsoft/msbuild#394

haf added a commit to SuaveIO/suave that referenced this issue Apr 14, 2016

workaround msbuild restore error on VS 2015
on msbuild compile of Suave.csproj project

```
Your project is not referencing the ".NETFramework,Version=v4.5" framework. Add a reference to ".NETFramework,Version=v4.5" in the "frameworks" section of your project.json, and then re-run NuGet restore
```

ref Microsoft/msbuild#394

theimowski added a commit to theimowski/suave that referenced this issue Apr 19, 2016

workaround msbuild restore error on VS 2015
on msbuild compile of Suave.csproj project

```
Your project is not referencing the ".NETFramework,Version=v4.5" framework. Add a reference to ".NETFramework,Version=v4.5" in the "frameworks" section of your project.json, and then re-run NuGet restore
```

ref Microsoft/msbuild#394
@psulek

This comment has been minimized.

Copy link

psulek commented May 4, 2016

@bchavez name.project.json helps me a lot, thanks!

@dmitriyse

This comment has been minimized.

Copy link

dmitriyse commented Jul 27, 2016

In my case migration to project.json is not an option. I created new issue and suggest solution with temp implementation. NuGet/Home#3207

enricosada added a commit to enricosada/FSharp.Compiler.Service that referenced this issue Jul 27, 2016

fix nuget error/features
ref Microsoft/msbuild#394

```
C:\Program Files (x86)\MSBuild\Microsoft\NuGet\Microsoft.NuGet.targets(140,5): Your project is not referencing the ".NETFramework,Version=v4.5" framework. Add a reference to ".NETFramework,Version=v4.5" in the "frameworks" section of your project.json, and then re-run NuGet restore
```

polytypic added a commit to Hopac/Hopac that referenced this issue Sep 5, 2016

polytypic added a commit to Hopac/Hopac that referenced this issue Sep 5, 2016

polytypic added a commit to Hopac/Hopac that referenced this issue Sep 9, 2016

TheAngryByrd added a commit to TheAngryByrd/logary that referenced this issue Nov 20, 2016

TheAngryByrd added a commit to TheAngryByrd/logary that referenced this issue Dec 13, 2016

TheAngryByrd added a commit to TheAngryByrd/logary that referenced this issue May 29, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.