I have a solution that worked fine until the last couple of days which contains around 15 projects that are DLLs or Webforms applications. I also use ReSharper which is another peculiarity related to this solution.
There are naturally projects referencing other ones within the solution and all but one compile independently and run OK except one Webforms app (A) that refers to namespaces within another Webforms app(B) DLL.
(A) has 7 exceptions when I try to debug this all along the lines of "the type or namespace name [MyClass] does not exist in the namespace '[(B) namespace]' (are you missing an assembly reference?)"
All the projects target the same .net version 3.5 all target the same processor CPU architecture, I have cleaned the solution, recreated the reference to (B) from (A), can see the namespace in the object explorer when looking at it from (A)\bin so it's there... but still (A) at build has these errors above and for over a day now I cannot for the life of me work out why... can anyone help?
If I run the Webform app (B), it builds and runs without a problem...
The mention of ReSharper is due to it also not working with this solution anymore (but does work with others solutions), the behaviour of ReSharper with this solution is that I cannot type characters into VS anymore unless ReSharper is suspended. Also when searching for types the list does not filter down at all - so there is some sort of corruption there although I have cleared caches related to ReSharper.
The problem might be your virtual directory in IIS, it was not pointing to the correct folder, so the page couldn't find the DLLs
Brad McA, have you unblocked that namespace? In REFERENCES folder, right click on the particular reference, and see if there is an option "Unblock", If u can see it, kindly unblock it. Thanx
Seems to be building now, reason for failure was a dependency on Newtonsoft.Json.dll which was built to target .net 4 (strange as this reference in (B) has been there for ages! why it would suddenly cause build issues).
Thanks to those who posted, have a lovely day.
the dll reference were origionally built in framework 4.7.1. when trying to add the reference in lower framework project say 4.5.2. It gives such errors. try to update your project framework from 4.5 (lower version) to the version of your reference.
I just reopened a project I haven't touched in a few months, and my copy of VS2012 is doing some strange things. I've seen it do these things before, but usually it works itself out after a Clean or after restarting VS.
I have a Common project, which is referenced by at least 2 other projects in the solution. I have a cs file that contains 2 enums, and a class. I reference those enums within the class, but VS gives me the little red underline that indicates a syntax error.
"The type or namespace name "SourceTypes" could not be found (are you missing a using directive or assembly reference?)"
The enum is literally located above this class. It is public. Also, if I do a build, it will build correctly. But the error comes back after the build finishes. Sometimes it doesn't build properly, and I have to build this project first without doing a build all. I have no idea why this reference has started doing this suddenly.
I also installed CodeMaid and AllMargins recently, but I don't think either of those could cause build errors.
Also, the common library is using Framework 3.5, because it is referenced by two other projects, one of which is SharePoint, and therefore 3.5, and the other of which is a WPF app, running 4.0 (not Client Profile)
Any ideas?
Update: Clearly the problem is that it doesn't recognize the namespace. In the using statement in multiple files, the namespace has the red line under it. Maybe I've got some kind of namespace conflict? But if I did, I would expect it to fail when I do an actual build, which it does not.
Solution: Feri got the right answer. By unloading the Common project, and then reloading it, the problem went away. All references to the namespace were corrected, and everything works smoothly again.
Solution: Feri got the right answer (but opted not to submit his solution as an answer). By unloading the Common project, and then reloading it, the problem went away. All references to the namespace were corrected, and everything works smoothly again. However, the problem seems to come back whenever I close/reopen VS. Unloading/reloading the project fixes it each time though.
I've seen the above question asked many times on many sites, but I haven't seen an answer that fixed the problem.
The scenario is this...
I am on .NET Framework 4.0, building a C# web application in VisualStudio 2012 Express with the Razor view engine.
I'm trying to use Microsoft.VisualBasic.FileIO.TextFieldParser in my code. From what I've read it is appropriate to do so by adding a project reference to Microsoft.VisualBasic, which I've done, and coding #using Microsoft.VisualBasic; in my view. However when I code...
Microsoft.VisualBasic.FileIO.TextFieldParser parser = new Microsoft.VisualBasic.FileIO.TextFieldParser(new StringReader(xxxxxxxx));
...in the view and rebuild the solution it returns errors: The type or namespace name 'FileIO' does not exist in the namespace 'Microsoft.VisualBasic' (are you missing an assembly reference?)
I know the reference is in the correct project because when I add and remove it I see it come and go from the references folder. I know the code I'm trying to reference exists because I can see it in Object Browser. I've even tried adding the reference using Object Browser instead of through the menus and although it gets added, the results are the same.
The solution it's in is a bit complicated so I tried just creating a test stand alone C# project and I get the same results. I also tried creating a test stand alone Visual Basic project, and sure enough, it works there as advertised. I'm by no means an expert on Visual Studio so I'm guessing that it's just something I'm missing in the configuration, but I'm at a loss to figure it out.
I've spent days on this, so any help anyone could offer would be greatly appreciated.
Right-click on your project and select Add Reference...
In the Reference Manager, expand Assemblies and select Framework. Then check the box for Microsoft.VisualBasic and click OK.
Credit goes to:
https://stackoverflow.com/a/17146200/2530360
I just had the same problem and your question title was more verbose so I figured it should have the answer inside.
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.
I recently migrated a solution from VS2005 to VS2010.
The solution is composed by about 20 project. One of them is in VB.net, the others are C#.
In VS2005 everything was fine, that is I was able to reference the VB.net project into the C Sharp projects. Now I cannot anymore.
The strange thing is that when I open in the editor a C# class referencing the VB.net dll, I get a compile error that sounds more or less like this:
"he type or namespace name 'VB.netProject' does not exist in the namespace 'Solution Namespace' (are you missing an assembly reference?)"
... and no, the assembly reference is there indeed!
However, when I close the files in the editor and try to compile again, the operation succeeds and the executable that I get works perfectly like it did in VS2005.
Is there a way I can manage to see the VB.net component in the editor? I am sure I am missing something, but I don't know what! :-)
Many thanks in advance for your help,
John
Unfortunately the visual studio sets (after the migration) the target framework to .NET Framework 4 Client Profile. If this target framework is set, some namespace could not be found (=> because the client profile doesn't contain this classes). Please verify, if your project has set this target framework. You will find this setting under the project properties.
Kind regards, patrick