Visual-studio – How to turn off CodeLens-References

Manually edit .sln file

This method is entirely aimed at renaming the directory for the project, as viewed in Windows Explorer.

This method does not suffer from the problems in the Remove/add project file method below (references disappearing), but it can result in problems if your project is under source control (see notes below). This is why step 2 (backup) is so important.

1. Close Visual Studio.
2. Create a backup of your .sln file (you can always roll back).
3. Imagine you want to rename directory Project1 to Project2.
4. If not using source control, rename the folder from Project1 to Project2 using Windows Explorer.
5. If using source control, rename the folder from Project1 to Project2 using the functions supplied by source control. This preserves the history of the file. For example, with TortoiseSVN, right click on the file, select TortoiseSVN .. Rename.
6. In the .sln file, edit all instances of Project1 to be Project2, using a text editor like NotePad.
7. Restart Visual Studio, and everything will work as before, but with the project in a different directory.

You can also see renaming solution manually or post which describes this manual process.

Advantages

• You can make the directory within Windows Explorer match the project name within the solution.
• This method does not remove any references from other projects to this file (an advantage over the Remove/add project file method, see my other answer below).

Warnings

• It's important to back everything up into a .zip file before renaming anything, as this method can create issues with source control.
• If your project is under source control, it may create issues if you rename files or directories outside of source control (using Windows Explorer). Its preferable to rename the file using the source control framework itself, if you can, to preserve the history of that file (check out the context menu on a right click - it may have a function to rename the file).

Update 2014-11-02

ReSharper has added an automated method for achieving the same result as the manual method above. If the namespace is underlined with a squiggly blue line, click on the action pyramid icon to either:

• Rename the namespace to match the directory name in Windows Explorer, or;
• Rename the directory in Windows Explorer to match the namespace.

In the second case, the final word defines the new directory name in Windows Explorer, e.g. if we changed the namespace to ViewModel2, it would offer to move the file to folder ViewModel2.

However, this will not necessarily update files in source control, so you may still have to use the manual method.

Update 2018-01-31

Tested with Visual Studio 2008, 2010, 2012, 2013, 2015, 2017 Update 1, 2, 3, 4, 5.

Update 2020-05-02

Tested with Visual Studio 2019.

This warning seems to have been introduced with the new Visual Studio 11 Beta and .NET 4.5, although I suppose it might have been possible before.

First, it really is just a warning. It should not hurt anything if you are just dealing with x86 dependencies. Microsoft is just trying to warn you when you state that your project is compatible with "Any CPU" but you have a dependency on a project or .dll assembly that is either x86 or x64. Because you have an x86 dependency, technically your project is therefore not "Any CPU" compatible. To make the warning go away, you should actually change your project from "Any CPU" to "x86". This is very easy to do, here are the steps.

1. Go to the Build|Configuration Manager menu item.
2. Find your project in the list, under Platform it will say "Any CPU"
3. Select the "Any CPU" option from the drop down and then select <New..>
4. From that dialog, select x86 from the "New Platform" drop down and make sure "Any CPU" is selected in the "Copy settings from" drop down.
5. Hit OK
6. You will want to select x86 for both the Debug and Release configurations.

This will make the warning go away and also state that your assembly or project is now no longer "Any CPU" compatible but now x86 specific. This is also applicable if you are building a 64 bit project that has an x64 dependency; you would just select x64 instead.

One other note, projects can be "Any CPU" compatible usually if they are pure .NET projects. This issue only comes up if you introduce a dependency (3rd party dll or your own C++ managed project) that targets a specific processor architecture.