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)
- (note you can do the same from
- 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
- move all projects to new *_Net451 folders: first step towards dnx-ing UCDArch is to create separate folders for legacy .csproj files. see Marc Gravell info on why .csproj and .xproj currently do not ... — committed to emhenn/UCDArch by emhenn 8 years ago
- Move csproj's into separate directories to avoid conflicts with project.json Issue related to having csproj and project.json in same directory - https://github.com/dotnet/corefx/issues/4544 Hat tip t... — committed to elastic/elasticsearch-net by russcam 8 years ago
- Add a separate csproj for .NET 4 tests because they don't play well with .NET Core. For more details see: https://github.com/dotnet/corefx/issues/4544#issuecomment-230272419 — committed to alexandrnikitin/NSubstitute by alexandrnikitin 8 years ago
- .NET Core support (#197) * Remove original NSubstitute project * Add dotnet core project * Remove unnecessary meta info * Add Castle.Core as dependency * Move dependencies under dontnet c... — committed to nsubstitute/NSubstitute by alexandrnikitin 8 years ago
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 aproject.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 formatsI 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 buildStackExchange.Redis.Core.sln
(or any project fromdotnet
), 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.