I suggest you ...

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.

527 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Ben CollinsBen Collins shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    10 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Anonymous commented  ·   ·  Flag as inappropriate

        @Immo Landwerth

        (4) Only having to specify excluded files (including *\**\*.cs) and avoid merge problems when dealing with multiple branches.

      • Adam RalphAdam Ralph commented  ·   ·  Flag as inappropriate

        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 SchierboomErik Schierboom commented  ·   ·  Flag as inappropriate

        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.

      • JackJack commented  ·   ·  Flag as inappropriate

        @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.

      • AnonymousAnonymous commented  ·   ·  Flag as inappropriate

        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.

      • AlxandrAlxandr commented  ·   ·  Flag as inappropriate

        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]Immo Landwerth [MSFT] commented  ·   ·  Flag as inappropriate

        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 SmithEric Smith commented  ·   ·  Flag as inappropriate

        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 AllenJonathan Allen commented  ·   ·  Flag as inappropriate

        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.

      • AlxandrAlxandr commented  ·   ·  Flag as inappropriate

        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.

      Feedback and Knowledge Base