runtime: Presence of project.json breaks existing csproj tooling (and makes unexpected demands)

I’m trying to transition multiple libraries to CoreCLR, moving to the DNX build tools.

Since the folder name defines the assembly/package name (not editable), and since **/*.cs is the default inclusion list, the natural thing to want to do is to add a project.json alongside the pre-existing csproj. This is particularly valuable where not all parties are yet working with DNX.

Things go south very quickly, though, with errors from nuget package restore including errors about “runtimes”, having to add explicit version numbers to project references, and complains about projects targeting multiple frameworks (which gets generated into {projectt}.nuget.targets).

Short term, del project.json /s, del project.lock.json /s (and del *.nuget.targes /s if you have already failed once) makes everything work - so it is the mere presence of those files that makes the csproj unhappy. And obviously you need to not push those deletions back to source control!

This means that the only way to transition to DNX tooling alongside csproj is:

  • have the project.json in the {ProjectName} folder
  • have the csproj in a different folder
  • edit the csproj to pick the files up from outside the tree, ideally using "../{ProjectName}/**/*.cs" so no more edits will be needed
    • (note you can do the same from project.json, but if you do that the IDE doesn’t show them, where-as this at least does)
  • accept the fact that adding new files via the csproj is a “no-no”

It is a bit of a faff.

Am I doing something insanely wrong here? I know csproj alongside project.json isn’t the ideal end goal, but we live in the real world where most people aren’t using pre-RC software ;p

About this issue

  • Original URL
  • State: closed
  • Created 9 years ago
  • Comments: 26 (17 by maintainers)

Commits related to this issue

Most upvoted comments

What’s the status on this? What should we be doing here? This is still a build blocker on porting projects with sanity. I currently can’t build with a project.json present unless I move the project/folder structure all over the place.

To explain the frustration, in preview 2 tooling today: I can’t maintain a .NET Core solution and a .csproj solution easily, they have to be put in their own corners. I can’t have just one solution because .csproj <-> .xproj still doesn’t work, and some projects just can’t be project.json. There’s not really much of a choice for porting libraries, it’s workarounds everywhere…and workarounds I’ll have to undo manually later.

The pitch for getting started on project.json now and migrating back to .csproj later is basically “it’s okay, you can just upgrade later”…well no I can’t, not if I had to move folder structures all around to work around this issue. IMO, this should be much higher priority if we’re still waiting many months for everything to go .csproj.

@livarcocc what does that even mean? This is not about customization, this is the fact that the current implementation breaks the *.csproj tooling if there is a project.json next to it. It’s not a feature, it’s a bug and one that causes friction for projects that are transitioning / for whatever reason need to support both formats

I have tried with NuGet 3.5.0.1484 (is this Beta 2? VSIX seems to think so), the issue remains. You can easily repro by pulling the core-rtm branch and trying to build StackExchange.Redis.sln (not the .Core solution). If you build StackExchange.Redis.Core.sln (or any project from dotnet), you’ll run into https://github.com/dotnet/cli/issues/1342 which I guess is never getting fixed either. I don’t think I’m being unrealistic or unfair in saying the tooling experience is extremely frustrating here.