x
PERFECT!

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form

PUSH START BUTTON TO VOTE NOW!
please select a voting block

Ubiquitous .NET

Create a Ubiquitous .NET Client Application Development Model

Code Views

Allow developers to develop in their personal style within a team project.

Data Views

Enable developers to work with data files in their preferred format

VS PROJECTS

Improve Visual Studio Project System

EDGE

NATIVE/BROWSER INTEGRATION

Task API

Improve the language and usage of the Task API

Ubiquitous .NET Client Model

Create a Ubiquitous .NET Client Application Development Model

This vote is for developers who wish to see the idea of a ubiquitous .NET client application development model created by Microsoft and the Visual Studio team.

A ubiquitous .NET client application development model is a model that is defined in .NET-based technologies and is able to run in a multitude of runtime environments -- both native-compiled (store-hosted) and web-hosted.

A *very* rough image of the vision can be found here:
http://i0.wp.com/blog.developers.win/wp-content/uploads/2015/09/Vision.png

The goal is to enable *one* .NET Client Application Project to build deliverables for the following platforms:
1) Windows 10
2) Legacy Windows
3) *nix (Unix/Linux)
4) Droid
5) iOS
6) Macintosh
7) HTML5
8) ??? (Extendible to different, future platforms)

In order to achieve the above, a ubiquitous .NET client application development model should strive to possess the following qualities:
1) Native Cross-Platform Capable - For native-compiled/store-hosted scenarios (iOS/Droid/Windows Store)
2) HTML5-Compliant - For web-hosted scenarios, via .NET-to-JavaScript transpilation
3) Consistent User Experience - For brand recognition, reinforcement, and optimal usability across all known scenarios
4) Cross-Boundary Accessibility - For shared code/assemblies between server and client boundaries
5) Xaml-Powered - Harnessing one of the greatest inventions in Microsoft's great history
6) Object Serialization Congruence - Markup used to describe serialized objects is what is created in memory
7) Holistic Development Consistency - The same guidelines and conventions are used in both client and server scenarios

For more information around this idea and the qualities above, a series of articles has been created to discuss the notion of a ubiquitous .NET client application development model at length. You can view that series here:
http://blog.developers.win/series/bridge-to-dotnet-ubiquity/

Finally, this is intended to be a starting point for discussion, and not a final solution. THAT is meant for the experts there at Microsoft. :) Thank you for any support, dialogue, and feedback around this idea!

Roslyn-POwered Code Views

Enable developers to develop their code in their own individual style within a team environment

This vote is for developers who support the idea of Roslyn-Powered Code Views. Code Views are a conceptual improvement to the way Visual Studio renders code to a developer, and how a developer works with that code.

Opening a file: To load a Code View, code is loaded into memory and parsed as a Roslyn AST. From there, it is processed through a developer's Code Formatting Profile to render the code to the developer as they prefer it. This includes such things as spacing (spaces or tabs), documentation (on or off), and characters/symbols around fields (underscores or even Hungarian notation if they wish).

Saving a file: When a file is saved back to disk, the Code View sends it back to Roslyn to create an AST. The AST is then parsed and processed to create a 100% StyleCop-compliant code file, which is then saved to disk. From there it can then be checked into source control.

For more information around this idea, an article has been created to explore this concept at length. You can view that article here:
http://blog.developers.win/2015/10/roslyn-powered-code-views/

Finally, this is intended to be a starting point for discussion, and not a final solution. THAT is meant for the experts there at Microsoft. :) Thank you for any support, dialogue, and feedback around this idea!

Roslyn-Powered Data Views

Enable Developers to Work in their Preferred Data Formats

This vote is for developers who support the idea of Roslyn-Powered Data ASTs and Data Views. Data Views are a conceptual improvement to the way Visual Studio presents data files to a developer, and how a developer works with that data. Data Views are powered by Data ASTs, which are ASTs (abstract syntax trees) that describe data in much the same way that code-based ASTs describe code.

Data ASTs and the Data Views that they enable allow teams to pick a data format to use in their project, while enabling individual developers within the team to view the data in a different (and personally-preferred) format than the team.

Opening a file: To load a Data View, a data file (example.json) is loaded into memory and parsed as a Roslyn Data AST. From there, it is processed through a developer's Data Formatting Profile to render the data to the developer as they prefer it. This includes such preferences as format (.xml/.xaml) and spacing (tabs vs. spaces, properties on one line or multiple lines, etc.).

Saving a file: When a file is saved back to disk, the Data View sends it back to Roslyn to parse and create an Data AST. The Data AST is then converted into the target data format (or the format of the file in which it was originally opened), which is then saved to disk. From there, it can then be checked into source control where the team can view it as the expected data format.

For more information around this idea, an article has been created to explore this concept at length. You can view that article here:
http://blog.developers.win/2015/10/data-asts-and-data-views/

Finally, this is intended to be a starting point for discussion, and not a final solution. THAT is meant for the experts there at Microsoft. :) Thank you for any support, dialogue, and feedback around this idea!

visual studio

improve/reboot visual studio project system

  • The .sln format. 2001 called and wants its arcane, VB.NET-esque format back -- and we should gladly oblige, PRONTO!!!
  • 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.
  • 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 fundamental principle of DRY.


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:



Support yaml/json

New JSON parser in runtime



These include but are not limited to:

  • Xml
  • Json
  • Json5
  • Ini
  • YAML
  • TOML
  • ???


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

edge

native/browser integration


I see that

this vote

was taken down (which is completely against the spirit of a *community* telling YOU what THEY want).

.NET has been around for over a decade. Organizations and developers alike have invested hundreds of thousands of hours learning .NET and its languages. Code bases and libraries have been built around these languages that eliminate friction and encapsulate solutions to problems encountered over the lifetime of a product and/or framework.

By forcing developers to use JavaScript, and not utilize .NET languages, the Edge team is essentially forcing their users to break 

the fundamental principle of DRY.



In addition to forgoing hundreds of thousands of hours (and dollars) of investment, organizations and developers must now solve re-occurring problems (already encountered and accounted for in their favorite and familiar language of choice) in a completely new language, and forcing them to abandon mature and tested code. In doing so, they encounter new frictions and frustrations related to a different, incompatible paradigm that is being (unnecessarily) forced upon them. This is a wasteful and inefficient (not to mention expensive) approach.

The net result of this approach is that the same problems are now solved in two different languages, fundamentally breaking the principle of DRY.

The Edge team should account for .NET developers and allow them to leverage their extensive and exhaustive investments to make Edge a better (and fun, thereby more popular) product.


It's great to introduce an Edge Browser into a UWP application via the WebView. It would be especially powerful and useful to be able to access the DOM that is in the currently loaded page of the WebView control and have full control over querying it and even modifying it if necessary.


There have been many DOM APIs created in MSFT's history, so it's now time to build another one. :)

Task API improvements 

Improve Asynchronous Task API Programming Model


The asynchronous programming model introduced in .NET with the async/await keywords was a step in the right direction and a great improvement over previous design, but there are a few fundamental and disruptive qualities to it that need addressing:

  • Zombie-code. This is the biggest issue with .NET asynchronous programming model currently. Once asynchronous code finds its way into your code base, all code referencing it (and being called from it) must also start to incorporate asynchronous keywords and functionality. This results in a phenomenon which has been described as "Async Zombie Infection." It would obviously be great/ideal not to have a feature associated with zombies running around and infecting your code. :)
  • Coupling to Task and Task. Code is now coupled to the Task and Task objects. Interfaces and classes now have to change their signatures (and behaviors) to reflect these objects, leading to added complexity for a code base. Ideally, an asynchronous design should not be coupled to any class, and consumers should not have to change their consuming classes to enable it.
  • Contract pollution. When a class implements the current asynchronous model, it now introduces an asynchronous method for each and every synchronous method. This leads to longer intellisense lists and search times for finding a method, as now a class signature is twice as long. This also leads to a more complicated feeling to a class and code base. It would be better to have a design where a GetAsynchronous() (extension?) method is called to retrieve an object's asynchronous functionality.
  • Code Pollution. As alluded to the first two items, code that uses the current asynchronous model now has to incorporate not only task and Task, but now have to incorporate "async" and "await" throughout their code bases (more and more as the zombie infection spreads), as well as incorporate naming conventions that add "Async" to the end of classes and method names. This leads to what feels like code pollution and messy code.

    For instance, take the following interface;
    public interface IHelloWorld
    {
    string SayHello( string message );
    }

    The asynchronous version is:
    public interface IHelloWorldAsync
    {
    Task SayHelloAsync( string message );
    }

    The asynchronous version has 16 additional characters now over what used to be, due to coupling and convention. This might not seem much for a simple example, but when multiplied out in a code base that has hundreds of classes and thousands of methods, it adds up.

    (A parallel to this are class properties. In C#, properties used to be very verbose leading to a LOT of code in a class file, but now this has been adjusted to be extremely terse, especially 6.0. Perfection!)
  • The "gotchas" ... there are a lot of these. The biggest primarily being the "async void" problem and the exceptions that occur from this. This feels like a lot of friction and is indicative of further design improvement.
  • "async" is not a word. This encourages laziness and sloppiness in design and overall approach. That is all. :)

cross-platform uwp

Make Universal Windows Platform
Open Source and Cross-Platform


With the advent of //build 2015, the vision and direction of Microsoft seems to be open source and cross platform. This appears to be the case for every new product from Microsoft except for the Universal Windows Platform.

It would be great, ideal, and wonderfully awesome to see this platform reach consistency with the rest of the organization and embrace the ideals, values, and benefits from being open source and cross platform like other areas of Microsoft now are (or are on their way to being).

Please provide consistency throughout the entire Microsoft development ecosystem!

transpile uwp to JAVASCRIPT

Expand/Enable Universal Windows Platform to Transpile to JavaScript (Web / iOS / Droid Compatibility)


Companies like

CSHTML5

and

DuoCode

are already doing this, but it would be great to see this effort officially adopted into the Microsoft Universal Windows Platform.

Using Roslyn (as DuoCode does), UWP Applications written in Xaml and C#/VB.NET get transpiled into JavaScript and rendered via HTML5 canvas. The results of which could be hosted anywhere that HTML5/JS can run, notably iOS and Droid platforms. Or even on a regular ol' website.

A mechanism that operates like PhoneGap/Cordova would have to be implemented so that access to external hardware APIs can be achieved.

That way, there is truly *ONE* WUP application codebase, and it can truly work *anywhere*.

Native .NET for Windows 10, JavaScript "for everything else."

There would be no reason to ever learn another language/platform paradigm. Microsoft wins. :)

Ironically, this would truly make UWP "Universal."

Please consider this idea!!!

Explore Voting Options Above! 
Select, Click 
< >
, Swipe 
 or Key 
Improve Task API Model and Language
native / browser integration
Roslyn-Powered Data Views and Data ASTs
IMPROVE/REBOOT VISUAL STUDIO PROJECT SYSTEM
Roslyn-Powered Code Views
Ubiquitous .NET Client Application Model
<
>
Explore Voting Options Below!

Ubiquitous .NET

Create a Ubiquitous .NET Client Application Development Model

Code Views

ENABLE ABSTRACT SYNTAX TREE SOURCE FILES VIA ROSLYN

Data Views

Enable Developers to Develop in their Preferred Data Format

visual studio

Improve/Reboot Visual
Studio Project System

EDGE

NATIVE/BROWSER INTEGRATION

Task API

Improve Task API and language

about

Developers Win! is a site that is dedicated to advancing important (and challenging) improvements to Microsoft .NET technologies by way of UserVoice voting services.

Our primary issues of concern are as follows:


Additionally, we are also concerned with

improving Visual Studio project support, improving Edge browser integration,

and

improving the way developers work with the Task and TPL API. 



These issues are important to us, and we hope they are important to Microsoft developers who visit this site, too. If you are a developer and care about Microsoft and its future as much as we do, we ask that you take a second to vote for the issues presented here. Thank you for your support, and for doing your part in making sure that Microsoft  and its Developers Win!

Join Us!