Hacker News Reader

Comment by troygoode | Hacker News Reader

Finally switching away from the horrible XML-based CSPROJ files to a more sane JSON format (that hopefully doesn't require you to list every. single. file. individually) is the feature I'd be most excited about if I was still using .NET.

I recall CSPROJ files being the primary source of pain for me as I started to transition out of the Microsoft world and into the open source world, as it prevents you from using editors like vim & emacs if you're working in a team environment.

View on HN

Finally switching away from the horrible XML-based CSPROJ files to a more sane JSON format

This comment strikes me as a bit odd. While Csproj-files were never pretty they were XML, they were structured and they last but not least: they were mergeable.

Contrast that to the actually horrible file-format that is SLN-files. Yes, it's plaintext, but it has projects named and numbered in sequential order, meaning doing any sort of merge or multibranch development is impossible unless you manually recreate all changes done to SLN files in all branches.

Microsoft going ahead and "fixing" CSPROJ-files, and not SLN-files is just madness. Consider me disappointed.

SLN files are also horrible, I agree. Fortunately you don't have to frequently edit SLN files, unlike CSPROJ files (which are currently edited anytime you add/remove a file from the project). Both should be changed, but CSPROJ is what kept me from developing in vim during my day job back when I was making the shift. Me circa 2007 really wishes I had a JSON format without individual file entires...

(Also CSProj files aren't super fun to merge using git and change very frequently. See: http://stackoverflow.com/questions/13479294/why-are-my-cspro...)

I'm actually a little bit disappointed in the switch. The existing tooling around msbuild projects is great. The only "problem" is that by default Visual Studio adds item references each individual file instead.

Ideally the csproj file should rarely become modified. Talk to any team of more than 2 developers and they'll confirm that pain of dealing with mundane csproj conflicts.

As far as XML versus JSON, I really don't care at all since I don't intend on looking at them or modifying them every day.

Agreed that individual item references is the primary evil for this file.

Now that they're rolling packages.json into the project file you'll be editing it more frequently than you might think. (Though most Microsoft ecosystem developers will likely prefer to use a GUI of some sort to do so.)

You actually don't have to list every single file in a csproj. You can use this MSBuild syntax to include all file recursively:

  <Compile Include=".\**\*.cs" />

The downside is that VS doesn't automatically pick up on the file system event notifications in that case, so you have to unload/reload the project whenever a file gets added.

I imagine that if you do that, and then add files from within Visual Studio, it'll rewrite the csproj file with the individual file references. My company has had a fair share of csproj file pain caused by Visual Studio not understanding everything that's possible in csproj files. In our case we like to import some variables that give the install path and version number of our core libraries and we use those in Reference elements, but Visual Studio won't show the variables in the GUI and provides no way to add a new reference that uses the variables through the GUI. If you add a reference, you have to follow-up by hand-editing the csproj file, and it's easy to mess that up.

No, not exactly. In my experience, if you have the recursive wildcard in there and then add a new file from within VS, it'll put it in as an explicit entry next to the implicit wildcard. Then, next time you open the project, it'll import the file twice (once via the wildcard and once explicitly) and fail to build because "your class is defined twice."

I've always found it weird that they don't fix this, especially given how easy the fix seems to be:

1. When a file is added, VS could re-run the wildcard matches to see if they match the new file. If they do, don't add an explicit entry.

2. VS could turn the file list into a unique file list before passing it to the compiler.

Can you elaborate on why a json format would be better for a csproj ?

I have issues with the .csproj also, but I don't think json would fix anything, my issue is usually with visual studio and the confguration manager not applying changes...

For me - it'll be reading it.

I have to deal quite often with "Unload Project file" in MSVC IDE, edit by hand, "Load again" - because no matter how good the IDE is (and Visual Studio is a good IDE overall) there are lots of edge cases where it fails (merging multiple settings per project / per configuration / etc.)

re: readability

project.json (.csproj/packages.config/nuspec file replacement) has been unveiled:

https://github.com/aspnet/DependencyInjection/blob/dev/src/M...

re: load/unload process

VSCommands Pro Extension adds the ability to right click on a project to automate the unload, edit, reload cycle and offers editing inline.

http://visualstudiogallery.msdn.microsoft.com/c6d1c265-7007-...

I personally find the human readability of JSON to be superior to XML in this kind of configuration scenario, but I think what I really meant to say was that switching to JSON hopefully provides them the opportunity to redesign the file format from the ground up to be more sane. My specific hopes:

1) That the new format will be more convention-over-configuration based and not have to be 100+ lines for a default project.

2) As I've mentioned in the parent post, I hope that you don't have to list individual files in the equivalent of <ItemGroup> blocks - you should instead only need to add an exceptions to whatever convention is being applied.

Readability when not using VS, for one. If you're rolling your own csproj (or need to edit it) to use with MSBuild, or some other build system, JSON is easier to read than XML.

Have you tried merging a JSON file? XML is a shit ton easier. I can't see this as a good thing.

If they get rid of the need to list every single file you won't have the huge number of merge conflicts that CSProj files currently produce.

And msbuild will no longer work.

I agree with you though - its a PITA.

I assume they'll be updating MSBuild to work with the new format.

Re: listing every file

How do you think they will get around that? Just include a directory? Not that this will affect me much because I'm almost never in .csproj files because the IDE (Visual Studio) does 99% of things for me.

Yes, just wildcard include all *.cs files. You'll still have to list any potential embedded resources explicitly in your CSPROJ, as well as list any exceptions (please don't compile example.cs, for instance), but why add each and every .cs file to the CSProj explicitly?

This may actually take longer than having a line item for each file, consider:

> Visual Studio, please open all *.cs files in this directory (recursive)

vs.

> Visual Studio, open all of these files

Also, by itemizing each file you can exclude single files from build easier.

This is all speculation.

EDIT: Also, I think they did this because they didn't expect users to be mucking around in .csproj files.

Visual Studio doesn't open all of the *.cs files listed in the CSProj file, they're only pulled in by MSBuild while building. Also MSBuild supports wildcards today and it is plenty fast - it is just Visual Studio that screws it up.

As far as "exclude single files from build easier"... if you want to optimize for that why not invert the paradigm? Instead of listing every file that IS included, list the ones that aren't.

Valid points. We'll see what they do!

We will support both inclusive and exclusive patterns.

Reply on news.ycombinator.com