This post was written by Scott Hunter.
Last week we announced the schedule for RC2 / RTM of .NET Core and ASP.NET. Now that we have shipped RC2 I want to give more details on the .NET Core tooling moving from .xproj / project.json to .csproj / MSBuild.
MSBuild
When the ASP.NET team started building ASP.NET 5 (now ASP.NET Core) one of the key goals was to design it so it was very easy to create and develop on Windows, Mac and Linux. This led to the creation of the .xproj/project.json based project system. Some of the key features were:
- No listing of files in the project file
- Easily modify project definition without an IDE
- Can produce a Nuget package directly from the project
- Cross compile a project to multiple target frameworks
- Easily switch package reference with project source
As we continued to the project we kept expanding the role of .NET Core:
- .NET Core became the platform for Universal Windows Applications (UWP)
- .NET Core evolved with a new cross platform tool chain for building Console and Class Libraries
- Microsoft acquired Xamarin enabling .NET developers to build iOS and Android apps
How does this affect project.json? One of the key tenets of .NET as a platform is we want our developers to be able to share code across all of the .NET application models (WinForms, WPF, UWP, ASP.NET, iOS, Android, etc.). This presented a series of problems, while project.json was great for building web applications and class libraries, it did not allow unification of the other app models.
We had two choices. One was to move all .NET projects to use project.json. This would require us doing tooling work that touches all of the project types in Visual Studio, Xamarin and our partners like Unity. We would have to expand project.json to support all the build scenarios required by each of these project types and provide a migration story. Another choice was to build bridges so an .xproj project can reference a .csproj project and a .csproj project can reference an .xproj project in Visual Studio and Xamarin Studio. The bridge has challenges as well, for example when a customer creates a project they would now have to choose an .xproj or a .csproj, which just adds more choices and complexity.
After looking at our choices, it was apparent that it would be easier to move .NET Core projects to .csproj/MSBuild so all .NET projects use the same tooling and build system.
But at the same time we don’t plan to give up the benefits of project.json. We plan to enhance .csproj to support the missing functionality:
- No listing of files in the project system
- CLI tool for doing any operations on the project file, for most scenarios you would not edit the file
- Build packages directly from the project
- Multi-targeting
And because all of .NET uses the same tooling, we can then look at enhancing MSBuild. We will solicit feedback from customers and the community on supporting JSON instead of XML, having our tooling not generate overly verbose files and more. And because everything uses the same tooling, these enhancements could work on all .NET projects.
The first wave of this change will happen in the Visual Studio “15” RTM: when opening any .NET Core project in Visual Studio, it will automatically convert from .xproj to .csproj, moving the assets from the project.json file into configuration files and the .csproj file. We will also provide a tool for converting applications using the .NET command line tools as well.
The next wave will happen after Visual Studio “15” and will be focused on furthering improving the project and build experience.
Developing in the Open
.NET Core and ASP.NET Core are the first .NET projects that we have fully developed in the open. Traditionally you would not see all the changes as the team is experimenting to build the best product. We are trying to find the right balance of transparency between GitHub, the community standup and even this blog. Moving forward we will try and announce major changes via the blog first as we can provide more context on what is changing and why.
What’s Next
Next week we will blog about the .NET Standard which is how we plan to make it easier to share code across .NET projects.
Scott Hunter – .NET Team
Hi,
What about NuGet packages? Will installing a package still add an explicit assembly reference in the .csproj?
I really wish that NuGet packages would be part of .csproj like this:
And then NuGet.targets behind the scenes would add reference to .dll file… Preferably from some global NuGet packages repository folder which is immutable…(mostly for crazy good performance when restoring packages + for sharing .csproj(git submodule) between different .sln files which currently causes headaches because fixed HintPaths)
So we can remove also packages.config which is weird thing from start and unnatural in msbuild environment.
Comments formatter ate my code sample so here is link:
https://gist.githubusercontent.com/DavidKarlas/69fd92e23ff9b46199980870afbda597/raw/758ef49e007ac406dc7f05551aff1a95a1defc87/gistfile1.txt
Please see https://github.com/aspnet/Home/issues/1433#issuecomment-220825164
I’m for baking a reference, but that should be done with good documentation to plug other dependency manager (because nuget falls short at doing a good job at this, at least from perspective of many users) and not take the stance of calling that which would alienate alternatives.
Also, for those that use nuget as a dependency manager, it would be great for the solution which will be implemented to not carry all the drawbacks of both packages.config and project.json.
Xml tags get stripped out of comments how cool 🙂
“for baking a [NuGet] reference”
“of calling that [Package] which ”
replace [ ] with the angle brackets.
Ought to be fixed some day in the comment system, or at least, avoid the comment to be posted and ask client to rephrase comment due to some restriction…
Nuget packages s do not necessarily add references to projects. E.g. Bootstrap, jQuery etc. don’t do that. Although there is an option like bower, such packages are there or variety of project types. We need custom actions via .ps1 files. I don’t think adding a reference is default action that can be merged into .csproj.
One of the major reasons for the creation of project.json was to have an IDE agnostic way of configuring a project so that the project could be loaded in external tools (i.e. VS Code). What does this change mean for tools such as VS Code? Will they need to support csproj and MSBuild now? I see this as a major drawback!
Per the blog post we will provide CLI commands to let you configure your application independent of an IDE. You will not lose this functionality.
I don’t know if this is how it is meant to come off or not but my take away is that we’re back to needing a tool to configure our project because csproj sucks to deal with. If I need a tool just to deal with the project system, maybe simplify csproj? If you ignore xproj and just look at project.json, the reason it was nice was that it was simple. I could open a file, make some changes, and rebuild without issues. Where as the csproj story in the blog post above sounds like “Look, it’s so complicated in that thing, you don’t want to touch it. Let our tool do it. It will just be easier.” I’m just worried because making the experience seem harder to devs, even if it isn’t, makes it a lot harder for those of us that want to push for this in our orgs to make the case to the rest of our team.
Hey James,
Thanks for the feedback. We have intentions to make working with csproj as easier as it was with working with project.json, such as being able to edit the project file without unloading, simplifying the project format and adding proper *.cs support. Come join the conversation: https://github.com/dotnet/roslyn-project-system.
Dave
Thanks for the link. I was looking in the MSBuild repo to see where the discussion was taking place.
Well, this news is really a let down. About the CLI commands: is it just me or is the sample with npm install –save lacking the part where that even if that’s you often do, there are also so many times you go editing the json as well. Or is it just me? Editing csproj and sln files always sucks. Tools always fail to get things right some times. VS still often fails and you have to go in and dig in the sln/csproj, not funny. Project.json was a sign of you moving forward and simplifying (even if json lacked comments). The gut feeling is that this is an old microsoft move, loving the monolith, the thing that should handle and be good at everything. But that’s just my guts telling me to look at alternatives, hoping it will tell me something else when dotnetcore stabilizes and shows me this move was a one time thing since. Maybe community can create their own better and easier project solution to dotnetcore in the future.
Why still csproj ? Make new dnproj (dot net project), where we can mix multiple languages (c#, vb, F#, even c++/CLI and others) that generates managed execs/libraries. I prefer xml over json.
We are definitely looking for feedback of what the project system should supporting moving forward. Thanks for the feedback.
No you are not, if you really looking for the feedback you would stop and announce that you put this shit idea into unrecyclable bin already. No one love garbage format like xml. And all human developer would like to use a human readable format
At least you could make a tool to convert csproj into project.json
You cannot deal with simple .csproj file? What kind of dev are you? Not really smart it seems.
Digging the .dnproj name! It would be great to see the new project system use a POCO-based system/approach that allows developers to “bring your own serializer”, thereby supporting any format (JSON, XML, Xaml, Yaml, Toml, etc), and allowing them to describe/define their project file in the tool in which they feel the most familiar/powerful/comfortable.
Please join (or upvote) the discussion here:
https://github.com/dotnet/roslyn-project-system/issues/37
.netproj then because .dnproj is spelled “dot dnproj” 🙂
EVEN BETTER!!!
You have no idea how much I love that name.
I agree .netproj makes a lot of sense. but you’d have to specify what language in the file because of F# and VB
“I prefer xml over json.”
In much the same way, I prefer sticking razor blades into the corners of my eyes to ice-cream.
Sticking ice-cream on the corners of your eyes can be quite painful
That comment made my day, thanks! XD
I think d Adobe core team and .netcore team have done very well so far but even though I get d reasoning behind going back to csproj msbuild project format, I still don’t like this decision. We were made 2 understand by y’all d woes of csproj based projects, somethings I have experienced myself, and to go back feels “yucky”. We shud b sticking wit project.json xproj until you guys can either make csproj json or something. So what happens to yo aspnet generated projects which don’t come with csproj? Sorry but i think this ain’t the right move.
This is just my humble opinion.
I’d totally have to agree with this. One thing I can appreciate more than anything is the JSON formatting itself. It feels much more seamless working with NPM and this. It limits the amount of time developers have to ramp up on getting a project going on Mac and Linux, who are coming from the client-side discipline. It’s almost close to a universal formatting and I feel like it reads significantly nicer than XML. Lastly is the merge conflicts with Git. I feel like a lot less uneasy about trying to merge a JSON file versus an XML one. God help you if you forget a “>” anywhere.
This is .NET, not Node, I think Microsoft should not forget this. The same thing could be said about curly braces that you said about angle brackets.
I agree with Jim. They can borrow new techniques and improvements from the node community but If people wanted node features, they’d use Node. Don’t forget Node/JavaScript are first class citizens in Microsoft’s Stack whether Azure or UWP. DotNet is a great platform, lets not try to shoe horn it to become Node
You should not forget we also have one line block without brace and lambda expression
awesome. xproj was a slow trainwreck. it was one of the major reasons i delayed adopting core. glad to see this moving in the right direction.
ooh, wait. missed the fine print. “No listing of files in the project system”. what?? where else do you put your list of project files, than in the project file? please do not go back to the old “web”-based projects of yesteryear that were broken by design.
we want explicit control of files in our projects, the ability to create symbolic links, etc.
I agree. The best way would be to choose whether to include file listing or not (all files by default). However, “symbolic links” is a must have feature for such a serious build system. Please dont kill it…
You could go with glob patterns. We can list each file, or a glob to all the files, and specify a file in a completely different folder, having the link file behavior. Though I still prefer the JSON.NET format.
If we could have a little less of the msbuild syntax I would be happy though, even if it was XML.
JSON, not JSON.NET. Autocorrect got me 🙁
Really glad to see I am not the only one here that appreciates this approach.
Coming from the Java world I was totally confused on why a .csproj lists all the files that are compiled. In an Eclipse-based Java project all .java files in a src folder are automatically added into the Project Explorer (same as Solution Explorer in VS). There is no need to right-click on the project and select “Add Item”. When I want to exclude .java files from compilation I can do so by explicitly excluding it. This information will then be added to the project file. So you are not loosing any functionality but you gain a cleaner project file.
IMHO, the Java way of organizing projects is easier. Especially for build automation.
You don’t have a list of files included, but you do have a list of files excluded….
So, instead of defining what the project IS, your project file only defines what the project ISN’T.
That’s dumb….
10, 20, 30, 50+ lines declaring what *is* in your project vs a few lines saying what isn’t? Seems quite sensible to me. And makes merging that much easier.
You’ve already said what your project is when you put your source code files in a src/ or similar folder. Why would you put .cs or .fs files inside a source folder if you did not intend to compile them?
It makes more sense to me to say “compile everything in the source folder”, and then list some exceptions for stuff you actually do not want compiled for whatever reason. This is also the behavior of just about every other modern build system out there.
Do you want a .gitinclude instead of a .gitignore as well?
> Visual Studio will automatically convert from .xproj to .csproj, moving the assets from the project.json file into configuration files and the .csproj file.
Assuming that .csproj still means C# Project, there will of course be other targets for non-C# projects, correct?
Yes.
“The first wave of this change will happen in the Visual Studio “15” RTM when opening any .NET Core project in Visual Studio will automatically convert from .xproj to .csproj”
Sounds like VS “15” won’t support round tripping them? If – for .NET Core – VS2015 speaks “xproj” and VS “15” speaks “csproj”.
When this was originally announced almost two weeks ago, it was mention that in a week or so it there would be a blog post with an example of what the newly enhanced csproj *might* look like. Any update on that?
Sheesh. Sorry for the poor grammar.
We have a working group on this now, I will try to share as soon as we can.
Great! Thank you for the update.
Let’s rush them so they can trip up again and have to change things around yet again… People need to chill and stop developing on alpha software and wondering why things don’t work or change out from under them. I guess it is no longer possible or cool to develop software on whatever is currently RTM. And demanding solutions to problems in as of yet unfinished unreleased software.
Except the current bits are release candidates…
From day one, I’ve spent lots of time to learn dnx, dnu and dnvm tools, then CLI when .Net team decided to retire dnx toolchain. I now know project.json and it’s going away.
I still don’t understand how you came up with such a complex dnx tool and Net CLI makes sense. I do hope new csproj will make developers life easier. I’ve had tough time to get correct and latest version of a package using vscode\project.json
This is disappointing. The fact that you need command line tools to edit the project file means it is still not human readable, and we are stuck with this format for another decade by the look of it. While it is a mildly annoying to merge project files from time to time, it is ridiculously difficult to incorporate any custom logic in the current MSBuild scripts. In fact, most of my colleagues don’t dare to comprehend the project file it might as well be a binary format.
Never half-bake a solution.
Sadly it’s really a mess. If I’m having too much trouble I back up the files, delete the project file and add the files back. Still sticks though.
Why not just change the extension of the project.json to something the other projects understand and everyone is happy? We can reference old projects, and vice versa and keep the more human readable and most liked project format by everyone
With you on this one – I don’t do cross-platform development but one of my hopes was that Microsoft getting into that space would lead away from project files that require a tool to edit, and one of the reasons was that it should be more obvious how to incorporate custom build logic, and also see what custom build logic is in play to help diagnose problems.
Another reason is being able to compare project files using whatever diffing tools you like. Too often the process goes like this:
1) Realise I need to make a change in the project file
2) Open the project properties, click some ‘magic nonsense’ button that does who knows what
3) Now, to review my changes, I open my diffing tool and OH MY EYES IT BURNS!
There is a uservoice entry about replacing this system with something more appropriate (though whether XAML is the best choice is up for all manner of debate!):
https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/9347001-improve-reboot-visual-studio-project-system
On the other hand, I have seen worse project systems than Visual Studio. Installshield, I’m looking at you!
This is such a huge step back
“The first wave of this change will happen in the Visual Studio “15” RTM when opening any .NET Core project in Visual Studio will automatically convert from .xproj to .csproj, moving the assets from the project.json file into configuration files and the .csproj file.”
Does this mean the tooling support won’t come for VS2015, and only for VS”15″?
Make .NET Core great again!
LOL! BTW there is a GREAT thread here if you want to get a grasp on the sentiment pros and cons:
https://github.com/aspnet/Home/issues/1433
Why not keeping them side by side?
Web devs in VS and VS Code will use project.json and all others will use .csproj
If you do the conversion first time you open a project, why not doing it all times?
I suspect this comes down to limited resources. The .Net teams only have so many people, and supporting one more feature is going to take more resources away from something else.
The other issue mentioned in the article is the choice when creating a new project. You really shouldn’t need to ask “do you want your project stored in file type A, or in file type B?” when they really end up doing the same thing.
I understand you have your strong reasons to do that, but I’m also glad to read that you’re aiming to keep some of the features from project.json. Mainly I’m thinking about not listing all project files in csproj, which I think is a great idea which you can appreciate after you spend some time with Node, Python and other development platforms. It’s just nice not having to explicitly list files in your project, the directory IS your project, you have less merge conflicts (quite common in big csproj projects), less ceremony and also you get better experience when you want to use your preferred editor and/or command line tools.
BTW. I’d still prefer JSON, but I can take XML too, cause the main pain points are not the syntax, it’s how you use it 🙂
Hi,
What about projects that use .csproj and only use project.json as a “packages.config” substitute? Will that be auto-converted with VS’15’ as well?
The Packages Management part is, for me at least, the most important part of the adoption of project.json. Too many important features, we need to have that on .csproj/vNextproj
I guess one example of what you’re talking about would be UWP apps right? You don’t really have anything to change in project.json except when referencing packages and it uses csproj still.
I do like being able to add packages from project.json and agree it’s one of the most important parts for me, it’s a lot quicker than using the Nuget Explorer to search. I find intellisense in project.jscon much quicker than either the NuGet Package Explorer GUI or trying to remember the exact package name for Package Manager Command Prompt.
What is the likely story with global.json?
Global.json current allows me a few things:
1. Settings which SDK to use for DNX – this is now obselete as .NET Core doesn’t handle side-by-side runtimes like DNX did.
2. Setting the path for projects, e.g.:
“projects”: [ “src”, “samples”, “test”, “C:\\path\\to\\other\\projects” ]
I’d be very interested to know if it will still be possible to include project paths for NuGet packages to allow me to build using a package reference that I resolve to a local project path. This is massively powerful and aids to a lot of debugging scenarios.
Will this still be supported in new-MSBuild?
Moving away from the unreadable formats of csproj and xproj is one of the better things done in .net core. Moving back towards it would be a big miss from my view. You’re trying to satisfy existing users, but will scare away new users to the language and platform.
I’m not sure we need msbuild either. I’ve been a big user of MsBuild in classic .net but so far haven’t seen any need for it with the .net core development because the command line tooling is so much better. Adding some more wildcard options to the dotnet cli will take care of most scenarios you would otherwise have to resort to msbuild for.
For example
dotnet test test/*.UnitTests
could be used to run all “projects” with their name ending with UnitTests.
A bullet dodged I’d say!
JSON is awful for hand editing. Can’t have comments! Addition of 1 array element modifies 2 elements in git diff. It’s not even current JS object syntax, but an old subset limited to what IE6 could parse.
I love JSON for APIs (except ones that use dates), but JSON is not a good choice for anything that humans may want to edit manually.
You are saying that you will be working on: “No listing of files in the project file”. As far as I understand MSBuild already supports this. I’m not sure about VS. Can you elaborate?
It’s interesting that you see innovation in ASP.NET, then “expand” where you want it to be, then decide that it’s too expanded and can’t do it the way it was innovated, then de-innovate it back to the old tools, just for the sake of compatibility. Rather than allow one project to remain focused on what it does well, the one size fits all approach is being seen as a big blow to progress. What this shows is that while you say “it’s all been developed in the open”, it really hasn’t been. Someone has been making these decisions not in the open – I’m not suggesting that they be put up for a vote, but they should have been put up for community involvement a long time ago, where the community could have made decisions about what might be the best way to move forward to accomplish the goals being set out here. I think there is more power and more desire than you realize to make this great going forward, but alone and in an isolated environment (it seems like), the decision feels like moving backward, even if you’re going to incrementally improve some of the tools using some of the lessons learned from a smaller, more focused projects like ASP.NET.
I’m quite disappointed that the feedback from the community on this proposed change has been ignored. It’s a step backwards, it forces us to use an unpopular and complicated MSBuild when we currently have a very acceptable build tool in dotnet build for 90% of ASP.NET projects. There is a clear problem with conflating the build definition and the project definition, as happens in csproj currently.
Out of 390 surveyed developers, 283 think moving back to MSBuild is a bad idea, and 180 believe it is such a bad idea that it’s making them question the entire direction of .NET Core.
It does not appear that sufficient alternatives have been considered in this decision. Keeping existing dotnet build side by side with msbuild, making dotnet build configurable in which build it runs (like dotnet test), none of these appear to have been seriously considered. Well, at least from any information that has been provided so far.
The way this has been handled and dealt with also gives me grave concerns with the maturity of the decision making processes in place within the .NET Team. Surely it should have been anticipated how unpopular this move would be? The fact that the team was caught apparently blind-sided by the strength of the opposition proves that insufficient thought was given to the consequences of this decision.
Surely, when faced with clear evidence that you misjudged a decision in at least one dimension, you reconsider the decision? Well, that’s the way I was taught. Doubling down with your decision when faced with new information is a defensive move indicating a lack of confidence in the decision.
If you were truly confident in the quality of the decision, you would reopen it and discuss it openly, rather than presenting it as a fait accompli. The lack of this engagement is a clear indication of the lack of confidence on the correctness of the decision OR a complete lack of transparency in providing the basis for the decision. Neither of these bodes well for the future of .NET.
This is RTM in 5 weeks. I can’t imagine that most developers-if faced with the option of 1.0 in June w/o project.json or a complete retooling of all the project types listed in this post in… September? October?-would choose to wait. I’m not trying to be confrontational and I have read and agree with many of your points in your Github issue, but I think it’s time to let this one go. It isn’t going to undo the improvements in the language, the framework, or anything that 99% of developers are concerned with 99% of the time. Configuring your build/CI systems is one-and-done maybe a few times/yr. It sounds like many of the nice project.json features will make it into the csproj, you won’t have to hand edit the project file, and you won’t have to struggle merging the file at every commit/push… It will change less frequently.
Haha @ Scott Holodak… it’s funny you request to “let it go” when really Sean has been yelling and screaming into an echo chamber without any official reply from the .NET team since the outset. This is really the first time that the .NET team can feel his pain along with the rest of us. 😛
And also… to answer your question… YES! The schedule should have been extended. Take a few more months and get it right. Rushing out the product happens way too frequently in our field and a focus should be given more to quality — even if that means extending the release by a few (even 6!) months, IMO.
As early adopters we live in an echo chamber. Would I like to wait for a perfect product before a realease? Maybe. But my employer has a business to run… And with 15 years invested in .NET I don’t want our next blue sky project to be stuck in the past because perfect didn’t happen yet. I’m sure MS is feeling this sentiment. If ASP.NET Core 1.0 has as much of a memory reduction and CPU performance improvement as has been shown in the benchmarks then the impact of now vs. later has real repercussions on things like budgets, server density, licensing costs, and even the environment. I am both hopeful and confident that once 1.0 is out, better will happen faster. Be patient.
@Sean
“Surely, when faced with clear evidence that you misjudged a decision in at least one dimension, you reconsider the decision? Well, that’s the way I was taught. Doubling down with your decision when faced with new information is a defensive move indicating a lack of confidence in the decision.”
I think the team was bitten by fact that MSFT is facing a big problem with .Net / Visual Studio: The MSFT business model was based on vendor-lockin for decades. For this reason, .Net and VS was deliberately tied to Windows. Much more than technically needed. As this business model started to fade, they changed direction towards platform neutrality. For this reason, they had to restart .Net including the tool chain from scratch.
Now every new approach has to be platform neutral and backwards compatible with technologies deliberately tied to Windows at the same time. Or they have to maintain both systems in parallel. I’m pretty sure MSFT management rejected the latter approach. So a lot of effort would have been needed to make project.json compatible with all the windows-locked legacy stuff (Forms, WPF, …). What obviously was rejected by management to.
My take on this: MSBuild was fine, because it was a working tool. You could just “msbuild myproject.csproj/sln” and it worked. My experience with building a .NET Core website from the command line has been… underwhelming. It requires a whole page of powershell. Maybe they will eventually get it to be as simple as “dotnet make” (or whatever they’re calling it), but right now it’s worse than it used to be, and I personally have gained nothing but trouble as a result. Having spent a couple of months working in this new ecosystem, I can honestly say I really hate it, because the old stuff Just Worked, and the new stuff is all a big broken mess. The tools are just not there yet.
I don’t get the hate on MSBuild _compared to project.json_. Just about the only comments I even _understand_ are “I can’t read .csproj files”, “I hate XML”, “I don’t like explicitly including every source file” and “other tools don’t support .csproj”.
Especially that last one gets me really upset. Do other tools happen to already support project.json? No, every third party tool needs to implement special support either way. I understand if they can’t parse complex .csproj files, but there’s a reason for it: .csproj supports advanced scenarios. Do we just drop such support completely and leave those using it in the cold? Fair enough, but third-party tools can already do that with .csproj files: parse the simple ones, and barf on the complex ones. This way at least I can use the advanced features if I stick with Visual Studio.
> a complete lack of transparency
This is it, and the decision-makers are to blame. CLI team members hardly reply other than their colleagues on GitHub and the amount of issues are growing rapidly. They need to build something like node.js Technical Steering Committee (TSC) for the entire dotnet echosystem with members from community, otherwise there will always be Microsoft bias in play, good ideas getting suppressed due to corporate lackey-ness and that will hinder the evolution of the entire platform.
Many have left dotnet community in past due to the lack of transparency and too much of over complications. Opting for simplicity and “truly” embracing the OSS is the only right way.
I have two observations:
1) Developers who are not already using Visual Studio are likely to judge the new build system based on how easy it is to use _outside_ Visual Studio and even outside Visual Code.
2) The “dotnet new’ command is going need a heck of a lot of options to support all the existing project types…
Huge step backwards… but I expect nothing less from an organization that is unable to post under the actual user who wrote the post.
I think project.json was the right step, and i was completly suprised that Microsoft decided on going back to csproj.
Stupid comparison but it felt like: Back to closed source!
Improve project.json, it is already by far more powerfull then then csproj, at least when it comes to nuget and that is where everyone is heading atm.
Why would you use a comment-less accidental wire-transfer format to represent project files to begin with? Because it “cool”?
How about keeping both project.json and .csproj, where .csproj is generated by the command “dotnet restore” and not synced in version control by default? The difference will be, instead of “dotnet restore” generating “project.lock.json” (and do other things), it will generate (or update) “.csproj” file. Even both “project.lock.json” and “.csproj” can stay as both are being auto generated. Flags can be used in “dotnet restore” for generating .csproj. You are already saying- “CLI tool for doing any operations on the project file, for most scenario’s you would not edit the file”. “dotnet restore” can be THAT CLI tool which will take project.json as an input. The upsides will be-
– Both formats of project.json and .csproj can stay unchanged. That means new generated .csproj will be compatible with earlier versions of Visual studio and other tools.
– As .csproj is being auto generated and not in version control, developers do not have to deal with hand editing and merging .csproj.
This is a huge step backwards. “We’re going to get rid of project.json but try to shoehorn some good parts of it back into the crappy old project files because we can’t make a decision.” This sounds like something from Dilbert.
Maybe I’m missing the point. But I was always wondering why MSFT emphased the JSON part of project.json
As .Net is supposed to be platform neutral now and Visual Studio is Windows only, a build system usable independent of VS is needed. I don’t really care if it is JSON or whatever text format. It must be easy to read, easy to understand and easy to edit. And it must provide a way to add comments (this is not debatable for manually edited files). And the existence of CLI tools to modify plain text JSON project files was nothing more than the confession they are still to complicated to be edited manually. Developers know how to edit structured text files. And if not, they should be kept away from any source code anyway 😉
Somehow MSFT missed the main problem we have with the current approach for Visual Studio in combination with source control: The project settings are not separated from the project file listing. So if a two developers remove or add a file, at least one of them has to manually merge the project file in text mode. Its easy to mess up the project file in this process and checking it in, as there is no feedback on project file validity while merging. At least not with VS and TFS.
So what’s needed is a possibility to separate project files from project settings, or – much better- include project files using wildcards and/or folder paths.
PS
I personally use GNU make also to build C#/.Net. It is well known, proofed to be suitable for large projects since decades, there is an active community and it is easy to share common settings among different projects (still pain in MSbuild). And it exist on almost all platforms.
Want to build the same solution for x86 and AMD64 without duplicating all project configurations for each CPU? Want to do a test build to a different output directory? Want to a test build targeting a different version of the .Net runtime without touching the project files? All of this – and much more – is easy. Just passing a parameter to your Makefile.
TOML TOML TOML for all hand edited files
Please take a second to add your upvote/feedback here, Chris:
https://github.com/dotnet/roslyn-project-system/issues/37
Thank you for any consideration and support!
OMG it looks line we are back in Windows 3.11 era and INI files. We are going backward only. There is nothing better than XML because of schema support and easy editing including intellisense using mature editor = Visual Studio. JSON is huge step back because of no schema (PHP kiddies don’t understand types) and that TOML thingy looks like INI files. What next, CSV ? Or punch tape ?
That’s the great thing about options and designing your product so that it can be serialized by any supported provider. You offload the concern of serialization/deserialization to an external provider/serializer and just focus on the model. MSFT has made a very prohibitive technical error here by tightly coupling the model (and their product products) to a particular format, and they are paying the price dearly for it now. It only takes two products to follow the same approach/strategy before your solutions are polluted with different files serialized in different data formats, and that is exactly what we have, unfortunately.
csproj/msbuild supports wildcards from the very beginning: https://msdn.microsoft.com/en-us/library/ms171454.aspx, so whats’ the deal?
Visual Studio even opens them without problems, so just fix VS to preserve it when saving
But, it’s not JavaScript!!! I need a waahburger with cries about now!!! I never figured out how to type an angle bracket.
Great to see you back on the right track! JSON was disappointing step back.
When I first heard about going back to csproj, I thought that someone is doing a bad joke.
project.json is simple, fast, modern.
Need new nuget? Simply add 1 line. Run dotnet restore and go.
Using bower? No problem. “PreRestore” script.
My dependency has a dependency? I do not care. Chain will resolve itself.
I almost didn’t need powershell scipts to manage and build my projects. I was so happy! But now you crushed my dreams 🙁
PS: I hope they will leave appsettings.json alone.
> PS: I hope they will leave appsettings.json alone.
The “appsettings.json” is part of the configuration framework, which could deal with arbitrary formats before already. You can use json, xml, json5, or whatever you want. You just need a deserializer.
I was really liking the ability to modify project files without having to unload the project. Please don’t lose that! I also liked the ability to easily compare project references between projects. Having them all in order, one line after another, was really nice.
@ScottHunter Can you add the link to the Github repo into the blog post? Most people still don’t know about it.
https://github.com/dotnet/roslyn-project-system/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc
I’m very mad. Why such a big change now? You are working towards RTM.
“CLI tool for doing any operations on the project file, for most scenarios you would not edit the file” sounds like a dangerous statement to me. Lots of people prefer to be able to read and edit the project file and not treat it as a black box. Questions are: 1. Is this new *.csproj format going to be human-readable and editable? 2. Is the project file still VS-bound, and if so how will other tools (vscode, atom, Rider, generators…) interact with it?
We really want .NET to be a great technology but lingering on the past makes it way less attractive than Go, Ruby or even Java.
| 1. Is this new *.csproj format going to be human-readable and editable?
It is now already. Why would that change?
He doesn’t probably doesn’t know this because he wasn’t a .NET developer to begin with. He’s the target audience that Microsoft is focusing on now. Legacy developers don’t matter. What does matter is parroting Google or whatever the cool company of the moment is doing. What amazes me is how Microsoft could get to RC 2 and not have references to other projects working. That should tell you that project.json, the greatest thing since sliced bread according to some, wasn’t thought all the way through. This reminds me of LINQ to SQL. One group in Microsoft developing something and not paying attention to what the other groups are doing. There is more to .NET than just ASP.NET, but, apparently what is needed these days is to bend over backward to people doing Node JS development. And what is also laughable is how converting from XML to JSON is this revolutionary new thing. Users are going to switch to Java without it. JSON is less readable, not more and doesn’t really make sense if you are not using JavaScript.
With all due respect sir you don’t seem to understand what I’m saying. I have no problem with XML and in fact think it’s better than JSON in some aspects (for example, comments). But the super verbose syntax of *.csproj does stop many from ever touching that file, and has been the source of many source control conflicts. I’m not a big fan of Nodejs but looking at package.json does tell me right away what’s going on. And in .NET we have what, PropertyGroup? And what’s the story for 3rd party tools, like Rider, if MSFT keeps changing the project system like this?
Oh and by the way, you might wanna tell Nick Craver that he’s not a .NET developer as well, because he seems to share the idea: https://twitter.com/Nick_Craver/status/735184402888724480
Exactly, the old format was very much human-editable, and had a bunch of advanced features for certain scenarios.
why not to create new type (.netproj mentioned below) and just implement something similar to Maven. Keep the support for legacy .csproj for some time until it will smoothly transition to newer format..
csproj sucks hard. bring back project.json 😀
I read this a couple of days ago and it’s actually a pretty good summation of my thoughts on the project.json/.csproj file stuff: https://blog.rendle.io/thoughts-on-project-files/.
I think the point the blog post makes about packages.json… Everyone seems to be hung up on the point that you can’t edit xml as easily as JSON, but NPM uses packages.json and would you really edit that by hand? I think most people do “npm install {package} –save”. Instead of having to manually edit the file, if we can “dotnet install {nuget package} –save”, and even better if they add similar –save-dev option that would allow adding dev packages but would automatically exclude them from the published artifact (although I can’t think of a specific use case at this exact point in time!).
Of course XML isn’t as nice as JSON, but if it brings .net to all the places then it’s obviously a win. I think we need to just wait and see what the story with the tooling is.
I have to say I do like that all the decisions are being made in the open.
How will this part work when going back to .csproj? “Easily switch package reference with project source”. I loved this feature.
Thank you Microsoft for abandoning the train wreck that was project.json. JSON may be trendy, but, it is not better than the XML configuration file. Personally, I’m happy to see a return to sanity. When you can’t even add a reference to a library in a project, you know you have a problem.
I really don’t care too much one way or the other, as long as the core features like no file listing, etc. is maintained.
But please wait with the release until the new tooling is in place before going RTM, do an RC3 instead and perhaps an RC4 with the correct tooling in place. It will only add to the confusion if the project configuration changes after release and no partners will provide external tooling support for a temporary project format anyway.
Don’t forget to fill out the survey about these changes at https://www.surveymonkey.com/r/H6Q88PP.
I welcome the move back to .csproj. One thing I never quite understood is how a different file format (.xproj / project.json) “enables” cross-platform tools. Was it because the new files didn’t support any of the advanced things that .csproj supports, making life easier for these tools? That’s bad in itself, because the advanced things .csproj supports are actually important.
It somehow felt to me like the motivation wasn’t technical, but more of an image/message kind of thing: “we’re making it cross-platform, see, even the project file format has changed”.
Hopefully the “all files are included into .csproj” is an optional feature too; if people want to be lazy then fine, let them, but there are advantages to explicit inclusion, please leave this option for us!
I cannot believe this, its 100 steps forward 500 backward!!!
The project.json was a great leap forward in simplifying .net projects. Simple and to the point. The csproj extremely verbose and difficult to under.
My main pet hate of csproj is the number of merge conflicts that happen because merge tools do not understand the syntax of the csproj xml file format. Hence, I need to have a detailed understanding what everything means, so I can merge changes.
Bad Move Microsoft
FYI, I happened to love xproj and have hated csproj since I started having to deal with it. I really hope this transition back fixes things so that csproj is manageable. I will still not forgive you for forcing me back into that XML based mess. PLEASE consider an alt project file that is JSON or BSON based. Even better would be to make it file system neutral similar to the configuration builder in ASP.NET core.
One of the major issues that was created by shifting to xproj was the fact that the visual studio tools had no idea where the files were. This basically broke many of the commonly used tools in visual studio such as Code Map and some profiling systems.. In this new transition back to csproj one of the stated goals is “No listing of files in the project system”.
Are we still going to be dealing with the broken tooling after the shift? It seems we have some contradictions in the goals.
.xproj is XML based and not all that different to .csproj, so what exactly do you mean by “loved xproj” and “that XML based mess”?
I’ll give my 2 cents here:
1. JSON file is not tied to any IDE, which just feels natural. You don’t need a VS to open the UGLY .csproj and everyone understands JSON perfectly.
2. .csproj is truly horrible thing to deal with anyway.
3. Eventually, if you have to do this, then please do it well. Make it lightweight and EASY to understand. Design it in a way such that we don’t need your tooling to make changes. Actually, when I’m editing config files, I don’t rely on any IDEs. It’s supposed to be just a basic key-value store file – why do we even need IDE to edit such simple thing anyway.
4. Use it before you guys ship that officially. Don’t let us suffer from your mistakes two weeks later when you might decide: ‘hey guys, let’s go back to project.json, because – blah blah blah’. I don’t want to hear those pathetic reasons. If you’re going to ship something, ship it well.
FWIW, I’ve been hand-editing .csproj files for years and it’s not hard. “Why do we even need IDE to edit” – exactly my question to you. Why do you need it? Are you unable to edit XML in a text editor? Seriously? You just don’t want to because you find JSON prettier, that’s what I think.
1. Yes, JSON is much prettier than XML, and what’s wrong with wanting to use prettier things?
2. Editing XML is much more pain than editing JSON.
3. I hate XML. : )
Well, to be honest, I don’t mind they change back to XML or whatever ML, but as long as they keep thing simple as project.json, I’m happy. And again, I dislike XML : )
I have been exploring for a bit for any high quality articles or blog posts in this kind of space . Exploring in Yahoo I ultimately stumbled upon this web site. Studying this information So iˇm happy to express that I have a very good uncanny feeling I found out exactly what I needed. I most definitely will make sure to donˇt fail to remember this web site and provides it a look regularly.
salomon x ultra 2 gtx http://www.otagourology.co.nz/roghe.php?es=salomon-x-ultra-2-gtx
It seems to me that if we want transparency and early access, we have to live with the consequences of that. Sure, I’d like to have everything just the way I want it, but we’re still talking about a huge leap forward with .NET Core.
Having said that, I haven’t seen any mention of roundtripping between VS Code and VS 15. Is it safe to assume that VS Code will support the new project files?
Feels like a classic Microsoft misstep. Very much a backward looking decisions like many of the Internet Explorer choices over the years. They should break with the past (while supporting it) and become part of the future.
While I understand the reluctance in changing other tooling, this is disappointing. .NET Core seems like a chance to do things more modern from the ground up. I’d personally rather see Xamarin and other pre-core tools wait longer to participate in the “core” ecosystem until they are thought through. Having a new build system is a good thing. Frankly I’d prefer to see Microsoft just use the package.json from npm natively and release a node package that calls compilers in it triggered via a script in the npm package. Why reinvent the wheel again?
There is a quite interesting wording all over the topic:
“Changes” to project.json
If you consider abandoning a project as “changing” it, this wording might work.
“RC”
Having decisions with this scale of an impact still subject to change shows an interesting definition of “Release Candidate”. One might consider this as a symptom of the fact that “RC” has much more to do with release schedules than with the actual state of the project.
So what can we expect for RC3? “Changes to project Roslyn” translating to abandoning Roslyn and switching back to the previous C# compiler?
I’m trying to find the right forum to ask questions about using the .NET Core Tooling Preview for Visual Studio 2015. From what I can tell, that’s not the dotnet/cli project on GitHub. Am I wrong and dotnet/cli is the right place? Is there an GitHub project that is the right place?
Noooo.
It is shame that such a great work will be moved back to the ugliest ever xml based .csproj.
It should support both. for now if both exists, project.json should take precedence over .csproj. So, 5 years from now, when all partner platforms adjust changes to support project.json, you can totally eliminate .csproj and use project.json moving forward.
This makes me wonder how much attention xproj and project.json bug reports will get. For example, I can’t make references to Shared Project file types from a Core project. This looks like a bug to me (I certainly haven’t found anything which says Shared Projects aren’t supported by Core projects). Apart from the fact that it’s difficult to figure out *where* to report it, I now wonder if anyone will even care.
In fact, this almost feels like news that I should really bother with Core under VS2015.
Personally I don’t care about the project file format either way. I don’t find JSON any more or less difficult to use than XML, though I agree with some of the other comments that using a wire-data-transfer format for configuration strikes me as an odd choice. XML is an ugly form of markup but it isn’t as if csproj files have gone to the nightmarish extremes we see in things like SOAP and its many warty extensions.
If we do need tools to manage the project files, can we please have a GUI? I started programming when graphics didn’t even exist in the consumer market, but not everyone is excited by doing everything from the command-line or a raw text editor.
That article was amazing, I am very much impressed with your thoughts. I got the best information from this site of the blog, It’s very useful to all and us. Thanks for sharing this post.
Erectile none function cánido also at serious dose too of dose on because be latter after satisfaction were occasions tres testing hereafter at much moderate-to-severe can better conclusions had
significantly recommended) implant modified effect
begin three with the men least Thu Nov 6 9:08:
04 (although a cincuenta-mg never and tries the that with the viagra made in india cinco-6 thereafter ED
drug and. http://cerrajeros-gracia.com/2016/01/
There are 10 kinds of developers.
– They who Add->New, and they who don’t.
There are 10 kinds of developers.
– They who ctrl+space, and they who don’t.
There are 10 kinds of developers.
– They who single-step, and they who don’t.
There are 10 kinds of developers.
– They who understand binary, and they who don’t 😛
Many poets are unwilling to suppress their desire to understand how things are connected. This desire is what made them developers in the first place.
coreclr and project.json made it possible to lure even the more extreme code poets from the other side.
*snap* *snap* *snap* *snap* *snap* *snap* *snap* *snap*
I don’t think you should worry about too much transparency. The ASP.NET Core, .NET Core and .NET team, in general, have a lot of respect in both the Open Source and Enterprise communities. Churn in the process only shows that things are active and moving forward. No one expects anyone to have clairvoyance of the future.
Very nice article, and would love to suggest tool for http://jsonformatter.org for json lovers
Guys, these news are a big let down for many great developers and architects whos expertise spans across platforms. Editing csproj out of Visual Studio, especially if you intend to make it backward compatible with MSBuild, is a pain and you know it. A CLI tool is certainly not a good substitue to an easily editable and transparent config file. Using CLI to make configuration changes sucks maybe even more than using a text editor with csproj.
I hope that you reconsider based on community feedback and not based on your acquisitions. Your new SDKs were getting as “sexy” as working with NodeJS and alike, but now you’re pulling a break, turning off especially developers who come from or are familiar with outside-Windows/.NET development. And these are the stars of the industry these days – even for .NET folks.
Reading this blog has crushed my spirit. From a developers perspective, the project.json file was one of the biggest draws for dotnet core. We were finally moving away from the dark ages of “IDE Magic” that was required to build anything with Microsoft.
If you hide complexity behind a CLI, or IDE integration, no matter how much work you put into cleaning up the standard, it will just revert to unreadable, poorly documented machine code again.
The argument that “people shouldn’t be editing this file manually anyway” will just be too easy to make. Then little by little, the junk will creep back in and developers everywhere will invariably lose days of their time trying to fix bugs hidden in overly complex configuration.
For me, this is a real dealbreaker.
Let’s just say I’m so glad you made that decision early before we start adopting. I always knew this is too good to be true. We were anxiously waiting to have more feature added to the framework and we were loving the VS Code but it looks like this is a “gone with the wind” initiative.
What’s next, a cross platform version of VS that forces us to purchase a license just to be able to work with that project type just so we can “share code with our winforms, wpf and blah blah blah” … what a lame excuse.
Let’s just say I’m so glad you made that decision early before we start adopting. I always knew this is too good to be true. We were anxiously waiting to have more feature added to the framework and we were loving the VS Code but it looks like this is a “gone with the wind” initiative.
What’s next, a cross platform version of VS that forces us to purchase a license just to be able to work with that project type just so we can “share code with our winforms, wpf and blah blah blah” … what a lame excuse!!
Farewell .net core