Improve/Reboot Visual Studio Project System
Visual Studio Projects have been around for over a decade, and their projects are starting to show this fact. There are 3 primary issues with Visual Studio Projects that should be attended to in a (very-near) future release:
1) The .sln format. 2001 called and wants its arcane, VB.NET-esque format back -- and we should gladly oblige, PRONTO!!!
2) MSBuild XML format. The format is very difficult to work with, primarily because there is no tooling support for it. Additionally, the syntax is also arbitrary and suffers from XDom-to-POCO-mapping which is a terrible way to design any system around XML documents. XML Documents should be serialized POCOs, which make for much better design and tooling support.
3) ASP.NET vNext projects. This is really the impetus for this vote. ASP.NET vNext projects are now using their own .json-based project system that really have nothing to do with Visual Studio anymore. They offer an .xproj that is essentially there as a placeholder to keep Visual Studio happy. This is a terrible problem and reflects poorly on Visual Studio -- and the Visual Studio team for allowing it to happen in the first place! Now there are two project files in different formats, leading only to confusion and inconsistency. Furthermore, all sorts of features that "just worked" in the older project system are having to be rebuilt and added from scratch in the new project.json model, leading to all sorts of bugs and issues in the new system. Finally, this design violates the funamental principle of DRY: https://en.wikipedia.org/wiki/Don%27t_repeat_yourself
A new project system would address each of these issues. New solution and project formats should be .slnx and .projx, and should be serialized POCO objects that are first-class components of the MSBuild vNext system. Ideally, the default format would be Xaml, as it is a popular, powerful MSFT-based technology that is mature, tested, and has a great deal of tooling support built around it.
In addition to the .slnx/.projx format, the Visual Studio team should also formally acknowledge and recognize that developers and teams prefer working in their own data/serialization formats, as outlined in the following (great) discussions:
These include but are not limited to:
To reconcile this, the Visual Studio team should provide a new, innovative mechanism in which to open/view/edit data files in Visual Studio. Developers should be able to open the .slnx/.projx (or any data file, for that matter), and through the power of Roslyn be able to view the file in their preferred format. Once the file is saved, it is saved in the target .slnx/.projx format (Xaml, or otherwise).
Times are a'changing :)
"Official" thread here (for now ha ha):
Nice conversation here, jump on in and let your voices be heard. :)
LOL @ Anonymous ... this is starting to remind me of the epic "YES!" "NO!" debate/rant/post fest that happened with bringing back Silverlight in Edge:
The bottom line here is that there are two camps that MSFT has (unfortunately) created: web application developers and native application developers. Conceptually, they are one and the same (and ideally they should be!), but because of confusing/questionable strategy/direction we have now ended up with these two conflicting camps, with completely incompatible approaches and neither likes the ways of the other. Sounds like someone was inspired by our political system here in the US. :D
Anything but xaml!!!!
There's been good feedback like yours Michael. Thank you for sharing and hopefully MSFT will consider this with its new project system. To start with, I am not sure how you don't think Xaml is not tool friendly while JSON is. With Xaml you only require two artifacts:
1) Class definition (.cs file)
2) Data file (.xaml file)
Whereas with the JSON approach, you require 3:
1) Class definition (.cs file)
2) Data file (.json file)
3) JSON Schema (yet another .json file)
Then you need some way of linking up that 3rd schema file. JSON is supposed to be terse and standardized, but you end up having to define an arbitrary, unusual "$schema" attribute to point to its schema. With Xaml this is baked in to the root element and xmlns attribute and the tooling catches on to it without any sort of configuration.
Don't get me wrong, I see, understand (I hope! :D ), and appreciate the value of JSON: for describing objects in a compact, human-readable manner that's intended to transfer across service boundaries. The fact that the standard doesn't support comments reflects this intent. Any extended use of this travels into dangerous territory as now you are violating/bending a "standard" that might further be used (read: copy/paste) down the line that ends up breaking in interoperable scenarios.
At the end of the day, we have two developer scenarios: creating objects that are meant for transfer (lightweight/compact/terse: JSON is great for this), and defining applications that create those objects (significant/verbose: XAML is great for this). Of course, there are developers that prefer to keep the same format throughout their solutions to minimize context-switching and maximize efficiency, so this should be considered, too.
As a business owner, I would prefer to have one language (C#) and one data format (Xaml) all the way through my solutions. That way, I not only have to worry about working with just these formats in any of my solutions (less time in context-switching) but I also benefit in seeking the resources from the marketplace necessary to manage/maintain them by was of a simpler more defined/exact skillset. Incidentally, this is another reason why I think it's so important for a consolidated, ubiquitous .NET client application model, as well:
I really hope that the JSON project format sticks. This was a huge breath of fresh air and far easier to work with than the finicky XML mess with previous versions. XAML is NOT tool friendly, no XML format is "tool friendly", it takes a massive engineering effort to part every nuance of XML completely and properly.
Microsoft doesn't operate in a bubble anymore - they can't afford to ignore the rest of the ecosystem that is rapidly evolving around them.
I love the new Microsoft - .NET would quickly become irrelevant without Microsoft's new attitude, since it matters very little what runs on your server for web apps. The new JSON projects are just a small part of this and is extremely tool friendly - everything can parse from/serialize to JSON.
It's all fun and games until someone cuts themselves on an angle bracket.
"We also need to make it easy to work with projects across these application models. In order to do this we are working to merge the capabilities of .xproj/project.json and .csproj project systems into a single project system based on MSBuild."
Sounds promising! And the right thing to do. :)
Here's an article that sums up the discussion so far, discussing the tweet below, how Visual Studio is not actually following the .json specification, and screenshots/example of how Xaml is a viable object-definition language -- especially for things like project structure definitions:
Thank you john.ludlow.uk. Your support is much appreciated. :) Glad I am not alone here.
FWIW, something to consider here. This seems to be speaking directly to project.json:
A XAML-like approach would be great, I think. You could have a designer-like pane which allows you to quickly select common options in a GUI, and a code pane which allows you to make more advanced changes with full intellisense.
The fact that the XAML editor is already works this way and is reasonably mature plays into this nicely.
@john.ludlow.uk I like the way you think. :) I appreciate the properties pane from a utility perspective, but I agree with you that its implementation is pretty arcane (and not very extensible). It would be great to visually design and explore our project files in a extensible and flexible way. This is why I suggest Xaml as this can be done right now in the current IDE without much effort/work but I am definitely open to other options if the same power, tooling-friendliness, and flexibility is retained.
IMHO, the most important parts of this are
a) making it easy to extend your build logic and see how your build has been extended (not hiding that stuff behind a pointless and restrictive Project Properties dialog)
b) making it easy to do the right things when you are moving things around (e.g dragging a class to a different project should result in a move operation in your source control, as well as a prompt to update the namespace)
I just got done making a simple app that does what the Developers Win! post mentions below. Please see this file:
And (probably more importantly?) this file: https://github.com/DragonSpark/VoteReporter/blob/master/DevelopersWin.VoteReporter.Application/Program.xaml.cs
Here is a good example of a Xaml-driven application. In this case, all of the "steps" of the application startup are encapsulated in System.Windows.Input.ICommand's and they are called in succession to execute very discrete and encapsulated commands. These commands are then defined in the Program.xaml file that can be used to define all of the inputs and (what others might consider) configuration for the application.
The power again is the markup extensions. There are some really cool ones here that are being used, such as creating a DirectoryInfo object that is used by subsequent components via IoC: https://github.com/DragonSpark/VoteReporter/blob/master/DevelopersWin.VoteReporter.Application/Program.xaml#L22
This line tells the application to pull all registered IInstaller's found within the current AppDomain and add them to the collection found within the InitializeDatabaseCommand:
Very powerful stuff. This is how I see MSBuild vNext being implemented, and the new build projects looking very much like this.
Hm... the more I think about this, the more I think that I should write a blog article on this. :)
If anyone is interested, this vote and others like it that aim for key improvements to Visual Studio are being tracked on Developers Win! The first report can be found here:
Future weekly reports will be found here:
As of today, the Visual Studio Improvements category (where this vote is tracked) has 223 combined points. This report will be useful in seeing how many votes occurred over what period of time. Please continue sharing this idea and make sure that our voices are heard!
I think it would be something like this: https://xkcd.com/927/
FWIW, this vote is a featured vote on Developers Win! http://developers.win/visualstudio
Hi David, thank you for your reply. At this point, I believe it's the features that ASP.NET vNext doesn't use but should and are already in classical/traditional projects. The entire wheel is being reinvented all over again, and we're having to pay with enduring all of the same (and new) bugs and quirks that go along with it. It is quite frustrating as I am sure you can imagine.
Here is an issue I submitted that really started this vote and was the "last straw" for this feeling, really:
Additionally, nuget packages now are viewed in the References node, but cannot be interacted with in any obvious way. One would expect a full set of features from right-clicking a nuget package listed References, but alas, it is only a mirage at present.
Those are the two that strike me off the bat, but to be honest, I really didn't go past these observations. I had seen enough and created this vote instead as clearly there is obviously a systemic problem here.
I understand that this is all supposed to be fixed at some point (by the final release of ASP.NET vNext), but the (really) big issue here is the fragmentation of the project system in the first place, and how we as developers are now having to deal with two project systems: one in traditional MsBuild xml and now another in .json. Neither of these are as tool/designer-friendly as Xaml, so it really adds to the confusion here on why such an effort was made to bifurcate/duplicate concerns into a new technology (that isn't MSFT-invented and based) altogether, rather than rallying/leveraging an existing (MSFT-invented and based) technology that is tried-tested-mature and is used in pretty much every product/group in MSFT except ASP.NET. :P
The other major concern here is that a lot of noise was made around the new ASP.NET vNext projects that the experience was going to be "lit up" in Visual Studio. As we cannot easily exclude items from our projects, that simply does not appear to be the case at all. Projects have a very basic/dull feeling to them now, and there is a looming, almost-sinister feeling that if you have to get anything done now, you have to go crawling into an obscure .json file, and poke and prod it for any hidden easter eggs that may reveal working functionality that has already existed for over a decade in other, working project types in your solution.
We were promised a "lit up" experience, but in reality, it is as if Visual Studio is the afterthought, and enabling external, non-MSFT editors is the primary focus. it's almost as if you're working hard to make OTHER companies successful, not yours, and that is no way to run a successful business. I understand the appeal and value in supporting environments outside of Visual Studio, but please don't do it at the expense of its quality, and (more importantly) the mind share that it affords.
So, in summary, MSFT *First*... others second. :)
Thank you for engaging your loyal customers! And please let me know if you have any further questions.
David Kean commented
Hey, thanks for the feedback! I'd like to get an understanding of what features in the project system that ASP.NET vNext uses do you miss from classic/tranditional ASP.NET/.NET Framework projects?
Managed Languages Team @ Microsoft