Eight months ago we asked you to provide feedbackon the features you want us to ship. And you didn’t disappoint! Since then, we’ve seen hundreds of Tweets, blog posts and user voice votes. It’s great to be part of such a thriving community.
We are fully committed to improving the .NET ecosystem by being more open. To quote Habib from his Build talk:
By openness we don’t just mean open source. We also mean openness in the way we communicate, in the way we release documentation and just in the way that we do business.
Reacting to feedback is a critical part of making sure we’re doing a good job of enabling a great ecosystem.
One of the major feedback channels we monitor is User Voice. In this post, I’d like to look back and show case some the items we’ve resolved since we asked for more .NET advisors.
Overview
We’ve completed some very popular user voice items. In total, we’ve addressed well over 10,000 votes. Here is a picture of how the votes are distributed across the areas we’ve addressed:
Now let’s look at each area.
Reference Source
I don’t know about you but sometimes I’ve a hard time using APIs that other people wrote. In many cases having documentation is sufficient to solve the problem. However, sometimes it’s just easier to look at the source of the API. Using the .NET Framework is no exception to this.
It seems I’m not alone – there are close to three thousand votes for improving the .NET Reference Source, our existing solution that allows you to step through the .NET Framework source in the debugger:
First of all, we’ve addressed the specific request, which is to ensure that .NET Framework source debugging works, even after your installation has been updated with a security patch.
However, we also sat back and thought whether enabling debugging is the best experience for understanding the code. In many cases, reading and browsing can be a much better experience. Thus, we also launched a new web site that hosts the latest version of the .NET Reference Source, called http://sourceof.net.
Make sure to check out the video that walks through the features of the browser:
SIMD
Performance matters, especially in compute intense applications. Today, we don’t have a good story for leveraging SIMD instructions, which enables the processor to run computations in parallel within a single CPU core. As a result, the request to support SIMD is by far the most popular request for our code generation.
We announced a preview for SIMD support at Build and also provided a blog post on how you can leverage SIMD from your code.
.NET Native
Until recently you had to make a decision: do you prefer the productivity of C# and .NET or do you need the power of the C++ optimizer. Wouldn’t it be great if those aspects would be orthogonal decisions?
We felt so too. At Build, we announced the preview of .NET Native. For more details, have a look at our post about the .NET Native Preview.
Portable Class Libraries
Portable class libraries is the key building block for enabling a cross platform ecosystem with .NET. Many of you told us that you’d love to build more libraries for the ecosystem but that you can’t use portable class libraries because Visual Studio Express doesn’t support it.
Starting with Visual Studio 2013 Update 2, you can now build portable class libraries using Visual Studio Express for Windows.
We’ve also improved the tooling itself, for example, many of you needed WinRT support as well as the ability to design Xaml. Those items are also addressed with Visual Studio 2013 Update 2.
Cross Platform
We’re living in a many-device world now. Consequently, we’ve invested quite a lot into making newer features available via NuGet. NuGet packages enable you to take advantage of newer features without having to wait for the next .NET Framework release – or even an OS upgrade.
You told us that this isn’t good enough: you also needed a license that allows you to move your investments forward, to any platform.
We’ve addressed this concern by removing the platform restriction from our NuGet packages.
But we didn’t stop there – we also announced a collaboration with Xamarin to improve your cross-platform experience, in particular around building mobile applications.
Summary
In order make .NET great, we’ve asked you to advise us where we should focus our attention. Since that post we’ve completed numerous user voice items, addressing more than 10,000 votes.
Please keep the feedback coming!
Now that we have .Net Native, can you get it to spit out AMP accelerated binaries?
Thank for your effort. Please consider win7 support in the new stuff.
Wow! Thank you. Doing a great job team.
TIOBE Index for April 2014, C# Rating 4.82% change -1.33%. guys please speed up! you have no more the time!
Make .NET runtime for Linux, or show dedication to make Mono 1st class. It will pay off!
I'd like to see the async/await debugging support that you added in VS 2013 extended to more than just Win8 apps. We don't write any Modern apps currently so its as if this feature never existed for us.
Also, maybe you guys could share an update on progress with allowing lambda expressions in the debugger? Eagerly awaiting that feature.
Can you, please, log a suggestion for the Async support you have in mind on visualstudio.uservoice.com That is how we track customer requests in so we can implement them in order of popularity
For lambdas, we have visualstudio.uservoice.com/…/2049821-debug-lambda-expressions. Please vote on that if you haven't done so already! This item is under review, which means it will be implemented for one of our next releases.
Thanks!
Maria Ghiondea
Visual Studio Debugger
Is it possible to get the source of "sourceof.net" so that we can use that for browsing & searching through large codebases?
I like the idea of "openness" but for it to realistically "feel" open to everyone outside of Microsoft you will need to openly talk about the items you would rather avoid.
Your .NET item with by far the largest number of votes is XNA:
visualstudio.uservoice.com/…/3725445-xna-5
Even if the only use of XNA is to allow beginners an approachable way to learn both .NET and Game Programming, it is useful and valuable, not to mention repairing some very bad vibes you have managed to pick up by killing XNA and killing Silverlight.
I know you will want to pass those issues around like a hot potato that nobody at Microsoft wants to catch, but it's still reverberating through the internet and the memories of .NET fans everywhere and will continue to damage to you until you address it.
You appear to have belatedly addressed WPF from various hints dropped at BUILD but some plain talking (or blogging) is still missing in action on that as well.
Your cute pie chart will look quite different of you show those segments with the top votes included.
I like what your doing and I like your blog post but every day I run into the bitterness in other people and think that while you are having thoughts of "open" it just might be time to bring back all those developers that equate the silence on obviously important topics as anything but open.
@SleepyDaddySoftware: I've pinged the experts on .NET Native — reply will follow.
@Laci: Porting features to previous platforms can be tricky; it's always a balance of risk, available resources and product road map. That being said, most of our new library work is targeting existing platforms, which includes Windows 7.
@Simon: We're trying 🙂
@Anil Mujagic: Agreed — we're fully committed to make .NET work great across platforms. To ensure the best experience for the Linux/iOS/Android platforms, we're working with Xamarin. They are the industry expert on implementing .NET on those platforms.
@MgSm88: I've filed the following user voice item on your behalf:
visualstudio.uservoice.com/…/5757204-expand-async-debugging-support
Please spread the word & vote! It helps Maria's team to prioritize.
@Teucer: I'm not aware of any plans to open source the implementation of the .NET Reference Source browser. I've filed the following suggestion on User Voice.
visualstudio.uservoice.com/…/5757227-open-source-the-code-that-powers-net-reference-so
Again please share & vote!
@DonAlienware: I fully understand the frustration around the issues you're raising. I've taken your feedback and will try to make sure it gets addressed.
@SleepyDaddySoftware: Thank you for the suggestion. The C++ optimizer is capable of autovectorization. AMP code is usually generated as the result of explicit AMP instructions (such as parallel_for_each.) I'm not certain what the gap is between autovectorization and automatically recognizing patters where AMP instructions should be applied but it's certainly something we should put on our radar.
The vote for an updated VB6 has more votes than any you have listed above.
visualstudio.uservoice.com/…/3440221-bring-back-classic-visual-basic-an-improved-versi
And yet no one in Microsoft dare address it.
(Yes I know VB6 isn't part of .Net, nor would we want it to be, but it does need updating).
In the Tiobe index for April 2014, VB6 has just risen to sixth place. Not bad for a language ignored by Microsoft for the last 12 years.
Does no one in Microsoft have the authority to look at the call for an updated VB6 and at least make a response ?
Thank you a lot. You did really great job here.
Please dont stop here and make .NET even better by adding AMP acceleration possibility and really cross platform, eg buy Xamarin.
Maybe eventually you can make VB.NET Native as well.
@Sten: Unfortunately, I can't comment on VB6 as this is outside my area.
@Pavel: Regarding AMP, see Andrew's response above. With respect to cross platform & Xamarin, see my comment above.
@Sten:
I'm sure someone in Microsoft has that authority but I imagine you won't find that person on the .NET feature team. Usually creating or reviving entire products is done by someone a bit higher up in management. But we've highlighted to our management the popular Connect issue and your comments on this blog. Thank you!
@westprogram1: First C# then the world! .NET Native is in preview right now. We started with Windows Store apps, and because C# is the most-used managed language in the Windows Store, we started with C#. VB.NET is definitely on our radar. Thanks for the feedback!
By the way, a lot of the questions being asked about .NET Native are answered in our FAQ at msdn.microsoft.com/…/dn642499.aspx, linked off the .NET Native site at http://aka.ms/dotnetnative.
Thanks for your interest and great suggestions!
dx12/wpf questions … airgap , shell integration and real shell api exposure , flip3d , glass , chrome .
multi-taskbar , multi-screen , multi-desktops , multi user configurable desktop context menus.
xaml templates for Win9 UX that allow UI rearrangement as simple as theme replacements .
microsoft has literally dictated the UI for 30 years . like hardware drivers , set the standard , define the api , and open it the **** up
then maybe cross platform will be a stampede toward instead of from
Has someone do a .NET Native test with: github.com/…/RayTraceBenchmark
It actually ran slower with .NET Native on x64.
C++ = .11 sec
C# JIT = .4 sec
C# Native = .6 sec
Bring Visual Basic 6.0 in a new version ! this is important.
It would be nice if VB6 fans could have a venue somewhere outside of .NET. There is a strong vocal minority of VB6 fans that obviously know that VB6 is NOT .NET yet they keep trying to make a case for doing something with VB6 in various places that are obviously about .NET
I can only guess that they they feel there is no forum to address their need. Perhaps Microsoft could somehow view that discussion in a different light and no matter how retro and not .NETish the concept might be, maybe you guys could somehow combine VB6 and Small Basic into an Outercurve OSS project?
Because from what I can see, the VB6 fans are adding a noise level to any legitimate discussion surrounding other potential "retro" technologies such as XNA, Silverlight and WPF which are all .NET technologies and all have a reasonable use-case as on-ramps for current directions.
Here are some thoughts on why it might be worthwhile to create an open conversation around Silverlight, WPF and XNA as part of "current" forward looking thinking.
Addressing Silverlight would be more of a marketing gain, but still valuable. For the cost of some devs allocated to Silverlight 6, Microsoft would reap huge good will in a segment of the small business and small enterprise segment which are not very vocal but I run into them all the time. These devs don't hang out on the internet or go to shows. They have LOB apps in MFC or WinForms and previously had every intention of moving to Silverlight. By killing both Silverlight and WPF, Microsoft created a chasm too large to jump. You can't just silently bring back WPF and expect this huge "silent majority" to suddenly perceive the new shift. You need to shout to that crowd. There is a "current" value to repairing the SIlverlight damage.
WPF should be obvious. It was the high point of .NETism and was a sleeping giant of potential uptake that Microsoft was not patient enough to wait for. It needs to be a first class target and should be part of Universal Apps. As part of "open" it still needs to be talked about. Please put the WPF team together again and let them blog or assign a writer to that team. The existence of 1.6 billion desktops means there is huge "current" value to hitting hard with WPF and bringing it into Universal Apps gives you a path to the other.
XNA was a strange child of .NET and DirectX and was easy to kill perhaps but again did more damage than the killing was worth. It wasn't just a way for Indies to do Xbox, it was a giant on-ramp for uptake of Microsoft technologies in a group that didn't give immediate payback – children, teenagers, college kids were all attracted to 3D gaming and what a great way to get this group enjoying Microsoft .NET. Now there is just a giant gaping hole between TouchDevelop and C++/DirectX – XNA was right at the center of a .NET strength and you didn't see it because it got binned into the wrong group/division/demographic/whatever in your planning. XNA can easily become an on ramp to current technology.
As part of being "open" if there are still good reasons right here right now to make the most talked about .NET technologies (outside the Microsoft Bubble) stay in the Dead State, then please talk about it! The silence just fosters ongoing mistrust. The mistrust really makes it hard in the day to day normal world to have conversations about Microsoft technology. When I hear "but they killed Silverlight so how can I trust them to ___" I just want to hide. Maybe you don't even need good reasons, just the openness of a conversation in order to re-engage people.
You have moved far enough that I can justify to myself the time it took to type in this comment. Now you just have to complete the journey.
If anyone wants to expand on this topic, I monitor comments in my .NET UserVoice – "One .NET for One Microsoft"
@Andrew: Thanks for the heads-up! We're looking into the Raytracer benchmark. I suspect that the issue is that it is a benchmark–the raytracer is focused on doing a ton of computation, and our JIT is doing a great job at optimizing that computation. We've currently optimized .NET Native for improving the startup of Store apps, which are normally far less computationally intensive than CPU-bound benchmarks. But understand this is just my assumption–we haven't measured anything as of yet.
I'll post again once we've had a chance to look.
@DonAlienware: What a fantastic, thoughtful comment! I just this afternoon mentioned to my immediate the outpouring of support that VB6 received when we blogged about .NET Native. I'm going to send your entire comment to my management as well.
I can't say much about Silverlight, WPF, desktop support, etc. right now but your feedback–and similar feedback from others–has been heard. Thank you.
Please, make developing asp.net, database agnostic. I want to be able to develop for say 2 or more databases without writing different queries for each databases. I just want to change a parameter somewhere and the switch is over. Thanks.
@Andrew Pardoe
"But we've highlighted to our management the popular Connect issue and your comments on this blog. Thank you!"
Thank you, Andrew, for bringing this to the attention of your management.
@DonAlienware
"It would be nice if VB6 fans could have a venue somewhere outside of .NET. There is a strong vocal minority of VB6 fans that obviously know that VB6 is NOT .NET yet they keep trying to make a case for doing something with VB6 in various places that are obviously about .NET"
Thank you too, Don, for your suggestion. There isn't really a (Microsoft) forum addressing VB6. Even though VB6 and VBA are the same language and VBA is still current in Microsoft Office.
(Good luck with a Silverlight 6, I also require this. And with XNA, though it isn't really my area).
@Andrew,
We've taken a look at the ray tracing benchmark you linked to above and we have seen similar results where .NET Native is slower. Specifically, the benchmark runs ~15% faster on AMD64 JIT than on AMD64 Native when the BIT64 compiler flag is set and the benchmark is run on certain Intel CPUs. (We tested an i7-4558U.) This appears to be a result of our use of SIMD instructions in .NET Native. We did not expect this to be slower and we are continuing to investigate. We have been unable to reproduce this issue on an AMD CPU.
We were not able to produce a 50% regression, like the one you described, by comparing any two samples for the same architecture. However, if we compare x86 JIT to AMD64 Native, we see a similar regression. Please note that this is not an apples-to-apples comparison. Many benchmarks will always perform faster if run as a 32-bit process instead of a 64-bit process. When running the benchmark, please make sure that you either target 'x64' or uncheck 'Prefer 32-bit' if you are targeting 'AnyCPU'.
Additionally, we generally suggest that benchmarks iterate multiple times, report an average with variance, and throw out the first result. We find this helps reduce noise generated by the system. I’ve modified the Win8 benchmark to do these things and you can find a repo at: github.com/…/RayTraceBenchmark
We’d like to know if you still see a 50% regression when comparing AMD64 JIT to AMD64 Native. Also, we’d like to know what specific processor you ran the benchmark on. Please feel free to send me an email at xyziemba@<you know my employer>.com.
Thanks,
Xy Ziemba
Nice but please build Silverlight 6.0…
You can comment on VB6 but not WPF/Silverlight. what the hell is going on with you guys?
The whole metro/modern/store app is a disaster, no one is interested in that world of suck.
I remember going to a presentation by a MS Dev evangelist who pointed out that the metro interface was really just fullscreen IE. you guys have wasted three years on this crap. Being limited to the capability of HTML5 canvas, why the hell would anyone not just write a HTML5/JS app instead of limiting themselves to the tiny market for metro apps?
If there where any windows 8 worth a damn I'm sure you would have shown it at the build conference!, BTW hows that Windows RT working out? did'nt see anything about that at Build, hopefully that was the last of the Build series! four strikes and your out! bring back PDC with a focus on the P part! Time to get serious and fix the stupid ugly eye straining UI in VS for starters, it simply screams avoid this version! we have huge investment in .Net/WPF/Silverlight ! and you are costing us real money while you play these silly games and say sorry we cant comment at this time!
did'nt penguin pete B say that in 2011 ? wanna get thrown out on your a$$ at any real enterprise ? suggest a Modern/Metro solution! , want a good belly laugh? , check out metrostorescanner,
or better yet the app store itself! tip calc anyone? mad bird? AI tic tac toe? it's over , epic fail, period!
solid color rectangles are solid color rectangles, not bold and colorful live tiles!
you was more then enough money everyday on your stupid marketing to fix the few problem that WPF still has!
we are getting very weary of hearing how excited you are about the newest shinny crap no on wants while great tech like WPF is ignored! an you hit us with the smug "sorry we can't comment at this time, wait for Build 2015"
time to either give us a real Roadmap for .Net or get ready to become irrelevant to the rest of us!
Now hurry up an get a shill to post fluff comment that you CAN respond so your can continue to ignore myself an the others, pretty soon you'll have nothing but "Great job,Good Work" comments and we will be gone for good!
Well what about this long filename issue you blogged about 7 (!!!) years ago and said you had long term plans for?
blogs.msdn.com/…/long-paths-in-net-part-1-of-3-kim-hamilton.aspx
Not to mention one of the most highly requested features in VS (which was declined due to this issue) will never get fixed: visualstudio.uservoice.com/…/2156195-fix-260-character-file-name-length-limitation
I'm sorry, but I have a really hard time believing you when you say our feedback really matters. It's more like "we'll do these features we solely decided on, and when we're done let's go to uservoice and check off the ones someone else just happened to suggest".
Morten to the rescue!
@Morten: The long path issue sucks big time. We're the first to admit that. We've tried many times to fix it. The reality is that this problem is super hard to solve. We could paper over a few symptoms but this wouldn't address the general problem when people pass paths between apps. In order to fix it properly, we need to fix the underlying problem in Windows. As was pointed out by Kim, this is generally a very hard problem as MAX_PATH is constant that is virtually compiled into every (native) Windows application.
However, we've definitely seen the outrage when we closed the user voice item. I can't commit on anything, but we've taken note and we will revisit the is issue and see whether there are paths (no pun intended) that we haven't explored yet.
I understand that from your point of view it's hard to believe that votes on user voice matter. But I think there is an aspect that you overlook. The .NET team is super feedback driven. Does that mean that feedback is the ONLY input to our planning? Of course not. One is cost. Is it better to fix 10 issues with 500 votes or 1 with 5000 votes?
Of course, we also take into considerations of whether our work enables other items. It may not fix them, but by doing certain features we may get a step closer to address other highly requested work.
Sten – It's safe to say that most "social" comments are subjective and the .NET Team has to sift carefully through the noise level to partially inform their planning.
In my case, I don't have a use for Silverlight 6 or XNA. I think it's safe to say most Windows developers have a use for WPF and also see the applicability of WinRT XAML.
My comments were directed on the assumption that a properly motivated Microsoft can bring a lot of resources to bear on encouraging a productive future for .NET in a world that will care about that.
So it doesn't take a lot of drilling down among fellow programmers to discover the intense level of bitterness caused as near as I can tell by an important former member of the Microsoft leadership team and now everyone on the .NET Team that didn't abandon ship during the worst of it can lift heir heads out of the foxholes and try to make a fresh start which unfortunately to a great group of technology geeks, logically requires some backward looking attention and some atonement for what happened that was certainly beyond their control. It is my opinion that the .NET Team is avoiding some unpleasant areas and I wanted to remind everyone of it for the benefit of .NET as a whole. They don't just have the usual task of encouraging new adoption rates, they have to deal with a lot of anger in their customers. When someone is angry, the first step is to say you are sorry. I think it's really needed.
One way to say you are sorry, is to find a budget to put 5 or 10 devs on Silverlight 6 which could include a lot of brainstorming around branding WPF to Silverlight in a superset of the two runtimes and then including the result as the fourth member of Universal Apps.
It may sound silly, but when I talk to the silent majority .NET "soldier" WPF just didn't roll off the tongue right and Silverlight did. All the LOB MFC and Winforms you don't know about out there were gradually being imagined as a Silverlight solution. You were not competing with Flash. Those millions of devs aren't jumping to JavaScript or WinRT and all they see in 2014 is that all their options in the Microsoft world of Silverlight or WPF look very dead dead dead.
This is plain not good for .NET and that's why I bring it up, not because I subjectively need any of it. Moving XAML into the Windows API is just fine with me. But in the real world, I'm in a minority, everyone at BUILD is in a minority, and Microsoft is in trouble if they think that this will just blow over and I really don't want .NET to be in trouble. It's too good.
Please keep going as you are but just add the resources to say you are sorry and be very vocal about moving Silverlight and WPF down a path that gets you where you planned in a more long term and round about manner but brings all of the .NET community along with you on your journey.
Everything I've said also applies to XNA. So I won't repeat it, except to say XNA has great potential to be an on-ramp to .NET technology that fills a huge gap right now and really you only had a handful of devs on it. It is not perfect but it's a fantastic teaching vehicle for .NET that could get an order of magnitude more significant with some real attention.
@Andrew,
Our performance and code generation teams spent some time to further investigate the benchmark you sent us. The machine code we generated for the benchmark was hitting what's known as a "hardware hazard" (more details below). We have modified our compiler to avoid this problem and we now see similar performance (within ~5%) between .NET Native and CLR JIT generated code. Thanks for bringing this to our attention so we could get it fixed!
Please see the detailed analysis from the codegen team below.
Thanks,
Xy Ziemba
===================================================
Thanks, for taking the time to report this issue. My engineers were able reproduce and investigate the slowdown. The good news is that thanks to your report I was able to identify a missed optimization opportunity, and you should see the performance issue resolved in the next preview release of .NET Native. I’ve included some technical details on the issue below if you are interested in learning more about what we found and how it was addressed.
Code quality and optimization is not a static process as the compiler implements new optimizations, new hardware becomes available, and coding patterns change. This process is greatly improved by constant feedback from the community. My team and I really appreciate you taking the time to try out our compiler and provide us such great feedback. Please continue to let us know issues that you find whether they are correctness, code quality, new feature requests, or you’re just curious about how things work.
Some details on the issue:
In this case, the .NET Native compiler generated locally better code (e.g. it used fewer instructions, less code bytes, reduced number memory accesses), but overall we see the code slow down when compared to the code generated by the desktop CLR JIT compiler. This is because this "better" code is hitting a hardware hazard (en.wikipedia.org/…/Hazard_(computer_architecture)), in particular a store-forwarding stall which occurs when the processor’s store-to-load forwarding machinery is stymied (en.wikipedia.org/…/Memory_disambiguation). If you’re not familiar with this, this type of problem can occur when the same memory location is addressed via different sized memory operations too close together in time. The exact pattern of memory operations that can lead to a stall is dependent on the hardware.
<continued in next comment>
<continued from previous comment>
In the scenario you provided, the function CheckDouble access some Vec3 data, a structure with 24 bytes of data. The code generated by the desktop CLR complier uses 3 8-byte copies each time it is accesses a Vec3 while the code generated by the .NET Native compiler is able to take advantage of the modern Intel SSE2 instruction set and use one 16-byte copy and one 8-byte copy. This is great, as it reduces the number of instructions by two each time a copy of the Vec3 is made (one for the load and one for the store). The problem is that we didn’t use this optimization on every copy. We missed one copy and left it as 3 8-byte operations. Mixing the two types of copies introduced the store-to-load forwarding stall.
I verified that with the set of improved optimizations we are delivering in the next preview release of .NET Native the compiler is no longer mixing memory access types which avoids the store-forwarding stall. In addition, a few unnecessary copies of the Vec3 in CheckDouble have been removed which should result in overall better performance. Please let continue to let me know how your experience goes.
ian Bearman
Principal Development Lead
Microsoft Code Generation and Optimization Technologies Team
The vote for an updated VB6 on the UserVoice site is now over 6,000.
visualstudio.uservoice.com/…/3440221-bring-back-classic-visual-basic-an-improved-versi
It is the fifth most popular on the site.
But no response from Microsoft yet.
And no response to the suggestion to have a separate Microsoft forum for VB6 users.
But Satya Nadella's comment at Build 2014 "It's crazy to abandon what you built and crazy to not let what you build work on other platforms" epitomizes the thoughts of many VB6 developers.
It is crazy to abandon VB6 source code – we need a VB6 update now.
@Sten Ten
I agree. I develop (like many many others) a lot of new projects in Visual Basic 6.0.
A positive response (for a new version of VB6) from Microsoft is yet to be expected.
Visual Basic 6 has just risen to 5th place in the Tiobe Index of programming language popularity for May 2014
C# has dropped to 6th, and VB.Net is 11th.
Now is the time to bring back an updated VB6:
visualstudio.uservoice.com/…/3440221-bring-back-classic-visual-basic-an-improved-versi
VB6 – Microsoft's favorite programming language.
@Andrew – the second developer preview of .NET Native was released today and has a fix for the code generation bug you reported to us in the ray tracer benchmark. If you'd like to try it out, you can download the bits from http://aka.ms/dotnetnative.
In this article you claim to have addressed over 10,000 votes on the UserVoice site.
You could easily address more…
The vote for an updated VB6 programming language on the Microsoft VisualStudio UserVoice site has reached 7000.
visualstudio.uservoice.com/…/3440221-bring-back-classic-visual-basic-an-improved-versi
It is now the fifth highest vote, out of over 8,000.
But Microsoft haven't even replied to this, let alone 'addressed' it.
VB6 Microsoft's most popular programming language (Tiobe index, May 2014)
Microsoft have just announced on the VisualStudio UserVoice site that they will not bring back an updated VB6 programming language.
visualstudio.uservoice.com/…/3440221-bring-back-classic-visual-basic-an-improved-versi
Despite almost 7,500 votes and over 1,000 comments Paul Yuknewicz has (without even reviewing the idea) declined it.
He has also said that it would not be 'feasible' to open source VB6.
It seems that as Paul Yuknewicz was instrumental in the original cancellation of the VB6 update back in 2002 he is now covering up for his past mistakes.
The message to developers throughout the world is now clear – do not use Microsoft developer tools. You simply cannot trust Microsoft to protect your investment.
Is there a discussion forum for .NET Framework features similar to the codeplex forums for the .NET compiler platform (Rosyln)?
We don't have a dedicated forum to discuss the direction of .NET, which I assume you're looking for. Our forums are mostly about using the existing features. In cases where the feature is in preview they can be the same. For example, to discuss the future of .NET code generation you can use the .NET Native forum: social.msdn.microsoft.com/…/home
The best place to propose new directions for .NET is the Visual Studio User Voice site: visualstudio.uservoice.com.
260 character limit is still alive and well.
I have just tried the Windows Server 10 technical preview, build 9481 on Windows Azure and the 260 long path issue is still present. It seems that this "new" version of Windows has the same problem as we have been experiencing for the last 12 years. The version of Powershell in the preview is version 5 however it appears it still sits on top of CLR 4.0. I was so hoping for a fix to this issue, I remain astonished and incredibly disappointed to see it has not been fixed again.
In my job I come across this issue each and every day and that is not an exaggeration. We write complex software that requires complex naming and organisation and 260 characters is simply not enough. We either have to perform huge work-arounds like renaming folders, Visual Studio solution, projects or the install location of software throughout the Enterprise but sometimes that does not work. We make use of Powershell a lot and because it sits on top of .NET it suffers from the problems as well so we have to write custom assemblies using kernel32 methods to bypass System.IO. I personally have spent many hundreds of wasted hours dealing with this issue and honestly I am sick to death of hearing that it is a hard problem to fix. God knows how much time has been wasted overall! We all have hard problems to fix but we don't just hide away from them and say we won't fix them because they are hard.
We are in the year 2014, almost 2015. Microsoft is changing we hear, Windows is changing we hear and yet a problem that is causing constant pain to your customers is simply not been resolved despite being discussed Ad nauseam and being promised that the fix is coming. How many times have I seen that written down.
A casual search on Microsoft Connect reveals at least 10 separate entries all about the same issue. There are posts on User Voice and on countless blogs about this. When is someone going to actually do something about this issue?
Windows 10 is the opportunity. If this issue is not resolved I am going to have a serious look at using alternatives in our Enterprise as I have wasted enough hours resolving something that should have been fixed years ago.
An honest reply would be really appreciated that tells us what you are doing about this issue.