I suggest you ...

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:
- Xml
- Json
- Json5
- Ini
- ???

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

558 votes
Sign in
Password icon
Signed in as (Sign out)
You have left! (?) (thinking…)
Mike-EEE shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Password icon
Signed in as (Sign out)
  • Mike-EEE commented  ·   ·  Flag as inappropriate

    Anything is possible with MarkupExtensions. :) This is the primary power of Xaml and why it is so great.

    First off, the notion of the XML used below is very arbitrary. I am not entirely positive it maps to POCO objects, and to this day (after working with Visual Studio for nearly 15 years!) still don't know what it ultimately resolves to. Instead, POCO objects are initialized, and then data from the XML presented below is then converted (ugly omgggg) and mapped to those POCO objects. This is one of the biggest problems with working with XML-based documents.

    In Xaml, you are working directly with a POCO object. This is why tooling works so well with, from intellisense to the beautiful designers used in Blend and UWP. In this paradigm, you would be designing POCO objects that are used to define build tasks. This is a much more coherent/cohesive manner to design, as Xaml developers know and appreciate. :)

    So, in your example below, PropertyGroups would most likely go away (and should). You would then be working with an POCO, we'll call it BuildTask:

    <msbuild:BuildTask Enabled="{x:Eval {x:Reference Item}, 'SomePropertyInt', 1 }">

    This is very quick psedo-code that has absolutely no bearing in reality. :) Just giving a VERY quick example of one way of handling this. In the case above, there is an Eval markup extension, that is referencing another item in the document (with the x:Name of "Item") and is evaluating a property on it named "SomePropertyInt" to see if it equals the number 1.

    Another example could be more terse:
    <msbuild:BuildTask Enabled="{x:Eval 'Item.SomePropertyInt == 1' }">

    This would do the same thing and be more aligned with what you see below, but using a stronger object identification structure that Xaml provides seamlessly. Additionally, now that Roslyn is around, the expression above should be a piece of cake to resolve. :)

    So, in regards to "good" replacement, it would be a little more verbose, but much more powerful and clear.

  • Anonymous commented  ·   ·  Flag as inappropriate

    Does XAML have a *good* equivalent to the way MSBuild uses Condition attributes? I'll define "good" as having same or better functionality, with same or better (e.g. less) verbosity.

    <Foobar Condition="'$(***)'=='1'">***</Foobar>
    <Foobar Condition="'$(yyy)'=='1'">yyy</Foobar>
    <Foobar Condition="'$(Foobar)'==''">xyz</Foobar>

  • Mike-EEE commented  ·   ·  Flag as inappropriate

    Thank you for your support, José Manuel Nieto Sánchez! Please feel free to share this vote. :)

2 Next →

Feedback and Knowledge Base