Please throw the StackOverflowException when the stack contains StackMaxSize - 100 (or 256 for that matter) entries which allows normal handling of the exception.

Imagine a user interface to define group-in-group memberships. Without considerable effort by the programmer it is easily possible to add a parent group indirectly as a child group which leads to an infinite loop.

When I now can make make a method GetMembers(aGroup, recursive), call it after every change from within a try/catch that catches the StackOverflowException then I can provide feedback to the user, undo his last change and everything is handled proberly and without me having to fill dictionaries etc. to determine the endless loop before it even occures. It is much easier to run into the exception and then handle the problem that preventing it from occuring.

Java for example allows (or at least 10 years ago did allow) to do exactely that and it would be great if .NET would allow such behaviour as well.

We request Microsoft include in their next release of the Silverlight runtime, the ability to retrieve Microsoft Intermediate Language (IL )offsets via System.Diagnostics.StackFrame.GetILOffset. We produce a product written in Silverlight in a growing number of installed sites. In the field we have experienced exceptions that we cannot reproduce in our development or test environments. They are intermittent problems, nevertheless, our customer’s opinion of our software takes a hit whenever these exceptions occur and our ability to use customers as a reference for further sales is jeopardized. We must fix these problems.

To fix these problems we need to know the source line number in our code where the exception takes place. We understand that Silverlight clients cannot produce the source code line number for an exception. Therefore, we have taken the time to write our own stack trace that is written to an error log when we have unexpected exceptions on the client. In it we get the IL offset of each stack frame in the trace (using System.Diagnostics.StackFrame.GetILOffset) so that we can translate back to a source line number using the IL Disassembler included in Visual Studio.

This has worked fine in development, however, at customer sites the Silverlight plug in does not provide the correct IL offset. We get “ffffffff” for each stack frame. I’ve been informed and we have verified in testing that the Silverlight Developer version of the plug in provides the correct offsets, but the release version of Silverlight that is automatically installed on client computers does not provide it.

As the errors we are attempting to fix only occur intermittently, we need the release version of Silverlight to include this capability, installing the Silverlight Developer for these clients is not practical.

We have been a loyal Microsoft customer for many years and in general find the development environment to be reliable. However in this case, we find it lacking. How are vendors that produce products for customers supposed to fix intermittent errors in the product?

We appreciate your consideration of this request.

Rob Raymond

Like you wouldn't declare your vars at the top of your class' or method's body (anymore, bye bye, "C") but at the narrowest possible scope, the same should be possible with "using <namespace>" (in C#, other keywords apply to other languages).

Not only would this feature solve some common problems regarding identical class names in different namespaces, but would it also bring the supposed namespace closer to a reference to it. Think of a class that deals with XML serialization from line 300 on. Still the neccessary "using" declarations would be around line 15 or such, without the 285 lines between declaration and usage even bothering with XML.

I'd be happy with being able to declare the usages at class level (i.e. directly before a method definition).

Java has the cool feature that code invoking a method that could throw exceptions must either catch all potentially thrown exceptions or explicitly rethrow them. I miss a feature like that in .NET. It's a real pain to investigate which exceptions a method (or property) can throw. I do this obviously using the documentation, but this is unfortunately largely incomplete in case of exceptions, especially when exceptions could be thrown in base classes. At the end of the day we often end in catching the general Exception, but this is bad, even according to the Microsoft quality rules (FxCop).
It would be really helpful if we had a tool or feature that allows us to add catches for all possibly thrown exceptions. I personally think the Java way is best. The compiler should force the programmers to either catch or rethrow all potentially thrown exceptions. This could be an option in the project settings for those who don’t want to be forced to catch or rethrow all exceptions.

I've found several limitations within the Bundling & Minification framework in .NET 4.5, and though I've managed (with the help of Reflector due to the lack of documentation for the System.Web.Optimization assembly) to derive my own bundles and transforms, the most recent limitation is the lack of options surroundong the media attribute in CSS <link /> tags. There's no way of setting this, nor does such an attribute get written.

This makes it impossible to provide one bundle for the screen and another bundle for print, which I thought was pretty standard on large-scale modern websites.

It's difficult to derive a custom implementation to take care of this because so many of the methods between Styles.Render(string path) and the actual string being written are inside the internal sealed AssetManager class.

Please change this so that we can set the media attribute, or better, perhaps make the AssetManager an abstract class or atleast overrideable.

I have a basic ObjectRepository pattern as follows:

public interface IRepository<T> where T : Entity
{
T Create(T entity);
IEnumerable<T> Find(Expression<Func<T, bool>> expression);
IEnumerable<T> GetAll();
...
}

It would be great to be able to use derived interfaces like the following:

public interface IFooRepository : IRepository<Foo>
{
// non-parameterized type for use with ObjectDataSource
}

with ObjectDataSource. At present, it is only possible to use the actual implementing class (e.g. FooRepositoryImpl) as the TypeName, since ObjectDataSource won't find the methods defined in IRepository<Foo> if the TypeName is set to IFooRepository. Directly specifying IRepository<Foo> as the TypeName is equally undesirable since it can only be specified using the fully qualified name, which makes for rather unreadable code. The goal is to completely decouple the .ASPX from the persistence implementation, which is almost possible as of .NET 4.5, where it is no longer necessary to reference EntityFramework in order to get the schema data annotations necessary for EntityFramework persistence. This allows for separate model, interface and implementation assemblies, in which only the implementation assembly has a reference to EntityFramework.

I would like to encourage your developement staff to think of specifically making WMV encoding a part of Media namespace. It would improve VisualStudio.NET ! ... WMV would also gain more ground against competing video formats.

Consider the following:

Imports System.Media
Improts System.Media.VideoIO
Imports System.Media.VideoIO.WMVEncoder

If you made VisualStudio.NET with WMVEncoder that will also crop video that is already in .avi, .asf, or .wmv format, the utilization would increase the popularity of VisualStudio.NET and WMV.
I still use VisualStudio 2008 and Vista Business (though it is now year 2013); still works great!

Microsoft making a WMVEncoding dll to import - Add Reference in VisualStudio on Vista and Windows 7 platform - would improve previous VisualStudio.
The future of VisualStudio.NET should include improvement to media encoding.