Should we keep using project.json?

[arlm]

It came to my knowledge that project.json files will be deprecated in favor of MSBuild. Does it make sense for us to maintain those on our code? I have had a pretty hard time setting up new projects using project.json because support for some features is poor or lacking on Visual Studio (like the parent suppression on dependencies or other attributes on dependencies other than the version number only).

So I ask: Should we keep it at all?

---

Some references for discussion:

• From .NET Core team public roadmap:

Q4 2016 / Q1 2017

This will be the first minor update, mainly focused on replacing .xproj/project.json with .csproj/MSBuild. Project format update should be automatic. Just opening a 1.0 project will update it to the new project format.

• From InfoQ article ".NET Core Plans to Drop project.json":

Starting in .NET Core RTM/tooling preview 2, Visual Studio will automatically rename .xproj files as .csproj. However, the project.json’s functionality won’t change just yet.

After preview 2, Microsoft will start working on moving project.json’s functionality into csproj. Some of that will simply require updating Visual Studio. For example, .csproj already support wildcards, even though Visual Studio insists on adding source files one by one. Other features of project.json may require significantly more work to integrate into .csproj.

At the end of this process, project.json may only exist as an alternative to Nuget’s packages.config file. If that happens, it will probably be renamed to nuget.json.

• Discussions on the migration and suggestions on this process can be done on [Discussion] Project dependency after project.json phase out aspnetcore#1433

[AArnott]

Absolutely keep it -- for now.
I happen to be friends with several folks on the team making these decisions. And while we all agree on the deprecation of project.json, it hasn't happened yet. There is no better alternative. packages.config is quite poor for a variety of reasons.
When the MSBuild alternative is ready, yes we'll switch to it.

[AArnott]

sorry for the trouble you've had with it. It (or rather, the nuget tooling) certainly isn't perfect.

[arlm]

Cool. No problem. The problems I had were never with nuget, these worked flawlessly. It was mainly on Visual Studio v14 IDE on the Portable Projects general properties. It just states that JSON deserializing has wrong information after the dependency package version number (when it has the array with other options instead of just the version string).

So I took it out from the two projects I created.

[AArnott]

@arlm: what exactly did you take out? The fields in the package dependency beyond the version number itself is important. Although it may seem alright when you remove it, it has subtle and broken behaviors elsewhere when you remove it.

[arlm]

I came to this conclusion when I tried to understand what was the problem and which were the implications of taking that parameters out. That lead me to take out project.json completely and look for an alternative solution using package.config and MSBuild.

The thing that was giving me headaches was a suppressParent option, I replaced it for a less versatile version on package.config using the developmentDependency option. I think it don't have exactly the same effect but seemed to be the most similar option to use with package.config/MSBuild. We had that on our project.json dependencies for code analysis only, and as far as I understood the options is there to tell NuGet not to pack that as dependency on the final packages.

[AArnott]

I'm afraid your understanding of the behavior of suppressParent is incorrect. It has nothing to do with developmentDependency.

In packages.config developmentDependency prevents it being seen as a dependency in other packages, as you say. This attribute is added to packages.config automatically if a package's .nuspec file has a <DevelopmentDependency>true</DevelopmentDependency> tag.

In project.json, this XML tag in the .nuspec file is still respected, but it has no representation in the project.json file. It isn't necessary.

In project.json, dependencies automatically propagate across project references (regardless of the value of developmentDependency in the .nuspec file.) But MSBuild imports offered by a NuGet package does not automatically propagate. They are suppressed by default. To ensure they propagate across P2P references, suppressParent: none tells NuGet to not suppress MSBuild imports from propagation.