Reclaim some Visual studio commands when using resharper

Reclaim some Visual studio commands when using resharper

I tried to change the key binding from the tools -> options window but it did not help and resharper was still claiming my shortcuts

But when I did It in below sequence it worked

  1. Change the binding for shortcut in tools menu
  2. In resharper options change the binding to intelliJ
  3. Save
  4. Change it back to vs
  5. In resharper options change the binding to visual studio binding
  6. Now press that shortcut and resharper will prompt conflict: select VS options
  7. Now press alt + enter
  8. resharper will prompt conflict: select Reshaper options forever checkbox


Restart VS if needed





  1. Ctrl + , : Navigate to anything
  4. @ in Quick launch menu
  5. BEST: hide the Menu Bar using VSCommands options
  6. Html or cshtml file: html5 then tab scaffolds
  7. Less file create and see css in parallel
  9. PASTE FROM CLIPBOARD: ctrl + shift + v


Productivity Power Tools:

New additions to Productivity Power Tools 2013:

  1. Peek Help
  2. Solution Explorer Errors
  3. Structure Visualizer
  4. Double click to maximize windows
  5. Timestamp margin
  6. Quick tasks – Edit Present On
  7. Ctrl + Click to Peek Definition`
  8. HTML Copy improvements
  9. Recently Closed Documents
  10. Match Margin
  11. Power Commands context menu cleanup
  12. 12.   Other features:
  13. Quick Tasks
  14. Power Commands
  15. Color printing
  16. Middle-Click Scrolling
  17. Organize Imports for Visual Basic
  18. Custom Document Well
  19. Tools Options Support
  20. HTML Copy
  21. Fix Mixed Tabs
  22. Ctrl + Click Go To Definition
  23. Align Assignments
  24. Column Guides
  25. Colorized Parameter Help 


visual studio keeps switching between threads while debugging

My problem here was that i wanted to debug only a particular thread in the sense that the breakpoint in the shared resource should be hit, only when it is being executed from thread 3, which is the thread that i want to debug.

How to clone any github repo and manage it in Visual Studio 2013


When I clone a github repo it doesn’t have a sln file and so doesn’t open in VS.

manage git repositories without sln file in visual studio


I tried out a few things in VS 2013 and Team Explorer but wasn’t able to accomplish this.

Also didn’t find a solution online


The only alternative is to create a new empty VS solution and add all the tracked files including .git into it and then manage the check in, etc commands from the Bash etc. Team Explorer will not identify this .git file as its inside the sln file.


Add folder as link in Visual Studio 2013


I followed this :

But it only allowed adding individual files as link, not folders,

Add Existing folder to a Project as link in visual studio


For multiple files

on the add existing items dialog SELECT all the files you want to add as an link and press the menu item ont he add button add as a link

For Multiple files in multiple locations

If you want to select a folder and add all the items on all subfolders then you can do that this way,

on the open dialog do a search for file types you want to add, select them all and do the “add item as link” action.


But this simply adds all files from all locations as link to current VS folder, it does not maintain Folder Hierarchy

The option mentioned here didn’t work for me:


  <Compile Include=”C:\MSDE\khematar\workspaces\3.8prod.win64\default\SME2\WebContent\**\*.*”>






how does visual studio build resolve references


I have referenced dll A which internally depends on Dll B.

In case I delete Dll B from my project folder, will the project still build?


How Type Resolution Works

At runtime, the CLR resolves the types in the assembly by looking in the GAC, the bin directory, and in any probing paths. This is handled by the fusion loader. But, how does the fusion loader know what it is looking for? This depends on a resolution made at design time, when the application is built.

During the build, the compiler resolves application types by using reference assemblies. In .NET Framework versions 2.0, 3.0, 3.5, 4, 4.5, and 4.5.1, the reference assemblies are installed when the .NET Framework is installed.

The reference assemblies are supplied by the targeting pack that ships with the corresponding version of the .NET Framework SDK. The Framework itself provides only the runtime assemblies. In order to build applications, you need to install both the .NET Framework and the corresponding .NET Framework SDK.

When you target a specific .NET Framework, the build system resolves all types by using the reference assemblies in the targeting pack. At runtime, the fusion loader resolves these same types to the runtime assemblies, which are typically located in the GAC.

If reference assemblies are not available, then the build system resolves assembly types by using the runtime assemblies. Because runtime assemblies in the GAC are not distinguished by minor version numbers, it is possible that resolution will be made to the wrong assembly. This could happen, for example, if a new method introduced in the .NET Framework version 3.5 is referenced while targeting version 3.0. The build will succeed, and the application will run on the build machine, but will fail when deployed to a machine that does not have version 3.5 installed.