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

Silverlight web service update fails to import wsdl

We've been battling with a strange issue for a couple of days now. Have searched the net for answers but none seem to solve the error.
Our scenario is: our organization has a Silverlight 5 application, which was developed in VS 2010, and everything was working fine. It is actually running in our production servers.Recently we migrated our development machines to VS 2015, and the machines themselves (new ones for the dept). The OS is Windows 7, same as before.
At first we were welcomed with that nasty MatchTimeoutInMilliseconds error, due to the MS Framework. Eventually MS released the 4.6.2 Preview version which covered this issue.
Ok. So back to implementing the changes requested, we created a new method in our webservice, and it complied just fine. We do have the [OperationContract] and [DataContract] tags in place. There is a question posted and answered with the justification that these tags were missing.However, when we go to the SL app and update the WS reference, we get this "Custom tool error: Failed to generate code for the service reference ..."
Custom Tool Warning messages include
"Cannot import wsdl:binding..."
"Cannot import wsdl:port..."
"Cannot import wsdl:portType..."
"No endpoints compatible with Silverlight 5 were found. The generated client class will not be usable unless endpoint information is provided via the constructor."
We're puzzled, because then we thought we might have done something wrong, so we rolled back the changes, and updated the service reference with no changes, and we get the same error. The Referece.cs file is generated with no code, and all references to the webservice are no longer recognized by the compiler.
We've also read some posts that offer as a solution unchecking "Reuse types in referenced assemblies". Doing that does clear these errors, only to generate others, since our app was built on this premise.
We've also tried deleting the service reference and adding it back again, but to no avail.
Eventually we reverted the SL app to the point it was compiling, which was before updating the webservice reference, republished the WS with the new method, and manually added the new method to the Reference.cs file, tested it and it works.
This, however, should not be -the- solution. It's a hassle and prone to errors.
We'd appreciate any help in solving this matter, or an insight as to why this is happening.
thanks

The whole problem is that, for some reason I still haven't found, VS fails to generate the code for Reference.cs.
As a workaround, we've managed to generate the Reference.cs file by using the SlSvcUtil.exe tool, located (on my machine) at "c:\Program Files (x86)\Microsoft SDKs\Silverlight\v5.0\Tools".
In order to get the same code as the one generated before the migration, I've used the following command and options:
SlSvcUtil.exe my_ws_address /namespace:"*,my_class_namespace" /ct:System.Collections.ObjectModel.ObservableCollection`1 /r:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v5.0\System.Windows.dll" /edb /ser:Auto
I didn't use the /out switch, but rather ran the command on my desired output directory. But you might want to look into that switch before running the command.

Can't use service reference in ASP.NET project

I successfully added a WCF Service Reference to my ASP.NET project, but I'm not able to use it.
I can't import the service referenece via using MyProject.MyService.
This worked in a standard Windows Form project and I now, that the requested service is working.
Thanks for your help.
Edit:
There occure Warnings during the generation of the service client
I think the "main" warning is the following
Warning 1 Custom tool warning: Cannot import wsdl:portType
Detail: An exception was thrown while running a WSDL import extension:System.ServiceModel.Description.DataContractSerializerMessageContractImporter
Error: Type 'Newtonsoft.Json.Linq.JToken' is a recursive collection data contract which is not supported. Consider modifying the definition of collection 'Newtonsoft.Json.Linq.JToken' to remove references to itself.
This warning comes only at the generation in an ASP.NET project. The generation works in my other projects.
It seems that this is a problem of a class I'm not responsible for. May I have to change the settings for the service reference creation or avoid some imports in the original WCF Service class?

We need some more information in order to troubleshoot this for you. Is the reference being added but you cannot use it?
I would suggest looking at the reference.cs file (under the service reference, you may need to tell solution explorer to show all files - little icon of the folders and files at the top) and seeing what namespace it has been generated with.
I think you're probably just not using the correct namespace to reference the client.
The other possibility: check for any compiler warnings, they might give you a clue as to what is going on.
EDIT: This seems to be an issue encountered by others. Do you have the json.net package installed?
Please see the following for details:
Getting "Recursive collection data contract" when referencing a WCF service with a slightly complex method

The type or namespace <blah> does not exist

Ok, I have had this one a million times before and it's been answered 1 million +1 times before.
And yet, once again. I have 3 projects, A, B, and C, each a DLL. Each project is .Net 4.0 (not the client build, full 4.0). Project C references A and B. They are referenced as projects, and the output is set to copy locally.
In C, I have two using statements in my .cs file:
using A;
using B;
When I compile, I get the complaint that is cannot find B. A is fine. B depends on A.
What the heck should I do? I've removed and re-added, closed VS2010, re-opened it, looked at the .csproj file. And I just cannot get it. Again, for the millionth time.
Someone please slap enough sense into me that I learn the source of this once and for all!
And yes, this is probably answered somewhere in StackOverflow, but not in any of the top answers I've checked so far. The terms are just too generic to be of use, too many questions where the answer is "duh, add a reference". I'm past that point.
Here are the errors I get. There are 3 kinds, but from past experience, the last one is the true one.
Error 130 'AWI.WWG.EXPMRI.MriUpload.Data.MriUpload' does not contain a definition for 'Database' and no extension method 'Database' accepting a first argument of type 'AWI.WWG.EXPMRI.MriUpload.Data.MriUpload' could be found (are you missing a using directive or an assembly reference?)
Error 114 'object' does not contain a definition for <blah>
Error 59 The type or namespace name '<blah>' could not be found (are you missing a using directive or an assembly reference?)
Aha I looked at the warnings, not just the errors, and here is what I see:
Warning 69 The referenced project '..\..\..\..\..\..\..\Partners\integration\framework\connectors\Partners.Connectors.Base\Partners.Connectors.Base\Partners.Connectors.Base.2010.csproj' does not exist. AWI.WWG.EXPMRI.MriUpload.Objects
That .csproj file is the "B" in this case. Even though I remove and re-add the project reference I get this. But it feels like I'm getting closer!
Hmm, I just found another DLL, call it "D", which "A" references. When I add it to the project, I start to get the complaint:
----------------
The Add Reference Dialog could not be shown due to the error:
The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
----------------
Could this be related, or just another distraction?
Ok, I found the issue, though I do not understand it.
When I add the reference through the IDE, it adds this to the csproj file of "C":
<ProjectReference Include="..\..\..\..\..\..\..\Partners\integration\framework\connectors\Partners.Connectors.Base\Partners.Connectors.Base\Partners.Connectors.Base.2010.csproj">
This does not compile, it WARNS that it cannot find the referenced project, then all those ERRORs happen. But then I change the ProjectReference to the following:
<ProjectReference Include="C:\...\Partners.Connectors.Base.2010.csproj">
... and it works just fine. Note that neither of those paths are anything close to 256 characters. The fully qualified one is only 135 characters. But perhaps the IDE is doing some silly decoration of the path.

The solution has to do with the file path limits in Windows, and they way the IDE translates relative paths into full ones, as explained in this blog.
The immediate solution is to edit the csproj file manually to use the absolute path. Until the reference is re-added, the absolute path will be valid. One day I may shorten my folders, but it's not top priority at the moment.
If you suspect you have this issue, look at the Warning messages from the compiler. I often have these turned off myself, only looking at errors. But the warning about "the referenced project does not exist" was the clue that solved this for me.
In case the other link disappears, here is the link to the MS article.
http://support.microsoft.com/kb/2516078
It is worth noting that this same error manifests for a variety of issues such as client-framework-targeting issues, and is logged as a warning when a reference fails to load. Presumably the reference error is only a warning because if the reference is not actually needed it doesn't matter.

I would make sure that your project has included the references to the assemblies.
I would check that the build order matches your dependencies
Finally, if everything is setup properly, you should see the following Build Order:
Doesn't look like this is your problem, but for completeness, I should add that another thing to check (if your project targets the .NET Framework 3.5 or above) is that the Target Framework for both projects match. If you are linking something that targets the Client Profile from a full version of the Framework, you will also get a 'not found' error:

Go to warning section and resolve all warning and you are done...
The warning section will tell you what all internal dlls dependencies are needed for the project you are referencing to.

I know this isn't the answer to your issue, but the error is quite similar when you are trying to reference a project with a higher .net version than the one you're using. IE: you can't reference something with .net 4.5 from .net 3.5

Basically, this sounds like a missing reference.
Some sanity checks I can think of are:
Are you sure that the project that generates the error is C?
Are you sure you are did not make a spelling mistake in the namespace B in your using?
Can there have been some compilation error in B before compiling C? (That may cause the compiler to fail finding the namespace in B).
Do you have any other compilation error or warning?
Edit
Another suggestion: is the class in the B assembly defined as public?

I got this when updating a project that we normally use via NuGet. I thought if I simply copied the updated built dll over to the packages folder I could test it without having to setup NuGet on my machine, but it wasn't that simple because my app was still looking for the old version number. Hope that helps someone out there.

After many hours of frustration, I discovered the following process to resolve this issue with a VS2017 solution:
Insure that all reference assemblies have been recognized and have current properties.
If assemblies do not show proper reference, right click the entry
and view properties. This action often resets the reference. This
action must be completed for each project in the solution.
After resolving all references, if the error continues, delete the
following:
-The Obj folder
-The Bin folder
-Reference to the offending assembly
-Clean and Rebuild the solution. Errors should occur.
-Re-reference the needed assembly.
The editor should no longer show the namespace error and build should succeed.

Create clean project and test minimal sets of assemblies you use in your project. This way you will be sure if there is something bad in your solution or if newly created project has same symptoms. If so, then maybe VS, .net etc is corrupted or something.

I started getting this error suddenly while trying to solve another problem
I solved this by going to Solution=>properties=>project dependencies and all the dependencies were off for the two projects I was getting a namespace error for. I checked the check boxes and rebuilt the solution with no errors.

I solved this using global::[namespace][type I want to use] in C# 6.0

With VS2017, this issue came up for me when the project in my solution was unloaded.

In my case, I have to check where the "WorkFlow"1 was implemented.
Hence, I compare the framework version of the projects/class libraries that uses this "WorkFlow".
After check that all projects/class libraries uses the same framework, I have to search ".WorkFlow" in the project/class library that was causing the builing error.
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Workflow.Targets(121,5):
error : The type or namespace name 'WorkFlow' no exists in the
namespace 'Proyect_to_build' (are you missing a using directive or an
assembly reference?)
It turns out that the .dll that contains "WorkFlow" was missing in the "Reference" folder. Once added the .dll, the project/class library compiled successfully.
Again, in my case, I wasn't using this .dll and I only need compile the project/class library for enable breakpoints in a certain part of the program (where "WorkFlow" is not involved at all), but well, after add it (the .dll with the "WorkFlow" source code), it compiled.
1 "WorkFlow" comes from a legacy code using custom code for WorkFlows.

Can you use WCF services with Windows Phone 7?

I've only been able to find a couple of people online mentioning this, and it seems to be as simple for them as adding the service reference.
However, when I attempt to add a service reference for my WCF service (which works correctly in a regular console app, so I have ruled the WCF out as the problem) I receive a host of errors.
Warning 5 Custom tool warning: No endpoints compatible with Silverlight 3 were found. The generated client class will not be usable unless endpoint information is provided via the constructor.
Warning 6 Custom tool warning: Exception has been thrown by the target of an invocation.
Warning 2 Custom tool warning: Cannot import wsdl:portType
Detail: An exception was thrown while running a WSDL import extension: System.ServiceModel.Description.DataContractSerializerMessageContractImporter
Error: Could not load type 'System.Runtime.Serialization.DataContractSet' from assembly 'System.Runtime.Serialization, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e'.
Warning 4 Custom tool warning: Cannot import wsdl:port
Detail: There was an error importing a wsdl:binding that the wsdl:port is dependent on.
Warning 3 Custom tool warning: Cannot import wsdl:binding
Detail: There was an error importing a wsdl:portType that the wsdl:binding is dependent on.
Error 7 Custom tool error: Failed to generate code for the service reference 'ServiceReference'. Please check other error and warning messages for details.
I find it strange that the first error mentions Silverlight 3, as I just completely uninstalled and reinstalled all of my development tools to ensure that I was using the latest version of .NET and Silverlight.
These errors look similar to the ones I see if I attempt to create a new Silverlight project and do not check the box "Enable WCF RIA services". I have not been able to find any means to enable that for WP7, if that is indeed the problem.
Any assistance from you scholarly gentlemen (and gentlewomen) would be much appreciated.

I ran into the exact same error, and changed the collection type to System.Collections.Generic.List instead of System.Collections.ObjectModel.ObservableCollections. This was odd since I did not even check the box for "Always generate message contracts".
Hope that helps.

Mmmm, I just changed the service reference config by unticking the "reuse type ...." box and then update worked and it generated the service config file. Not sure if this will help you?

Remember that Silverlight - even for Windows Phone, which uses a specialized version of Silverlight 3 - does NOT work with all WCF Service bindings/endpoints, but instead only supports a subset (which excludes WS-HTTP bindings, for example.) Your simplest bet is to create your WCF service for Silverlight applications using the "Silverlight-enabled WCF Service" template in Visual Studio (under Add/New Item/Silverlight).
This blog entry (http://blogs.msdn.com/b/silverlightws/archive/2009/03/20/what-s-new-with-web-services-in-silverlight-3-beta.aspx) from the Silverlight WCF Team Blog should shed some light on the possibilities. You may want to check out he whole blog (http://blogs.msdn.com/b/silverlightws/), as it has some interesting how-to and gotcha articles.

This problem occurred when you run the Visual Studio with Administrator Privilege. What you can do for a workaround is run the Visual Studio without Administrator Privilege, add the web service reference that will generate the proxy classes and close the solution. Open the project solution again in Visual Studio with Administrator privilege. A bug report already file in Microsoft Connect.
https://connect.microsoft.com/VisualStudio/feedback/details/624984/error-warnings-when-adding-web-reference-on-windows-phone-7-project?wa=wsignin1.0

Yes this is one strange Error. You will be able to return Strings, Integers etc but anything else like ArrayList and so forth you will get this error.
There is nothing wrong with your code, there is just a bug with VS. Microsoft have fixed it (check service packs) but if you are programming for Windows Phone 7, the bug is still there.
You have Delete the Service, Then Bin and Obj Folder. Save and close VS. Then restart the Project, Add the Service Ref (DO NOT DEBUG/RUN the app). Oh Yes DO A BACKUP FIRST. It should be ok. You may have to repeat this process everytime you Update the Service.
This should fix it, if not, you may have to open a new project or if possible recreate the Webservice.

The answer is yes, you can access WCF services from WP7, and like a previous poster noted it only supports WS-HTTP. In the case that you are trying to access a WCF Service for a Silverlight application then there are a few things that you need to do:
Update your Silvleright Toolkit to the latest. Go get it from Codeplex
Add a reference to Microsoft.ServiceModel.DomainServices.Hosting to your silverlight project.
Go to the Web.Config and add the soap endpoint:
<domainServices>
<endpoints>
<add name="Soap"
type="Microsoft.ServiceModel.DomainServices.Hosting.SoapXmlEndpointFactory,
Microsoft.ServiceModel.DomainServices.Hosting"
/>
</endpoints>
</domainServices>
Do not worry about the "system.serviceModel" warning; ignore it
Add the service reference. "But, which uri?" you ask. The address of your service is this one: [namespace of your ria service]-[classname of your ria service].svc where . are replaced with -. So, if I have created my service inside of a Services directory in my SL application and the namespace looks like this:
namespace myApplication.Web.Services
{
[EnableClientAccess()]
public class SuperService ....
then the address would be:
http://localhost[:port]/Services/myApplication-Web-Services-SuperService.svc
Let the tooling do the rest. If you get some funky errors then save and close VS and start again and it all works.
I hope that this is the answer that you are looking for.

The following solved my problem:
I created a new WP7 project added the wcf service.
Then I copied the Service References folder to the directory of my project that gave me this problem and restarted Visual studio and built the application.
You should get namespace errors inside your Reference.cs; just change the namespace to the current project namespace.