Certain files are always difficult to merge, and under certain circumstances or periods, a file may contain "dangerous" content that always need to be reviewed before check-in after merge.

We had a situation where contents of a file was merged to development, and a number of corrections were made before check-in of the merge. Since the corrections were made within the merge operation (and no other changes were made on that file), these corrections where not caught when merging back to the base branch, and therefore continued to exist there.

I think that a light-weight solution to this problem would be to have the possibility to mark certain items as "dangerous", and that TFS then always would mark a conflict for those during a merge. It would need to be on specific items, since file types is too broad as definition.

basically just dont' remove text when the user presses space to auto-complete if there is text immediately following. one common-ish scenario is nesting functions in the same namespace

I write:

Foo::Bar( x );

then, later, I decide I want to use a Baz to store the result of Bar on so I type...

Foo::BazFoo::Bar(x);

but as soon as I press space to name my variable I end up with

Foo::Baz ::Bar(x);

I could be wrong, and maybe there is some situation where removing the text is a good idea - but I don't ever notice it (but perhaps this is because it is so natural). The only time I notice text being removed by autocompletion is when it annoys me in this way...

auto-complete is great btw. its certainly better than not having it at all, but removing the little frustations would make a world of difference.

The new C++ standard introduces local type-inference for variables with the auto keyword and language gurus recommend to use frequently, e.g. Herb Sutter says:
"Guideline: Prefer using auto to declare variables, unless explicit conversion to a specific type is required. It’s shorter, and helps to insulate your code from needless source ripples due to minor type changes." (http://herbsutter.com/gotw/_104/).

While this is convenient from a programming point of view, the IDE does not recognize the infered type of the variable and provides no help at all when we assign a return value of a function call to a local variable:
class Klasse
{
public:
void f();
};

Klasse* bar();

void foo()
{
auto b = bar();
// when I now enter b., no suggestion for f is shown

Take this scenario;

You are running a large test which needs to spread over X amount of Agents.
You may need to switch between web servers in the future as other versions of the web applications may be hosted elsewhere

Wouldn't it be nice if a form could be initiated at the controller level to select which server to use (it could extend to all sorts of global parameter settings). Then this builds an app.settings file (or adds to it) which can be deployed with the rest of the items for the agents to use

Currently I have only managed to create a form under the LoadTestStarting Plugin which is great for Local Runs but the form pops up on every Agent if its a remote run.

This idea will also make it more management friendly so non-coding users can fire up Visual Studio, click run test then set the parameters on the form rather than opening and changing cs files to re-point the tests to other servers and files (for other data for example).

At present the CLR only loads satellite assemblies if they are signed with the same key as the fallback assembly to which they refer. This means that the only people that can add new cultures to an existing assembly are the original authors. This includes the .NET Framework itself, ASP.NET MVC, Silverlight and every signed assembly released by Microsoft (or indeed anyone else).

The .NET Framework 4 is currently available in 23 languages (plus English). ASP.NET MVC 3 is currently available in 9 languages. If the language you want isn't on this list then there is nothing you can do to add support for your language. As an example Welsh is not on either of these lists.

I suggest that the way the CLR loads satellite assemblies is changed. Authors of assemblies could add an attribute to their assembly indicating that they accept relaxed rules on loading satellite assemblies. Hereafter the CLR would load any satellite assembly that matches the parent except for the key with which it is signed.

The consequence is that it would allow the author of the assembly to grant other .NET developers the right to add new culture support to existing assemblies. For example I could create my own Welsh resources for the .NET Framework and/or ASP.NET MVC. Furthermore it would allow my company the option to allow other developers to add additional language support to our products without returning to the development team to sign their satellite assemblies. This makes the post-build localization model much more realistic.

One caveat that I suggest is that the CLR would only load the satellite assembly if it contains resources only (i.e. no executable code).

I appreciate that there now is an Sync with Active Document button in the Solution Explorer (Dev11/VS2012). But that is still a manual task and if corrupts workflow.

I can not work with the 'Track active item in the Solution Explorer' set to on as when navigating different files it just jumps around to much.

So why not use a lesser highlight (e.g. just use another font color) to highlight the active item, and use the standard highlight for the current selection on the Solution Explorer.

One peculiarity in my VS setup/layout is that (as most devs I guess) I have a wide screen (1920x1080) and as such I have two code windows side-by-side and the Solution Explorer. (Like https://connect.microsoft.com/VisualStudio/feedback/details/344253/widescreen-features-history-annotations-view)

Tracking the active item then becomes a bit more complicated. So having the active item(s) with a different highlight would be beneficial.