21

I am calling a static method on a class like

Foo.bar()

Visual studio's intellisense recognizes Foo and autocompletes bar for me (it highlights Foo and everything like it is working fine). Everything looks fine until I go to build the project, and it throws an error saying the name Foo doesn't exist in current context.

I am using this static method call in other files, so I know the class is ok. The situation is too big to post code, so I am mostly looking for reasons to start looking into that would cause intellisense to function normally but get errors on compile like this.

Jarrod Everett
  • 761
  • 2
  • 7
  • 15
  • Can you post the exact error message and maybe just some part of the code where you get the error? – nemesv Aug 21 '12 at 20:03
  • Have you included the appropriate library reference in the project? – Peter Gluck Aug 21 '12 at 20:05
  • Do you have a property called Foo in the class you are trying to make the static call from? – Mark Rucker Aug 21 '12 at 20:06
  • the exact error message is 'The name "Foo" does not exist in the current context." All library references are good (it works in other files in this project), and there is no other property named Foo in the context – Jarrod Everett Aug 21 '12 at 20:10
  • What type is your project: web app, winforms, wpf, etc? Have a look on this question http://stackoverflow.com/questions/706603/the-name-controlname-does-not-exist-in-the-current-context maybe one of the answers is helpful to you. – nemesv Aug 21 '12 at 20:13
  • Isn't Foo in another namespace? – everton Aug 21 '12 at 20:19
  • 1
    Do you have anything else that has the name Foo? An instance variable, perhaps? Also, check that the codebehind file (.cs) and the UI file (dunno what you have, .aspx, perhaps?) are in sync. – code4life Aug 21 '12 at 20:40
  • 1
    Are all of the projects targeting the same framework version? – Daniel Mann Aug 21 '12 at 21:56
  • +1 @code4life - I agree, sounds like a naming conflict to me. – CoderMarkus Aug 21 '12 at 21:58
  • Or maybe conflict between partial classes – everton Aug 22 '12 at 12:44
  • nope, nothing else is named Foo and no partial classes involved – Jarrod Everett Aug 22 '12 at 13:47
  • I got this even though the project was building fine, but another project in the solution wasn't building. It was always with type names that were duplicates of types in another assembly and namespace, and it would happen even though the type names were correctly qualified. Intellisense bug? – yoyo Jan 28 '14 at 00:27
  • I have the opposite problem. My solution builds fine and Go To Definition works as expected, but Intellisense complains that the name doesn't exist. – Tim Sparkles Jan 30 '18 at 00:43
  • Same problem here. When i was hovering over a variable, visual studio was not showing anything. If i opened the variable with quick watch i was getting the error. It turned out that due to the fact that i originally had created the project with VS 2017, when i was using VS 2022 the issue was happening. Openeing the project with VS 2017, solved the problem. – Sotiris Zegiannis Mar 01 '23 at 16:58

16 Answers16

34

I've seen this error caused by differing versions of the .NET framework in the different projects. The Class Library I built was 4.5 and the application was 4.0, but the only error it gave was namespace errors. Changing the framework version on the class library and rebuilding it, then the application, resolved the error.

aherocalledFrog
  • 831
  • 9
  • 13
  • This solved it for me - to clarify for anyone else it appeared as a namespace error - but the actual issue appeared as a warning that I had been hitherto ignoring – davidhood2 Oct 01 '16 at 11:13
9

This can occur when namespaces, classes and variables become tangled when they have the same name. I have suffered with this before. Intellisense told me I was right, the compiler told me I was wrong! I trusted the compiler!

You have 2 options that I can think of

  1. Search your code for Foo, and see it it is being used for something other than the static class.

  2. Fully qualify the Foo.bar() call. MyApplication.This.That.Foo.bar();

Do it in that order...it's better to elegantly resolve the issue so you can just call Foo.bar() as this is more readable and maintainable than having MyApplication.This.That.Foo.bar(); all over the place!

Matthew Layton
  • 39,871
  • 52
  • 185
  • 313
  • 5
    You could also use a class alias.. `using SuprFoo = MyApplication.This.That.Foo;` – CoderMarkus Aug 21 '12 at 21:59
  • @TrueDevelopment absolutely! I forgot that one! – Matthew Layton Aug 21 '12 at 22:01
  • After looking around, I can conclude that there is nothing else named Foo to conflict with. Even fully qualifying the call MyApp.Foo.bar() gives me the error "THe type or namespace name 'Foo' does not exist in the namespace 'MyApp' (are you missing an assembly reference?). But I know it isn't an assembly reference issue. – Jarrod Everett Aug 22 '12 at 13:48
  • 4
    @JarrodEverett I am not sure what else I can suggest without seeing your source. If you are using multiple assemblies, are they all targetting the same runtime? I.E. .NET 4.0 / .NET client profile? etc – Matthew Layton Aug 22 '12 at 14:09
  • @JarrodEverett Why did you accept this answer if it didn't solve your problem? I have this same issue. There's no conflict, intellisense recognizes the identifier and provides the correct method list, I can hover over the identifier and it displays the correct information, I've rebuilt and restarted... still errors. We even refer to this namespace in other files with no problem. – DCShannon Jun 13 '15 at 01:05
  • @DCShannon You're trusting intellisense. Instead you should be trusting the compiler. Can you elaborate on your issue? – Matthew Layton Jun 13 '15 at 12:06
  • I had the same problem, but in my case, problem was with adding an existing file in main project (A) as link to another project (B) which that file was using a may static class in project (A). So in project B, my static class was unknown. I added static class to Project B as Link and problem solved. – Javad Norouzi Mar 01 '21 at 17:30
7

In my case I was missing a } at the end of one of the methods in the middle of the code which was causing the program not see the rest of the code and complain about the Methods I have defined after that point.

Mehrad
  • 4,093
  • 4
  • 43
  • 61
  • 1
    Your comment made me relook at the simple things, and I did indeed have this: AutoPostBack="True"meta:resourcekey... Added a space and everything was good. – smoore4 Jan 20 '17 at 04:04
  • I am glad my comment was helpful :) – Mehrad Jan 21 '17 at 09:07
3

I know this is a bit old topic, but I just experienced the same and for me it was because the file was not actually included in the solution.

I properly happened because I had renamed the class and then the file, which caused Visual Studio to still know the class and the namespace, but the compiler did not get the file as the renamed file was not included.

David Klempfner
  • 8,700
  • 20
  • 73
  • 153
Allan S. Hansen
  • 4,013
  • 23
  • 25
3

Old thread I know, but I've encountered this issue when referencing a static method from within a unit test project - intellisense said the method was there, but when I tried to build/run the test (in Debug mode) I got the error 'name doesn't exist in current context'. In order to fix it I had to rebuild the project containing the referenced static method in Debug configuration (it had only previously been built in Release configuration) - after this the test built and ran OK.

Donald McInnes
  • 61
  • 8
1

Consider doing a Clean and then a Build on the project with the problem. It is possible for the editor and Intellisense to correctly discover the class, while the compiler works with files that are out-of-date. (I had this same problem, and that's how I resolved it.)

Michael
  • 11
  • 1
1

this is an old article I know, but I just encountered this issue and has been puzzling me for couple of days, and eventually got to it: click on the class file, in Solution Explorer, then look at the Properties tab; make sure Build Action is set to "Compile".

user1012598
  • 417
  • 1
  • 8
  • 18
1

Adjust the related file. If the error code in Default.aspx.cs, you need to change the top line in the file Default.aspx as below:

Replace "CodeFile=" with "CodeBehind"

Hope this can help.

-Thanks, Thai_FUV

Mebin Joe
  • 2,172
  • 4
  • 16
  • 22
Tran Thanh Thai
  • 11
  • 1
1

In my case I had to reload the project that was marked "missing".

  1. Project > Unload Project
  2. Project > Load Project
  3. Clean, Build Solution
Radall
  • 394
  • 4
  • 17
0

I have run into this probelm a few times and so when I do, the first thing I check is if the assembly not recognized has any Nuget packages. In my cases they always have and I simply forgot to install the same packages in the assembly of which the reference to the un-recognized assembly is in. A re-build command and problem fixed. I hope this helps someone. This same error message can be given for multiple things so this particular case, may not apply. If you have not used Nuget than I would suggest trying the other answers

SimperT
  • 2,837
  • 2
  • 15
  • 19
0

I also was running into this issue creating a data access layer and had static methods being called with the same symptoms: Intellisense finding it but not the compiler. I tried many of the above, including fixing the .Net version.

When adding the source files to the project I also changed the namespace. With the file with the issue, I forgot to change the namespace to match when it was imported at another time.

William Biesty
  • 11
  • 5
0

Closing all tabs of MonoDevelop. Then Closing MonoDevelop. Finally opening MonoDevelop again solved the problem for me.

chelder
  • 3,819
  • 6
  • 56
  • 90
0

Mine was a little more convoluted solution. Project A referenced projects B and C: both references had Copy Local to true and both produced assemblies with identical names. When building the referencing project, the output assemblies from projects B and C were copied and one overwrote the other because they had the same name. VS was then looking for the references within the build directory and only found the assembly that had "won."

yagni
  • 1,160
  • 13
  • 15
0

My solution to this problem that occurs every now and then:

  1. Find the class that is giving you problems in the Solution Explorer and "Exclude From Project"
  2. Rebuild that assembly (let's call it "A")
  3. The project that used the file ("B") will ask you to "Reload" project, wait
  4. Add the file back into assembly A, that you just removed it from, and rebuild
  5. Now, reload project B

Then the file was found in VS and all was well.

halfer
  • 19,824
  • 17
  • 99
  • 186
Ted
  • 19,727
  • 35
  • 96
  • 154
0

Changing the id of the control resolved the issue for me. Apparently the id of the control existed in another part of the solution.

Joe Gurria Celimendiz
  • 370
  • 2
  • 9
0

In my case, I was missing the following lines in my csproj file

<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
<DefineConstants>TRACE</DefineConstants>
<DebugType>full</DebugType>
<DebugSymbols>true</DebugSymbols>
</PropertyGroup>

Once I added this, I could see the variables while debugging

hooah
  • 36
  • 4
  • For my case, it was similar to this answer - I have accidentally set the Configuration. Setting it to `Debug` (from `Release`) solved my issue. – jacaheyo Aug 29 '22 at 11:03