Closed arlm closed 8 years ago
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.
sorry for the trouble you've had with it. It (or rather, the nuget tooling) certainly isn't perfect.
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.
@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.
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.
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.
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 usingproject.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: