How do specify one of several dot-notated namespaces which are ambiguous

Question

---

edits...

Please note, I am changing my fake references to folders to more properly reflect that they are not folders but namespaces. Some of the comments here were from before that change

---

I am quite new to C# so forgive me if I say something incorrect.

I am working within a large solution which has many projects in it.

I have been asked to move a particular class which is defined in a namespace from one of these projects to another. The problem when I do this however is that there is one object definition which is not properly referenced anymore. Here is an example:

Original Structure:

This file:

Main\Second.Level.Data\Second.Level.Data.csproj:

Originally had this line of code in it:

<Compile Include="Some\Nested\File\Way\Down.cs" />

And also, there was the actual file referenced which was here:

Main\Second.Level.Data\Some\Nested\File\Way\Down.cs

New Structure:

First we removed the Compile line from 'Main\Second.Level.Data\Second.Level.Data.csproj and added a similar line of code in the new namespace which was like this:

File: Main\Main.DataAccess\Main.DataAccess.csproj

New line of code added:

<Compile Include="New\Location\of\Down.cs" />

And we moved the actual file to the new location which is now:

Main\Main.DataAccess\New\Location\of\Down.cs

When this is done, all the references (aka all the using statements) seem to work except for one. There is one using statement that is like so:

using Main.Second.Level.Data.Yet.Another.Nested.File.Objects

In the old namespace, this using statement worked fine, however in the new one it does not. Specifically it fails on the third element (Level). My IDE gives an error saying "Cannot resolve symbol 'Level'".

I highly suspect that the reason this happens is that there actually exists another namespace which is named simply 'Main.Second' which has inside of it, it's own Main.Second.csproj file. I don't use this folder or the files in it for anything however I can't understand how the system would possibly know the difference between:

using Main.Second.Level.Data.Yet.Another.Nested.File.Objects

and

using Main.Second.Some.Other.Unrelated.Stuff

That is to say, I don't understand how the dot notation can tell where a namespace name begins or ends.

Addendum #1:

I have determined that the problem is there is no Project Reference to the new project in the csproj file of the destination project (or at least I am fairly certain this is the case). To resolve this, I have attempted to manually add this reference. Note, I am using JetBrains Rider IDE and tried several of the automated methods for adding the reference but none of them worked.

To add the reference, I found the ItemGroup block with all the other project references and added a new block. It looks like this:

<ItemGroup>
  <ProjectReference Include "..\Other.Project\Other.Project.csproj">
    <Project>{fh9w8es3-nota-real-guid-example1}</Project>
    <Name>Other.Project</Name>
  </ProjectReference>
  <ProjectReference Include "..\Main.Second.Level\Other.Project.csproj">
    <Project>{AD8234HS-NOTA-REAL-GUID-EXAMPLE2}</Project>
    <Name>Main.Second.Level</Name>
  </ProjectReference>
</ItemGroup>

Note, in doing this I had to come up with a guid for the Project element. I reasoned (after research) that this guid would be the one which existed currently in the solution file at the root of the solution, specifically it's the second GUID shown for that project. My example above is exactly the way I have made my code (specifically in that the GUID copied from the solution file is all caps where as the ones in the csproj file are not.

This however is not solving my problem. I feel that I am very close to a resolution however.

Answer 1

The correct answer to the original question I posed is that you need to add the ProjectReference to the ItemGroup as noted in the addendum I posted on the original question.

In my particular case however this was not possible because doing so caused a circular reference. Example:

Project A: had a reference to Project B Project A: Defined and used an internal class extensively and also used classes in project B

Project B: had classes that were only used in Project B

My change attempted to add one of the classes from Project A into project B however doing so would have required adding a back-reference to project A, which is what caused the circular reference.

In order to resolve this, I did the following:

1. Defined an interface in project B which would work for my new class defined in project A

2. Make the Project A class extend this interface

3. Change the references to the project A class which were in project B to reference the interface instead of the defined class. Doing this removed the need for a back reference.

Sorry this is so vague but it is proprietary code (and also extremely complicated) so not practical to post here, but I think I have encapsulated the gist of the solution.