Problem: Eyes get tired when looking on white background for many hours. Visual studio white areas, MSDN Library white area background for articles.

Solution:

Visual Studio IDE. Can set backgroundcolor to e.g. lightgray in one place so background color in all windows in IDE are affected.

MSDN Library web site. The preferred background color can be remembered in a cookie e.g.

This is nice features to have for software developers who use Visual Studio and MSDN Library a lot on a working day. Other websites and other applications on the host are not affected compared to solving the problem with dimming the display brightness or changing windows system colors.

Adobe PDF reader has a similar feature where "PDF paper" can be set to gray instead of white (255,255,255). Nice for the eye ;-)

Visual Studio 2010 when the build is against .NET Framework 4.0 doesn't allow you to add .NET Framework 3.5 references without having to first change the project and then change it back. The filter should be editable. Please fix this in a service pack. It is highly frustrating. I would regard this as a bug not simply a change request. We have many .NET components that are 2.0 &3.5. Rebuilding isn't always an option as it might require a verification cycle that is very time consuming. I have actually gone back to VS 2008 to create projects because it is such a pain. It has been a long time since I've been so frustrated with a change.

Today we put a todo comment and it appears in the todo task list. Many times that "todo" comments is optional and many times it become mandatory after a given date.

The suggestion is to put a date with todo comment. e.g.
//todo: 28/March/2013 : Replace this hard coded value by the value that we pull from database.

When a compilation triggered in IDE(Visual Studio), all such todo comments whose date has expired should be shown as error. To fix it either user can
1> postpone the date or
2> remove the comment or
3> mark the todo as complete. e.g. //todo: 28/March/2013 : Complete:
Replace this hard coded value by the value that we pull from database.

When a managed assembly depends on unmanaged DLLs it always a good ideia to set them as linked resources. It has two BIG advantages:

1. In VisualStudio, when you add a reference to the managed assembly, the unmanaged DLLs are automatically copied to the output path.

2. When the managed assembly is added to the GAC, the unmanaged DLLs are automatically copied to the same folder.

It would be awesome if you added a LinkResource option to the "Build Action" drop down.

It used to be possible to do this in VS2008 by editing the .target files but I never managed to do it under VS2010. It made my build process a LOT more complicated... :-(

(Submit on behalf of: Immad Naseer)
A majority of the time, I know the name of the file I want to switch to and I wasn't able to find a way to quickly switch to it. Alt tabbing to the file can take a long time. The other alternative could be to bring up the "Windows" dialog (Alt + W, W) and type the name of the file over there. While this is better than just alt tabbing, it does an exact match and forces me to type the file name from the start.
A "fuzzy" match where I can type any part of the file name and have the list automatically filter can do wonders for my productivity. This is low hanging fruit which I think will add a lot of value. If Visual Studio already has this feature, please do let me know how to access it and ignore my rant :)

VS should really have a deep look at Eclipse and implement some of the really small but extremely useful features of it:

1. Annotation bar in Eclipse is located at the right side of an editor and can show all kind of markers like errors, warnings, todo items, variable read/write accesses and so on. Once you get used to it, you can't live without it.

2. Highlight current variable: Eclipse shows both read and write accesses with different colors and that makes following the code extremely easy. VS shows only the variable occurances.

3. Use markers in the solution Explorer for faulty files and modules. In Eclipse, one can see if there is any faulty module or not just by looking at the Project Explorer window. In VS, you must popup the error view to check if there is any error. It takes too much space and time.

4. Right click on an error in the error view does not offer any fixes to the problem. One has to navigate to the fault and click on the fault itself. A lot of extra work.

5. When an interface is highlighted, please highlight also all methods that implements that interface, otherwise one has to open up the interface and browse that one just to find out what methods are in the interface.

6. Try to rename a namespace like x.y.z to x.y. Maybe ot's just me but I found no possible way doing it using the refactoring tools, because you can rename only z, but you cannot make is disappear.

7. It would be really useful to have optional tool support to implement the Java-way of handling directories and namespaces. It should not be mandatory, but for the ones who would like the namespace to follow the directory structure (and vice versa), it would be really useful.

Sigh. Sorry if any of these are already implemented :-)