A first hand look from the .NET engineering teams
This post was written by Rich Lander, a Program Manager on the .NET Framework team. He’s also the one posting as @DotNet on Twitter.
This post was written by Rich Lander, a Program Manager on the .NET Framework team. He’s also the one posting as @DotNet on Twitter.
Late last month, we released the .NET Framework 4.5.1 Preview. We’re in a spot in our release cycle where we’d appreciate feedback on the pre-release version that we just made available, but we're also starting to think about .NET vNext. A few of us were talking about that, and we thought it would be a good idea to share our approach to feedback.
There are two major axes of feedback: time and place. On the time side, we split feedback into real-time and forward-looking. If you report an issue with .NET Framework 4.5.1 Preview, that’s real-time feedback. If you request a new feature, that’s forward-looking. On the place-side, we generally try to go to the places you choose; however, there are some feedback places that we look at and respond to first.
While I was writing this post, I saw the following comment come in on a recent blog post on HttpClient, about not finding an official support channel. This serves as a good example of why we should be clearer on how to report feedback and requests for support.
We always seem to have a preview release out, now that we are releasing .NET Framework libraries on NuGet. It also happens that the .NET Framework 4.5.1 is out in preview at the moment, too. While releases are in preview, we do our best to collect as much feedback as possible. There is always something that we should fix or change (some that we know about, and some that we don't) with preview releases. We rely on your feedback to determine what those changes should be.
We use the .NET blog to tell you about our releases, and we tweet those blog post URLs on Twitter. The best place to report product issues or ask questions about preview releases is in the blog post comments or on Twitter (include “@dotnet” in the tweet). That’s what @SebM chose to do, above. We do our best to keep on top of those comments. Feel free to send your comments about products that have shipped (that are no longer in preview) this way, too.
For NuGet packages, you can also use the “contact owners” link in the NuGet Gallery to give feedback on a specific package. For HttpClient, for example, you will see the contact owners link on the left side of our HttpClient package page, just below our gravatar.
We know that many of you use forums such as StackOverflow or MSDN. In fact, forums probably represent the place we get the vast majority of feedback and support requests from our users. They tend to ask a lot of “how do I” type questions that are just as easy for the broad community to answer, and that’s indeed what we see happening. There are some really great answers that we’ve seen on StackOverflow, for example. Thanks for sharing your expertise! Seriously. We also participate there, and some of us have StackOverflow tag subscriptions; however, we tend to target particular issues that we are concerned about due to large volumes of activity that we see in forums.
Visual Studio and .NET Framework Connect is another good way to report issues. It has the benefit of being fully integrated into our TFS bug system, so your issue show up in our bug queries. We have heard that a high volume of issues have started coming in via the Visual Studio Send-a-Smile program. Connect is a better way to send issue feedback, since it is integrated into our bug reporting system, however, I’d rather see the feedback come in through any system than not at all.
You may have seen in our .NET Framework 4.5.1 Preview post that in addition to describing new features, we reported progress on UserVoice requests. There are a lot of good requests on UserVoice, and we hope to see new ideas continue to show up there. We’re looking at that list as a sort of agile backlog that we consider as we plan for a new release.
I mentioned earlier that we try to meet you where you're at. We look out for feature requests wherever we can find them. That said, we use UserVoice as our primary home for forward-looking feedback. It has a nice feature set and a lot of activity, which means that a lot of you are already there.
Here’s a recent discussion on Twitter. Alexander asked for a particular update for WPF. I asked him to crowdsource the need for it on UserVoice, with the promise that I’d broadcast the UserVoice entry.
About 24 hours later, I saw this from Alexander:
Here are links to Alexander’s three posts, if you want to retweet or vote on them: moving WPF to DirectX 11, better DirectX support in WPF, and better camera support in WPF.
You might be thinking that Alexander lucked out with this particular interaction. Not true. Tweet @DotNet a new UserVoice entry that you've created about .NET and I’ll retweet it. Also, if you have a favorite existing UserVoice entry (again, about .NET) but you don’t think it's getting enough attention, tweet that to me (@DotNet) as well. The goal is to get a lot of people voting on the .NET UserVoice requests so that we feel confident about the relative priorities, as set by a large set of .NET developers.
Here are the primary forums to report feature requests about .NET:
These three tweets, both the feature requests and the general idea of broadcasting them this way, got a positive reaction from the UserVoice community. That’s great. Just so everyone is on the same page, I’m offering to retweet these feature requests to raise visibility and increase voting on UserVoice features. This isn’t a commitment to do the feature work. We also may choose to ship releases with features that came exclusively from other places. That said, we do think that UserVoice is a great source for a crowdsourced, prioritized feature list. We felt really good about checking off some important requests that came in from UserVoice in the .NET Framework 4.5.1 Preview, and we hope to repeat that.
Thanks again to Alexander for being a great advisor to the .NET team. Thanks to everyone else who has been advising us as well, particularly our MVPs. Be the next Alexander and share your ideas with us!
We’re, in effect, lending you our ears. Do tell us, Robin, what should we do?
My feature request is for proper documentation for the .NET components released since version 2.0.
I switched to .NET because I saw that almost all classes, methods and properties were well documented, often with remarks on usage, and examples.
Now almost no new features have a reasonable level of documentation.
For the start here's an interesting bug in AtatchedProperty behavior in WinRT in Windows 8.1:
And also another issue - this Url is crashing WebView both in Windows 8 and Windows 8.1, and the Metro IE11 as well. This should not been happening I guess. The problematic Url:
Note this page works just fine in Chrome or desktop IE11
I would like to see SIMD support for the JIT compiler and a way to allocate string objects without the need to copy it on the managed heap so I could use an unmanaged buffer to parse the data to become faster at parsing data. The same would be nice for byte arrays. The biggest limitation of .NET (in my opinon) to get high throughput are the memory copy operations.
I'm really looking forward to seeing you guys improve debugging further by supporting lambda expressions (and hopefully integrating Roslyn's C# interactive window to replace the immediate window). This would save me eons of time as I work with a lot of data and not being able to write LINQ queries while debugging really slows things down.
I also hope you work on making the debugger more reliable, as I frequently get "Function evaluation disabled because a previous function evaluation timed out" errors and they inevitably lead to needing to restart the whole debugging session. There has to be a better way to recover than this, that doesn't involve losing your current execution context. The goal you should work towards is that you never have to leave the debugger in order to write an application.
I agree with Jon that documentation really needs to be improved. No matter how many downvotes a page on MSDN gets, or regardless of the inaccuracy or lack of depth of this in the article, I have yet to ever see a single article actually get improved.
Related to this, I'd like to see an HTML documentation generation tool built right into the core Visual Studio product (as it is with Java and Eclipse). You guys abandoned Sandcastle years ago and I've found all the 3rd party tools to be buggy and unnecessarily difficult to use. Encouraging good documentation should start at the IDE level.
On the purely framework side, I'd like to see the immutable collections eventually integrated in the core product. 95% of developers will never know they exist or use them unless they're put in .NET proper. It would also be nice if some of the already-existing parts of the framework were given some attention- more LINQ methods, make MatchCollection implement IEnumerable of T, and please, please deprecate the non-generic collections so developers get warnings and are thus forced to stop using them (including some of your own!)
Finally, I hope overhauling UserVoice is on someone's to-do list. The 10 votes max with 1-3 at a time system is completely ridiculous. CodePlex's one-person one-vote system makes a lot more sense (though it still lacks the ability to withdraw your vote if you change your mind).
My future request - NEVER have a new version of the framework overlay an older version again.
When 4.5 was released, we had to back our code down to 3.5 to the code we produce for our users will be stable because someone made the decision to overlay 4.0. We can't code for workarounds since we can't tell if our code is running under 4.0 or 4.5.
Then, someone made the decision to have 4.5.1 overlay 4.5 and again the bugs are hidden from us and we can't code around anything. My guess is that this was done because of the criticism aimed at MS because of the amount of storage that the OS and other components take up on Surface RT and Pro. If (a big "if") I am correct, then you have managed to make developers lives a living h3ll just to save a few bits on a failed device.
We have already started down the path of building our own dev environment. It is about 80% done. It will allow us to take a single model and output code for .Net, iOS, or Android. If the next version overlays any other version, we will officially be done with .Net. We will still support the current 3.5 based code for our customers, but there will be no forward path.
I love how EF5 seamlessly does what a person used to have work harder at to get the POCOs. The project I am presently doing is so much nicer due to how EF5 works, and how much cleaner it lets my code and my development experience be.
I just hope the team keeps pursuing that kind of result in .NET in general.
While I do appreciate the effort to drum up support for Uservoice requests I do have some gripes with the UserVoice service. Here they are in an effort to help you feel our pain.
1. Clearly there are lots of duplicated requests. It would be grand if you had a team of summer students coalesce them or at least propose such a change to someone more knowledgeable of the technologies involved and approve/deny the combinations.
2. It's pretty painful to spread 10 votes across all of Visual Studio especially given that the IDE warrants votes, the separate languages warrant votes, .NET should be a separate category altogether. How can I weigh "Move WPF to DX11" against "Parallelize the C++ Linker" against "Bring back color icons" etc. I hope you feel the pain there.
3. Speaking of WPF, another issue I have with UserVoice is issue resolution. Take this beauty for example: visualstudio.uservoice.com/.../2216399-create-a-native-wpf-ui-library
A wonderful request but an awful resolution. The whole issue revolves around us wanting a richer way to interact with WPF. Our scientific desktop app which uses C++ and WPF would really rock with this. The resolution of "Completed: Write a Metro style application with C++/CX" is simply unacceptable and shows a disdain and lack of understanding of the whole issue.
So what do I do now with that issue? Open another one with the same request? We'll never be a windows store app and this puts forth an attitude of "Desktop developer? Get lost" from MS (which I'm sure you don't intend but that's certainly the message we're receiving).
I agree with @jschroedl - right now most of MS UserVoice pages looks like big unattended playgrounds. Lot of duplicate entries, very few responses or progress. Lot of types of entries in one large UserVoice page. Some management here is clearly required.
Twitter is NOT a medium for proper feedback for a platform the drives a billion dollar industry. UserVoice is great but there's no place for bugs, and no liability for these bug reports or expected follow up. This is what connect is great for, and it's beyond me why you are not using this.
oh and yes your DX support in WPF is absolutely horrible and an atrocity. D9DImage? Really?
Unfortunately, I have not the feeling that the feedback at “Visual Studio and .NET Framework Connect” is considered much. I appreciate new features in .NET but it would be much more important to solve some serious issues which are posted on Connect (especially regarding WPF). Most of these issues are “Closed” because it was not enough time for the release but then they are never considered again for a later release.
Most horrific is the fact that a lot old Connect issues are not online anymore. The only way to see them is via Google Web Cache.
This should not be the way how you handle customer feedback :-(.
- update documentation - not only does MSDN lack proper samples and descriptions, but XML-doc comments in are rather bad
- don't push new features until you've gone back and fixed the old ones.
- improve the performance of commonly used classes/scenarios (string, decimal, reflection, etc)
- make it possible to cast generic function result directly, e.g. not return (T)(object)someClass, but (T)someClass.
@Jaanus -- You said:
"make it possible to cast generic function result directly, e.g. not return (T)(object)someClass, but (T)someClass."
That's what generic constraints are for. If you constraint T to some interface or class, in terms of someClass, then this will work. No?
@Morten -- Agreed. Twitter is not a good solution for all of our feedback. We largely use it for a certain set of things, like publishing our blog post links, and responding to real-time feedback. It works well for that. Oh, we sometimes respond to feedback from @DotMorten there too. ;)
Thank you for your feedback. In the world of Solid State Drives, hard drive space is no longer free. It's not very practical to install multiple versions of .NET Framework on the machine. We are receiving feedback from consumers and enterprises. Since .NET 4.5 is preinstalled on Windows 8, ISVs are seeing smaller install times for their app since they don't need to install .NET Framework. This improves end user experience with your apps and Windows. Multiple .NET versions on the machine will lead to installation of separate updates for each .NET version present on the machine. Side by side frameworks also lead to higher RAM usage because .NET files cannot be shared across processes. Having said that, we understand that compatibility is highest priority to accrue all these benefits. We have been working with hundreds of companies and we have received very good feedback around .NET compatibility. Large Microsoft products are running successfully on .NET 4.5. There are large, medium and small businesses that have also provided us positive reports on .NET 4.5. I'm sorry if you ran into any issue, I'd like to understand the issue that ran into. Could you please contact me on netfx45compat at Microsoft dot com to discuss? I appreciate your feedback. We want to help you build great apps with great end user experience.
WPF - Please add the ability to define max selected items on a listbox and make selected items bindable