In a solution containing several C# projects, the bottom line of the build results in the Output window provide a handy sanity check. The line reports something like this:
========== Build: 2 succeeded, 0 failed, 5 up-to-date, 0 skipped ==========

The numbers should match what you expected to be built depending on which projects you touched since the last build. If the "succeeded" count is larger than expected, it's a clue you may have touched something you didn't expect - time to check your pending changes in Team Explorer.

When a F# project is added to the solution, the rules for the result summary change in a way that is confusing at first and disappointing once you figure it out. The problem is that F# projects always count toward "succeeded" even when untouched.

Interestingly, if an F# project is in a solution by itself, it reports "1 succeeded or up-to-date". At least the ambiguity is made clear. However, in a mixed project, the results is simply misleading.

This issue was initially reported as a bug on Microsoft Connect before being deemed a missing feature, rather than a bug. The bug report, including the steps to reproduce, are here:
http://connect.microsoft.com/VisualStudio/feedback/details/768068/f-build-results-make-project-feel-dirty

If you're a C# developer, I bet you've used something like this before:

***** SomeType DoSomething(params AnotherType[] array){...}

It is a lot easier to use the 'params' modifier than to create a new array with all the paremeters of the same type you want to insert in a method, specially when it comes to small test projects.

However, using this comes with a disadvantage: you MUST use the array type. No IList, List<T>, Dictionary<TKey, TValue>, etc.. I believe there is no such reason not to allow these list-like types to use the params keyword. Example:

***** SomeType DoSomething(params ListType list){...}

Of course you may wonder how is the compiler going to know witch types to accept. Well, for that I have several suggestions: there may be an obligation to derive it from IList<T> or to have at least one indexer... I don't know. What I do know is that this would be a good feature.

I have specifically used the "Reparent" facility in VS2012 to break the parent-child relationship between two branches. I want to completely isolate them from one another and I want to specifically discourage or prevent the ability for our developers to easily merge changes from the orphaned child branch back to its original parents and vice-versa.

The current merge wizard still offers the former relation (parent or child) as a candidate merge target.

MSDN Community Support tell me that this has been left as a "convenience". I suggest it is a hindrance and it would be better to completely break the relationship by NOT allowing/displaying them as candidate merge targets.

Thanks for this great product, the effort invested in deisgn and implementation is amazing.

Some comments that hope to be useful:
1- The auto comelete textbox look like it queries on ienumerable (guess this is due to the summary field being not a part of the data source it self) but if we could detect that the summary field is a root data field "Not a computer one" and query on it using iqueryable that will be very good specially in large datasets.
2- Adding a prefix char count before quering can significantly enhance performance on large sets.
3- If i can assign a query with params to a model picker source and fillter with these params that whould be very very very helpful.
4- If adding a popup textbox that is one line but with a button that opens a popup with a multiline or even a rich text box this would be good and preserve screen estate.

Thank you and hope these comments add value to this great product :)

Most of the time, I start Visual Studio without using the run as admin option. Then I go to configure my projects, enter all important information (Name, source control, etc) and then After clicking Create, I get a warning that I need to run it as admin, and asks me to restart. However this still goes behind the scene and create the project's folder. I then have to go, open explorer, delete the project's folder, and then recreate it as admin in Visual Studio. Ideally, VS should be smart enough to let me know, depending on the type of project template I selected, if Admin rights will be needed or not. That would save a little bit of frustration.