This suggestion is migrated to Developer Community. Please use below link to view the current status.
https://developercommunity.visualstudio.com/content/idea/351412/create-a-ubiquitous-net-client-application-develop.html
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!

Blog post at http://davidburela.wordpress.com/2013/11/22/is-it-time-to-open-source-silverlight/

For all intents and purposes Microsoft now views Silverlight as “Done”. While it is no longer in active development it is still being “supported” through to 2021 (source).

However there is still a section of the .Net community that would like to see further development done on the Silverlight framework. A quick look at some common request lists brings up the following stats:

* 5,720+ votes to release Silverlight 6 https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3556619-silverlight-6
* Feature requests for Silverlight http://dotnet.uservoice.com/forums/4325-silverlight-feature-suggestions
* Microsoft connect list of active Silverlight feature requests: http://connect.microsoft.com/VisualStudio/SearchResults.aspx?KeywordSearchIn=2&SearchQuery=%22silverlight%22&FeedbackType=2&Status=1&Scope=0&SortOrder=10&TabView=1
Rather than letting Silverlight decay in a locked up source control in the Microsoft vaults, I call on them to instead release it into the hands of the community to see what they can build with it. Microsoft may no longer have a long term vision for it, but the community itself may find ways to extend it in ways Microsoft didn’t envision.
Earlier this year Microsoft open sourced RIA Services on Outer Curve http://www.outercurve.org/Galleries/ASPNETOpenSourceGallery/OpenRIAServices, it would be great to see this extended to the entire Silverlight framework.

Create a way to rename a project folder. This is closely related to http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2517011-enable-project-renaming- and http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3054944-rename-the-project-folder-when-renaming-a-project

I would like a way where I can change a folder name and optionally filenames: Project -> right click -> rename folder and files... -> give a new name, select folder, output filename or both ->
* Visual Studio updates name of the the solutiondirectory
* Visual Studio updates the solution to point at the new directory
* Visual Studio updates references of other projects to this project to the new directory
* Visual Studio updates the project to reflect the new output file name
* Visual Studio cleans the old files from the output dir if present

Extra brownie points for optionally integrating this in the rename project functionality (update output file name and directory to NEWNAME? <yes> <no>)

Double extra brownie points for a 'search for references to this directory from other tools': text-based search for all files not in obj or bin dirs in all folders under the solution dir that contain the old filename, and ask if the old directory name should be replaced with the new one, or if you want to open the files and edit them manually.

Create something like what Xamarin is doing in order to help developers to code once and run EVERYWHERE (Wndows 10, windows 10 mobile, android and ios).

If Microsoft could not buy Xamarin, at least do what they are doing by your own. Make something that enable us to archive real NATIVE cross platform development. It could dramatically increase the numbers of developers using .net to create mobile applications as well as increasing the number of apps created to wp too, since app could be compiled to ios, android AND WINDOWS PHONE. Hibrid apps like apache Cordova has a lot of potential but right now it is limited to offer a bad user experience when compared to the native apps you could build native with native objective-c on iOS, java on Android or C# (on Xamarin.Forms o WP and Windows 8). Porting .net to others platforms is good, but go further MS, create something that help us to "code once and run everywhere. And by EVERYWHERE I mean, not just windows, I mean: Native apps on Android, iOS, Windows PC, Windows Mobile, Xbox, HoloLens and to on. Bring us a tool that enable us to make Visual Studio Universal Apps REALLY UNIVERSAL (running as well on android and iOS).

We want a Framework that enable us to build NATIVE.
By the way Xamarin Starter edition has a very limited package size so is almost impossible to create even small apps with an organised architecture (multi layers) and its licences fees is very expensive too.
Hey M$ look to the opportunity a tool like Xamarin could bring to the windows ecosystem. It could help you to resolve the app gap Windows Phone suffers so far. With a tool that can help developers to build native applications to windows as well as to android and iOS could bring the apple and android developers interest to use it and since it will be able to compile to windows phone then they will not have why to do not do so. It will also bring mobile developers form other platforms (android and iOS) to Visual Studio and .NET.

This suggestion is migrated to Developer Community. Please use below link to view the current status.
https://developercommunity.visualstudio.com/content/idea/351081/add-f-support-for-net-native.html
I had a conversation with @xyziemba and @dotnet on Twitter recently about the .NET Native toolset and features. I understand the F# is not supported at the moment and that support is unlikely to come in the VS 2015 RTM timeframe. I'd like to suggest that you consider adding this support as soon as possible - even if it means some time after the RTM of VS 2015.

Since I couldn't find a UserVoice request for this - I wanted to put this in.

Thanks,
Krishna

Proposal is to create a “One Framework” project at Microsoft to encompass both technology development and a consistent message for customer engagement. A developer should be able to fire up Visual Studio and use C# and Xaml to target Windows Desktop, Windows Store Apps, and Xbox One along with a cloud deployed “click once” option to all these targets. There should be clear guidance that all of these will be both supported and enhanced for a long time to come. It would be a nice extra to have a fully supported by Microsoft targeting of C# to Android and IOS for which a Xaml runtime is seriously needed. If there is a battery life and performance issue on small devices by using this sophisticated programming technology then that should become a tooling issue and not a “pull the rug out from under the developer” issue. The .NET framework is at the heart of this and needs to be the driving force since all possible solutions flow upward from a solid cross-platform framework. The PCL effort leads to the LCD which feels like a return to .NET 1.0. Instead each platform needs the full 4.5 framework either native or via extension DLL exported by tooling. Persistent data is vital to any serious application and every target needs a universal System.Data or new cross-platform data core to cover common always offline scenarios along with cached scenarios to Azure etc. It creates a cognitive breach when developing a Windows Store App and a Windows Desktop Application becomes cross-platform programming! “One Framework” would restore the beauty of C# Xaml development for millions of developers and restore confidence in enterprise investment in the Microsoft development stack. The WPF in .NET 4.5 should be harmonized with the WinRT Xaml runtime via either a O/S update or tooling extensions that could create a harmonized virtual “One Framework” layer. The Blend tool needs improved promotion to the developer community and could be extensively enhanced for the One Framework. The Entity Framework could be enhanced with both fundamentals and tooling to support all targets, and also NoSQL and Object Graph serializations as a universal One Framework Data Persistence.Currently disenfranchised Silverlight LOB developers can be given a clear upgrade path to this single One Framework target particularly if tooling for Android and IOS targets are added. The scope implied by this proposal will hopefully not be a deterrent to consideration of the technical enhancements listed here.