On the task board, navigate to it in TFS go to Work -> Board, we should be able to view, and change, a BPI or Bugs current state. The task that are assigned to the BPI or Bugs state is easily viewed and changed since they are in swimlanes, however, the parent WI on the left doesn't display its current state. If there are multiple big items for a release, it get laborious to open the PBI, or Bug, every time you see all task a completed state just to verify that the parent WI is now in the desired state.

See the red blob on the screen shot for an idea of what I mean. Now image having 50 something PBIs/Bugs to review for a release. A lot of time would be saved by simply showing the current state, and even more time saved by making it editable.

Currently only corporate accounts are allowed complete access to the documentsLibrary capability. Individual accounts can read files from the library only through a file picker, and you must maintain a list of files in the StorageItemAccessList if you wish to access those files in the future. This is cumbersome because you have to determine which files need to go in that list and maintain the list. There is also a 1000 file limit, which may not be enough (it is not in my situation). It is not acceptable to have to tell users "We're sorry, but Microsoft has determined that you can only have access to 1000 files from our app because we are not a big corporation." I propose two possible solutions:

1) Allow individual accounts full access. The user could be prompted on install the same way they are prompted for things like Location.

2) Alternatively, remove the 1000 file limit from StorageItemAccessList. This is less desirable because it still makes developing more cumbersome if you have an individual account. But if for security reasons you do not want to open up the documentsLibrary at least remove the 1000 file limit so my app is not broken.

1) The property pages provide a large set of macros ($(...), %(...)).
For example '$(OutDir)$(TargetName)$(TargetExt)'.
Unfortunately there is no way to see the expanded text.
2) It would be fine to see the expanded text in a tool tip or to have a context menu item that allows switching between expanded/symbolic views.
3) Paths should be checked for plausibility/existence. Especially when using relative paths (e.g. ..\..\lib). It is not always clear what is the current directory.
4) It should be possible to convert an absolute path to a relative path.
5) It should be possible to navigate to a compiler option be searching for the abbreviation of a feature (e.g. /SAFESEH). Nobody knows by heart on which property page this option is.
6) Why is the property dialog not resizable?

When I'm refactoring member names in a class, it often takes quite a lot of time to scan the entire solution for references to this member (we have about 4,5k source files in 26 projects). It would be great if IDE could "predict" which members I'm going to refactor next (e.g. properties within the same class) and index them together with the current member being refactored so the next operation will be much faster.

Example:

public class PublishData
{
public string Name { get; set; }
public string Text { get; set; }
}

When I refactor the "Name" to "Title", the IDE, while scanning for references, would also "index" the "Text" property references assuming that I'm going to refactor it as well (and if my next step would be refactoring "Text" to "Body" the operation won't take that long since the IDE holds the references already).

I'm sure there are many developers out there with "older" systems that are completely capable of running Windows 8 64-bit and Visual Studio 2012 but are not able to develop and test Windows Phone 8 applications because of Microsoft's choice to make the Windows Phone 8 emulator a Hyper-V virtual machine. There should be a mechanism to run the emulator using either VMware Player or VirtualBox which will use SLAT if it's present but will continue to work if it isn't or update Hyper-V to do the same.

I don't understand this choice as I am able to write applications for Windows 8 using the built in simulator and I would think that is more involved than developing for the phone. Making it MORE difficult to develop for the phone isn't smart when you need more apps to compete with other ecosystems.

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