support project.json/global.json for all project types, not just ASP.NET
As demonstrated at TechEd, ASP.NET vNext projects support a new Nuget mechanism whereby packages are organized in a by-project project.json file. Also of particular interest is the ability to override the package with local sources in a solution file called global.json, which facilitates a much smoother way to contribute to projects outside the solution. Please do this for all project types.
jsonp will be throwed out
See Q4 plan
Neil Glover commented
Hot swapping packages for source code would be great.
Don't do this, keeping configs in .json is like moving back, to era where there was no xml and schema definitions.
I've got it working for normal .NET class libraries by adding the msbuild project property <TargetPlatformIdentifier>Windows</TargetPlatformIdentifier>
and adding a project.json file e.g.
This is obvious.
Developer should decide what kind of files he want in the project.
Not project template designers.
Søren Nguyen Boisen commented
Making a project format that only works with ASP.NET makes very little sense. It should definitely be used for all project types, since all project types would benefit from it.
The current list-all-source-files behavior is a major pain point, since it guarantees lots of nasty merge conflicts even for small teams.
Ben Collins commented
@Immo - I agree that (1) isn't very important. (2) is important, but (3) is even more important. Also, within (3) I highlighted this: "...the ability to override the package with local sources in a solution file called global.json, which facilitates a much smoother way to contribute to projects outside the solution." The point here is to be able to right-click on a nuget package and replace it with version-controlled sources (references intact and everything). One of my pain points right now is if I'm using some nuget package and want to fix or contribute something, it's very painful to set up a dev environment that will let me do that.
(4) Only having to specify excluded files (including *\**\*.cs) and avoid merge problems when dealing with multiple branches.
Adam Ralph commented
Is this not just chipping away at a larger desire for all of .NET to go the way of vNext?
vNext is taking most aspects of the ecosystem to the place they should be, not just with project.json.
Erik Schierboom commented
The feature I like best about this is the fact that only excluded files are included. This would save me so much time not having to deal with merge conflicts.
I also prefer JSON to XML, but to me that's secondary.
@Immo In addition to the comments of others, I'd add the following two points:
- I don't think the file being JSON rather than XML is trivial. JSON is much less verbose and easier to write than XML. They also *already* have Intellisense for the project.json file. As far as I'm aware there has never been Intellisense for the csproj file.
- You guys should aim for consistency. If ASP .NET is doing this and it's working out well (which it seems to be), we should work towards doing it everywhere. It would be really weird if ASP .NET develops a new project system and the rest of .NET gets left behind.
Immo: The biggest issues the project.json file fixes are :
1) They specify what to reference not how. For internal projects referencing other internal projects, I should be able to say what projects I reference but not be forced to say whether it is a binary reference from my build server or a source reference from my local drive. I think nuget config may need to be upgraded to allow scoped references to make this address common use cases. For example, I may have multiple working directories on my machine, looking at different branches of an internal repository. I'd like to reference a project in the same working directory, if it exists, in preference to going to my nuget servers.
2) The current project system for csproj et al requires that I reference the transitive closure of references of project or binary references. project.json fixes that nicely, showing references as a tree. This is particular important for project (rather than binary) references in csprojs. I may have to update a ton of sln files if I update a dependency in a core libary, so that the right stuff will get built.
In my opinion, after having played with this for a while, the biggest advantages are the following:
1. Instead of listing assemblies as dependencies, you list packages. At first this might not seem like a big thing, but the implications could be fairly large. An assembly as of today, is either platform specific, or a PCL library. If today I want to make something that works on both say net45 and mobile, assuming that the code is identical, I have to create 2 project files, and keep both in sync. Whereas with the new project structure, it's possible to have one project file that targets both platforms.
2. The new project system allows for hot-swapping packages with sources. If you run into a problem because "MyLib" contains a bug, you can download the sources somewhere (if it's open source) and point to them, and your app will use the sources instead of the package.
Immo Landwerth [MSFT] commented
Ben, can you qualify what exactly you want to see so that we can prioritize? As far as I can tell project.json is different from MSBuild based projects by these three elements:
(1) Encoding is JSON instead of XML
(2) The JSON file doesn't list the source files
(3) Unified model for referencing projects, binaries and NuGet packages
I believe (1) is mostly uninteresting to folks; I believe we could support (2) and (3) while still maintaining the MSBuild based file format.
(Please note that I don't work on the VS project & build team but on the .NET team. So I'm merely providing an opinion on how to phrase the feature request.)
Eric Smith commented
This is an entire new project system that is much cleaner and simpler than csproj files. Not just a NuGet package references change. I can't think of any other IDE's that make you specify each individual file in the project. Doing so causes constant merge conflicts and in general just seems really silly to have to do.
Jonathan Allen commented
What a stupid idea. In case you haven't noticed, XML parsers are available for Linux and OSX machines as well. This is just change for the sake of change.
The other benefit is the ability to write code once and compile to many more targets with much more ease. This would be really great feature to have.