We Keep Coding

C# with WPF -- Using project reference and adding to reference list does not work

In a specific project (meant for web-services) in my .net solution (Visual Studio), I have added a using directive:
using ourSystem.Common.WPF
and I also added the corresponding reference (pointing to the DLL) to the project file.
The web-services project compiles, builds, and works just fine until I try to add the WPF project.
When I add the WPF project, I get the error message:
Error CS0234 The type or namespace name 'WPF' does not exist in the namespace 'ourSystem.Common' (are you missing an assembly reference?)
I have looked at similar questions on stack overflow and web posts elsewhere, but nothing seems to work.
It appears that the problem must be some sort of incompatibility between files.
NOTE: The Visual Studio Solution (VS2019) I am working on has several projects, and this DLL/namespace works in many of the other projects, just not the project that I am trying to add it to.
Both the WPF project and the project I am trying to reference it in are v4.5.2
Thus, at least for that attribute, they should be compatible.
For what it's worth, I have also tried unloading projects, and reloading them. This often changes the error count from about 4 (all the same message) to well over 100, and it seems to lose all references to everything.
Edit added: It turns out the relative structure of the many projects within the solution (which I didn't describe in the original post of this question) was key in finding an answer. See my own answer below for details, if interested.
Any suggestions on how to fix this problem?

I was able to fix it essentially as follows:
I refactored the directory structure.
It had been
A-> Top Level GUI project that had called B & C
B-> Folder with the projects used by A including WPF, but not Web Service Project.
C-> Folder with Web Service Project
I then moved all of C to the same layer as B.
Having them in the same folder seemed to 'placate' the compiler.
I am not claiming that this was absolutely needed, nor that it should always be done, however it worked in my case.
I had to also redo some code within the C project to account for different layering within C's own folders (especially packages folder), as it still had legacy code as if it were the top-level project. The following link was useful in that: (especially the answer by Nikita R.)
How to fix re-layering problem

Trying to better understand Shared Projects and using them in different solutions

Even though Shared Projects have been around since Visual Studio 2015 (maybe as early as VS 2013 update2), I've only recently learned about them. Today I spent time trying to learn how to use them following a tutorial I found Shared Project: An Impressive Feature of Visual Studio 2015 Preview. However, the one thing the author did in that tutorial, which won't work for us, is he created the Shared Project and 3 other projects, all within the same solution. Of course, you can do that, but in practice we're likely to want to create a Shared Project in some solution, and then as time goes by, include that Shared Project in other solutions.
So what I did is instead of putting the Windows Forms application into the same solution as the author of that C# Corner post did, I created a new solution with a Windows Forms project in it, then I tried to add the Shared Project from the first solution. First, I tried adding the .sln file. That failed miserably. Then I tried adding the .shproj file to the second solution. That failed miserably as well.
Next I shared here on SO for ways of addressing this. I found 2 posts: Adding references in a shared (.shproj) project and How do I add a reference to a Shared Code project (.shproj) from another project. The second one gave me an idea. I decided I would simply add the Shared Project, from the first solution, to the second solution by clicking on the second solution within Solution Explorer, then doing a "Add Existing Project". That worked.
But I wonder, is that the way you're supposed to use Shared Projects? If so, it seems to me as though I could just as well created a simple class library in the first solution and then added that class library project to the second solution. Is there something about Shared Projects that make them inherently better to use, if you add the Shared Project to a different solution, instead of just adding a regular class library project to a solution?

A class library compiles into its own DLL and your original project references that DLL, whereas a project using a Shared Project will compile into a single assembly. One scenario I could think of with shared projects is that you can have single code base but has platform specific code sections marked by directives.

There is a good video on this subject even though it's being explained in the context of xamarin they do a good job i think.
https://www.youtube.com/watch?v=G5ov0gLZWgQ
Personally I I would always go with PCL (portable class lib) rather than SAP (shared project). I use shared code projects as documentation container in my projects. The project green icon stands out really well. I keep everything there from markeddown doc files to stored procedures and etc.

CS0436 compiler warning with a shared project

We have two solutions (C#, VS2015) that consist of a few projects.
The Basic-Solution with namespace Wpf has some classes that are re-written in the More Advanced - Solution in the namespace Wpf.Advanced because the more advanced solution uses different data types for example.
Since every code-change in one of the classes, that are present in both solutions, needs to be rewritten in the second file, we decided to change the structure and use a shared project as a single place where the files should be located for both solutions.
We now use "usings" in combination with precompiler #if #else #endif blocks to merge the two files into one by changing the data types based on the project (via a compilation symbol ADVANCED).
Now to the problem:
Since some of our example projects need to reference both, the Wpf and the shared project we get the mentioned warnings CS0436 because some objects, that now exist in the shared project and in the namespace Wpf.
How can I resolve this issue?
I mean, everything works, but no warning is better than any warning, thank you!

I just had similar situation. In exe project I referenced dll and shared project. The dll in turn was referencing shared project. The solution was to exclude the shared project from the exe project. Since the shared project gets referenced from the dll the exe gets all of them too.
It may look trivial unless you are not experienced with shared projects.

The namespace NamespaceName1 in NamespaceName2 conflicts with the type TypeName1 in NamespaceName3
This error occurs when the imported type and the imported namespace have the same fully qualified name. When that duplicate name is referenced, the compiler is unable to distinguish between the two.

How To Include Classes From Another Namespace In Assembly Instead of Writing Them Into A Separate DLL File?

I have a C# project with two namespaces. A GUI (Stoff3GUI as namespace) with the GUI xaml and .cs files, marked as starting object and a Library (Stoff3Lib as namespace) with all the classes doing the actual work.
Now, when I compile my code, I will receive a .exe file Stoff3GUI.exe and a .dll Stoff3Lib.dll. In Visual Studio, both namespaces are part of the same Project.
How can I compile the classes from the Stoff3Lib into the .exe file without producing a separated .dll file?
Edit:
Changed the xxx to my project name Stoff3 for better understanding.

If both namespaces are part of the same project, you should already only end up getting a single assembly.
This can differ with web project setups (various different flavours of web projects create assemblies in times and manners I've never understood) but for standalone executable projects, it really is "one project produces one assembly" in all cases as far as I'm aware. Double-check that you really only have one project - for example, you shouldn't have any references in the project to an xxxLib assembly.

I'm not entirely sure what you are doing here. It sounds like you might have a single 'Solution' with two projects My immediate thought is just to move the classes you want into the the GUI start project and delete the other project.

I believe what you really have is 1 Visual Studio solution with 2 projects.
Since a picture is worth 1000 words, and just to clear up terminology, here's what that looks like in VS2012:
The output of this solution is exactly what you describe:
TwoProjects\Stoff3GUI\bin\Debug\Stoff3GUI.exe
TwoProjects\Stoff3Lib\bin\Debug\Stoff3Lib.dll
The easiest way to accomplish what you want is to have a single VS project that contains 2 different namespaces. It's good practice to add folders that match your intended namespace structure, in your case Stoff3GUI and Stoff3Lib:
When you compile this solution, the output will be a single EXE, but you still maintain the separation of model and view namespaces very clearly in your folder/file structure:
OneProject\bin\Debug\OneProject.exe

Class Library Intellisense not showing up after adding the dll to the references

In C#, I made a ClassLibrary that has one Namespace and one Class.
I saved it and build it.
in other Projects, when i use it, I add it to my references by browsing to the .dll location.
But The Problem is that its name is not showing up in the Intellisense.
i.e when I: using ... my dll doesn't show ..
I'm Importing the library to a ConsoleApp.
both of the App and the library target Framework is .NET Framework 4.0
and I made their Assembly Version 4.0.0.0 so they're the exact same.
is there a setting or something that I'm missing ?
how can i make it pop up ?
I'm using VS2010 Professional
Thank you for your help

Maybe this be usefull, I was having a similar issue, I have a Web project, add the reference to a Class Library by selecting the project, but if I made a change on the class library, I can´t see that change on the intellisense of the Web Project, after try many things, I see that in the recently added reference, the value of the option "Local Copy" was set "True", then I change it to false and everething works!

I had a similar issue but in my case it was a property on the class. If you go to the file properties and look for a Build Action. Somehow mine was set to Content it had to be set to Compile.
I am using Visual Studio 2013. I hope this helps someone else.

Is the namespace for your assembly different than the namespace for your currently open project? I've had times when the current project and an assembly share the same namespace path the intellisense can mess up.
In general, Visual Studio is pretty good about intellisense generation, especially for C#. But sometimes there are some interesting conditions regarding ambiguities, and especially mixing project types where it just doesn't quite work.
Placing your content in the same namespace makes me wonder if you've actually fixed the problem (it may just be autocompleting the namespace in the currently loaded project rather than the assembly), but if it allows you to continue working, then go with it!

Right click on project on which you add reference of your dll/project select menu project dependancies and select/MarkCheckBox for reference project/dll. then it will work fine.

If the class library project had its name changed after creation, then intellisense may fail finding it due to directory issues, I believe.
I created my class with the generic "ClassLibrary1" or whatever, and then later changed the default namespace, class name, and project name inside of VS2017. I closed VS2017 and changed the directory name to match my default namespace, and then re-associated the project file in VS2017, and then re-added the reference in my main project file.
All seems to be fixed now.