I renamed a folder and updated my namespace declarations, but ReSharper 6 claims that the namespace should be a reflection of how it was before the rename. Where is it storing the file location data?
-
I suggest that you delete all `*.ReSharper` files. Resharper will recreate them from scratch without the "garbage". – Ofer Zelig Feb 22 '12 at 14:21
-
1I thought I had. I suppose I should give it another go. – Ian Warburton Feb 22 '12 at 14:37
-
It's all in `*.ReSharper` files. If all were deleted and you still get a namespace issue, I believe it is indeed related to your folder's structure... – Ofer Zelig Feb 23 '12 at 21:02
-
This also happened to me using Resharper 8.2.3. The problem is that it was ignoring folders with a space in the name. So `MyProject>Service Contracts>Common` was resolving to `MyProject>Common` instead of the expected `MyProject>Service_Contracts>Common` – JumpingJezza Mar 16 '15 at 02:09
6 Answers
Check to make sure your assembly name matches your new namespace. If you've changed your folder structure to match your new namespace, you may still see the ReSharper alert until you update the project properties.

- 9,564
- 146
- 81
- 122

- 950
- 1
- 10
- 16
-
-
17@Will S That's exactly what was vexing me until I found your post. In VS go to Project > [project name] Properties > Application & change "Assembly name" (this may not be required in your situation) as well as "Default namespace". Once I did this, ReSharper 7.7.1 quit complaining about the namespace. – delliottg Aug 23 '13 at 16:17
As delliottg's comment says, in Visual Studio, go to
Project
> [project name] Properties
> Application
and change "Assembly name" as well as "Default namespace".

- 9,564
- 146
- 81
- 122

- 4,384
- 2
- 36
- 53
I also had this problem with a folder/namespace and none of the above steps fixed it.
In my case I had to do this in Visual Studio:
- Right-click the "problem" folder in the solution explorer to open the properties
- Ensure the "Namespace Provider" is set to true
This fixed the ReSharper issue for me and I was able to adjust namespaces as normal.

- 1,859
- 1
- 19
- 21
-
I had a folder that was giving me total grief. Resharper kept telling me to add it to a folder with the same name within the folder. This was the perfect solution. – Michael Sep 22 '16 at 22:46
-
I use Resharper 2019.3.2 in VS 2019 vs 16.5.2 and I had similar issues.
When developing, I first work out my namespace hierarchy in a single project, then split the project in seperate class libraries. In the first stage, it is convenient to always let the subdirectory correspond to the namespace.
For example, my prototype MeshTools.dll project currently contains:
Meshtools ........................ 3 cs-files in \MeshTools
MeshTools.HeightField .......... 2 cs-files in \MeshTools\HeightField
MeshTools.VectorTools .......... 3 cs-files in \MeshTools\VectorTools
The above answers all assume one single namespace per project. Renaming directories manually may confuse Resharper and that can be repaired by setting the default assembly in the .csproj file to the proper namespace. Thanks for the tip.
However in my case, I have several namespaces in a single project, with each namespace in a Solution directory corresponding to a real directory. Setting the default assembly "Meshtools" does not affect ReSharper behaviour for HeightField and VectorTools, when things have gone wrong with the renaming.
I googled this issue and came by https://www.jetbrains.com/help/resharper/Refactorings__Adjust_Namespaces.html#
It turns out there is a right-click option on a Solution Directory -> Properties. You will find an option to decide, if the Solution Directory is a NameSpace provider or not. When something has gone wrong, Visual studio will reset the field to False. Set it back to True and Resharper will correctly refactor namespace or file location when needed..

- 1,951
- 21
- 26
If you're using JetBrains Rider, go to the Solution Explorer and right click on the csproj file, then properties in the context menu. In my case the Assembly Name was already updated but "Root Namespace" wasn't, updating Root Namespace allowed JetBrains to automatically update all namespaces.

- 3,105
- 2
- 14
- 17