Related
I'm getting a:
type or namespace name could not be found
error for a C# WPF app in VS2010. This area of code was compiling fine, but suddenly I'm getting this error. I've tried removing the Project Reference and the using statement, shutting VS2010 and restarting, but still I have this issue.
Any ideas why this might be occurring, where it seems like I'm doing the right thing re Reference & using statement?
I also noted in VS2010 that intellisense for that namespace is working ok, so it seems like VS2010 has the project reference and is seeing the namespace on one hand, but during compile doesn't see it?
This can be the result of a .Net framework version incompatibility between two projects.
It can happen in two ways:
a client profile project referencing a full framework project; or
an older framework version targeting a newer framework version
For example it will happen when an application is set to target the .Net 4 Client Profile framework, and the project it references targets the full .Net 4 framework.
So to make that clearer:
Project A targets the Client Profile framework
Project A references Project B
Project B targets the full framework
The solution in this case is to either upgrade the framework target of the application (Project A), or downgrade the target of referenced assembly (Project B). It is okay for a full framework app to reference/consume a client profile framework assembly, but not the other way round (client profile cannot reference full framework targeted assembly).
Note that you can also get this error when you create a new project in VS2012 or VS2013 (which uses .Net 4.5 as the default framework) and:
the referencing project(s) use .Net 4.0 (this is common when you have migrated from VS2010 to VS2012 or VS2013 and you then add a new project)
the referenced projects use a greater version i.e. 4.5.1 or 4.5.3 (you've re-targeted your existing projects to the latest version, but VS still creates new projects targeting v4.5, and you then reference those older projects from the new project)
Reinstalling nuget packages did the trick for me. After I changed .NET Framework versions to be in sync for all projects, some of the nuget packages (especially Entity Framework) were still installed for previous versions. This command in Packages Manager Console reinstalls packages for the whole solution:
Update-Package –reinstall
I've no idea why this worked, but I removed the project reference that VS2015 was telling me it couldn't find, and added it again. Solved the problem. I'd tried both cleaning, building and restarting VS to no avail.
When building the solution I was getting the same error (type or namespace ' ' could not be found). Below it I saw a warning stating that "the reference could not be resolved" and to make sure "the assembly exists on disk".
I was very confused, because my DLL was very clearly in the location that the reference was pointing to. VS didn't seem to highlight any errors, until I tried to build the solution.
I finally realized the problem (or at least what I suspect was the problem). I was building the library file in the same solution. So even though it existed on the disk, it was being rebuilt in that location (somehow in the process of the library getting rebuilt my other project - in the same solution - that referenced the library must have decided that the library didn't exist)
When I right-clicked on the project and built that only, instead of the entire solution, I didn't get the error.
To fix this problem I added the library as a dependency to the project that was using it.
To do this:
I right-clicked on my Solution in the Solution Explorer and selected
"Properties"
Then in "Common Properties" I selected "Project Dependencies".
Then in the Projects drop-down menu I selected the project that
relied on the library, and
Checked the box next to the library found under "Depends On"
This ensures that the library project gets built first.
First I would verify that your project's generated information isn't corrupt. Do a clean and rebuild on your solution.
If that doesn't help, one thing I've seen work in the past for designer issues is opening up a windows forms project, then closing it again. This is a little chicken-entrails-ish, though, so don't hold your breath.
A trickier situation I ran into was:
Project one targets the 4.0 full framework with Microsoft.Bcl.Async package installed.
Project two target the 4.0 full framework but would not compile when reference a Project one class.
Once I installed the Async NuGet package on the second project it compiled fine.
In my case, I find the reference in the VisualStudio have a triangle, and a exclamation mark as this image,
then, I right click remove it, and add the dll reference correctly again, the problem was solved.
I had a similar issue: The compiler was unable to detect a folder inside the same project, so a using directive linking to that folder generated an error. In my case, the problem originated from renaming the folder. Even though I updated the namespace of all the classes inside that folder, the project info somehow failed to update. I tried everything: deleting the .suo file and the bin and obj folders, cleaning the solution, reloading the project - nothing helped. I resolved the problem by deleting the folder and the classes inside, creating a new folder and creating new classes in that new folder (simply moving the classes inside the new folder didn't help).
PS: In my case I was working on a web application, but this problem may occur in different types of projects.
This one worked for me. In your class, where the class name is defined, eg: Public class ABC, remove one character and wait a little. You error list will increase because you have changed the name. Now put back the character that you have typed. This worked for me, hopefully it will work for you too. Good Luck!!!
[Facepalm] My issue was that I had added the dependency in the C++ way of doing things.
Go to the project that won't build, open up the 'References' folder in Solution Explorer, and see if your dependency is listed.
If not, you can 'Add Reference' and choose the dependency on the Projects tab.
Boom Shankar.
Check the Build Action of the .cs file containing the missing type. Make sure it's C# compiler.
Click on the .cs file containing the missing type.
Press F4 to bring up Properties.
Make sure Build Action is set to C# compiler.
Before:
After:
It even happens in Visual Studio 2017.
Restart Visual Studio
Clean project that fails to build.
Rebuild the project.
Had the same errors, my story was following:
after bad merging (via git) one of my .csproj files had duplicated compile entries like:
<Compile Include="Clients\Tree.cs" />
<Compile Include="Clients\Car.cs" />
<Compile Include="Clients\Tree.cs" /> //it's a duplicate
If you have a big solution and more than 300 messages in the errors window it's hard to detect this issue.
So I've opened damaged .csproj file via notepad and removed duplicated entries. Worked in my case.
I had same problem as discussed: VS 2017 underlines a class in referenced project as error but the solution builds ok and even intellisense works.
Here is how I managed to solve this issu:
Unload the referenced project
Open .proj file in VS ( i was looking for duplicates as someone suggested here)
Reload project again (I did not change or even save the proj file as I did not have any duplicates)
We had a weird case of this that I just fixed in a solution. There was a hidden/whitespace character in front of a "using" statement in the main project. That project would build fine and the website worked fine, but the unit test project that referenced it could not be built.
I encountered this problem when upgrading existing projects from VS2008 to VS2012. I found that two projects (the only two that I created) were targeting different .Net Frameworks (3.5 and 4.0). I resolved this on the Application tab of the projects by making sure that both projects had ".NET Framework 4" in the Target Framework box.
In my case I had a Class that was listed in the proper source folder, but was not registering in Solution Explorer. I had to do right click the project > Add Existing item and manually select that Class it said it was missing. Then everything worked fine!
I know its old, but I've found the same issue. My project did build, I then updated Visual Studio to the latest & the project wouldnt build as it couldnt find a type definition from a separate assembly. The other assembly built OK, the main project referenced it correctly & nothing had changed since it built OK.
I cleaned the whole solution & rebuilt it, it failed. I built the assembly on its own, it built OK. The project didnt build. I cleaned & built multiple times, and it failed. I then called a colleague to look at it, when I built with him watching, it all built OK.
I think Visual Studio tooling is the problem, especially as I just updated it.
In my case, I unload the project, then:
Opened myProject.csproj and update the ToolsVersion="4.0" to ToolsVersion="12.0"(I'm using vs 2017)(using Paulus's answer https://stackoverflow.com/a/64552201/1594487).
Deleted following lines from the myProject.csproj:
<Import Project="..\packages\EntityFramework.6.4.0\build\EntityFramework.props" Condition="Exists('..\packages\EntityFramework.6.4.0\build\EntityFramework.props')" />
<Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
And the problem solved.
You might also try eliminating the code you think you're having problems with and seeing if it compiles with no references to that code. If not, fix things until it compiles again, and then work your suspected problem code back in. Sometimes I get strange errors about classes or methods that I know are correct when the compiler doesn't like something else. Once I fix the thing that it's really getting hung up on, these 'phantom' errors disappear.
I know this is kicking a dead horse but I had this error and the frameworks where fine. My problem was basically stating that an interface could not be found, yet it build and accessed just fine. So I got to thinking: "Why just this interface when others are working fine?"
It ended up that I was actually accessing a service using WCF with an endpoint's interface that was using Entity Version 6 and the rest of the projects were using version 5. Instead of using NuGet I simply copied the nuget packages to a local repository for reuse and listed them differently.
e.g. EntityFramework6.dll versus EntityFramework.dll.
I then added the references to the client project and poof, my error went away. I realize this is an edge case as most people will not mix versions of Entity Framework.
Adding my solution to the mix because it was a bit different and took me a while to figure out.
In my case I added a new class to one project but because my version control bindings weren't set I needed to make the file writable outside of Visual Studio (via the VC). I had cancelled out of the save in Visual Studio but after I made the file writable outside VS I then hit Save All again in VS. This inadvertently caused the new class file to not be saved in the project..however..Intellisense still showed it up as blue and valid in the referencing projects even though when I'd try to recompile the file wasn't found and got the type not found error. Closing and opening Visual Studio still showed the issue (but if I had taken note the class file was missing upon reopening).
Once I realized this, the fix was simple: with the project file set to writeable, readd the missing file to the project. All builds fine now.
I had the same issue. One night my project would compile the next morning ERRORS!.
I eventually found out that visual studio decided to "tweak" some of my references and point them elsewhere. for example:
System.ComponentModel.ISupportInitialize somehow became "blahblah.System.ComponentModel.ISupportInitialize"
Quite a rude thing for vs to do if you as me
My case was same as discussed here but nothing solved it until I've removed the System.Core reference from the references list (Everything worked fine without it)
hope it will help someone because this issue is quite frustrating
To solve this issue it can also help to delete and recreate the *.sln.DotSettings file of the associated solution.
Ok, years later using VS 2017 .NET Core 2.2 Razor Pages I feel this answer might help someone.
If it was a snake it would have bit me.
I was throwing stuff around, changing names, renaming Models, and all of a sudden I got this error:
Error CS0246 The type or namespace name 'UploadFileModel' could not be
found (are you missing a using directive or an assembly reference?)
This was underlined in red in my .chstml Razor Page. (not underlined after fix):
#page
#model UploadFileModel
So, finally, and luckily, I found the code from someone else that I had originally used, and low and behold, the namespace did not include the .cshtml file name!!!
Here is my bad dummy error spank myself with the page name in the namespace:
namespace OESAC.Pages.UploadFile
{
public class UploadFileModel : PageModel
{
What my original code had and all I had to do was delete the page name from the namespace, UploadFile:
namespace OESAC.Pages
{
public class UploadFileModel : PageModel
{
And low and behold, all the errors disappeared!!
Silly me. But you know, MS has made this .NET C# MVC stuff really confusing for us non-computer scientists. I am constantly tripping on my shoelaces trying to figure out model names, page names, and syntax to use them. It shouldn't be this hard. Oh well. I hope error and solution helps someone. The error was right, there is no Namespace named "UploadFileModel" haha.
In my case the problem was that after changing namespace to exactly same as is in another project (intentionally), the name of assembly was changed as well by VS, so there were two assemblies with same name, one overriding the other
Had the same problem after merging some new code into a vs2019 project.
Restarted VS, unloaded and reloaded projects, ensured all projects in solution had same ToolsVersion= and TargetFrameworkVersion. None of this helped.
I had a case of project Substrate, failing to find namespace Skin (in project Skin).
Finally I opened up Substrate.csproj and checked all the ProjectReference Include entries. The others were there, but no reference to Skin, even though Skin did show up in the check box of the little project dependencies dialog. So the project dependencies dialog took the check box for Skin (and saved it somewhere) but did not alter Substrate.csproj. I then added the ProjectReference Include manually, ensuring I had the correct path and GUID for the skin project.
<ProjectReference Include="..\Skin\Skin.csproj">
<Project>{1ad4b5d7-5014-4f5f-983e-2c59ac0e0028}</Project>
<Name>Skin</Name>
</ProjectReference>
I then saved the Substrate.csproj and the problem was solved. So as others have said this is a problem with VS tooling
In my case I had a file built by external dependency (xsd2code) and somehow its designer.cs files were not processed by VS correctly. Creating a new file in Visual Studio and pasting the code in it did the trick for me.
To anyone that is getting this error when they try to publish their website to Azure, none of the promising-looking solutions above helped me. I was in the same boat - my solution built fine on its own. I ended up having to
Remove all nuget packages in my solution.
Close and reopen my solution.
Re-add all the nuget packages.
A little painful but was the only way I could get my website to publish to Azure.
I am trying to work with GeoCoordinate which is meant to be supported by .Net Framework 4.5. I am working on winodws 8 and I have .Net Framework 4.5, but I keep getting The type or namespace name 'Device' does not exist in the namespace 'System' error.
Any solution?
The type or namespace name 'XXX' could not be found...
Always bear in mind, if you get this error there are three possibilities.
You missed the using directive.
You missed the Assembly reference
You have "using directive" as well as "Assembly reference" in place but the current project's target framework version is lower than the referenced assembly target framework version.
Almost all the cases above three steps should solve the problem.
Hope this helps.
Does not have added reference of System.Device dll in your project.
Steps to Add Reference.
1. Right click on the Reference folder on your project.
2. Select Add Reference.
3. Expand Assemblies option.
4. Search System.Device in the serach box at right corner side.
5. After searching, click on checkbox to select and click on ok.
If you are using VS.NET:
Right click on the References folder on your project.
Select Add Reference.
Select the .NET tab (or select the Browse button if it is not a .NET Framework assembly).
Double-click the assembly containing the namespace in the error message.
Press the OK button.
If you are using the command line, use the /r: or /reference: option. For Example:
csc.exe /reference:System.Drawing.dll MyFontDisplayApp.cs
When you recompile, this error will no longer appear.
It is also possible that your project uses x64 libraries and your machine has limited x64 libraries. I think this happened in my case.
Possible Solution: I copied library from x86 folder to bin folder of my project. Then added the new reference(discard the old reference to same library). AND IT WORKED.
Note: Please correct me if I am wrong here.
I am trying to make a Cassini-like server for a particular asp.net web application. The Client is not happy with the Cassini interface, so I am just expanding the Cassini code, adding new features, and providing a fresh look to the UI.
Now the problem I am facing is, all the files from Cassini source use the System.Web.Hosting namespace. Visual Studio throws me an error saying:
The type or namespace name 'Hosting' does not exist in the namespace 'System.Web' (are you missing an assembly reference?)
What am I missing here? I have already written
using System.Web.Hosting;
in the first line of the .cs file. I am using .Net FW 3.5 and VS2008.
Any help would be seriously appreciated.
Thanks.
Most likely, your project is targeting the "Client Profile" version of the .NET Framework, which doesn't include the System.Web.Hosting namespace.
You need to change your project to target the full version of the framework, and then add a reference to System.Web. To do this, follow these steps:
Open your project Properties by double-clicking on "Properties" in the Solution Explorer.
From the drop-down box labeled "Target framework," choose ".NET Framework 3.5". Visual Studio will inform you that this requires closing and re-opening your project, so make sure that it is saved first before clicking "Yes".
When your project re-opens, right click on "References" in the Solution Explorer, and select "Add Reference" from the context menu.
Find the item named "System.Web" under the ".NET" tab in the resulting dialog box, and click OK.
You have to add the System.Web reference to the project.
I'm getting a:
type or namespace name could not be found
error for a C# WPF app in VS2010. This area of code was compiling fine, but suddenly I'm getting this error. I've tried removing the Project Reference and the using statement, shutting VS2010 and restarting, but still I have this issue.
Any ideas why this might be occurring, where it seems like I'm doing the right thing re Reference & using statement?
I also noted in VS2010 that intellisense for that namespace is working ok, so it seems like VS2010 has the project reference and is seeing the namespace on one hand, but during compile doesn't see it?
This can be the result of a .Net framework version incompatibility between two projects.
It can happen in two ways:
a client profile project referencing a full framework project; or
an older framework version targeting a newer framework version
For example it will happen when an application is set to target the .Net 4 Client Profile framework, and the project it references targets the full .Net 4 framework.
So to make that clearer:
Project A targets the Client Profile framework
Project A references Project B
Project B targets the full framework
The solution in this case is to either upgrade the framework target of the application (Project A), or downgrade the target of referenced assembly (Project B). It is okay for a full framework app to reference/consume a client profile framework assembly, but not the other way round (client profile cannot reference full framework targeted assembly).
Note that you can also get this error when you create a new project in VS2012 or VS2013 (which uses .Net 4.5 as the default framework) and:
the referencing project(s) use .Net 4.0 (this is common when you have migrated from VS2010 to VS2012 or VS2013 and you then add a new project)
the referenced projects use a greater version i.e. 4.5.1 or 4.5.3 (you've re-targeted your existing projects to the latest version, but VS still creates new projects targeting v4.5, and you then reference those older projects from the new project)
Reinstalling nuget packages did the trick for me. After I changed .NET Framework versions to be in sync for all projects, some of the nuget packages (especially Entity Framework) were still installed for previous versions. This command in Packages Manager Console reinstalls packages for the whole solution:
Update-Package –reinstall
I've no idea why this worked, but I removed the project reference that VS2015 was telling me it couldn't find, and added it again. Solved the problem. I'd tried both cleaning, building and restarting VS to no avail.
When building the solution I was getting the same error (type or namespace ' ' could not be found). Below it I saw a warning stating that "the reference could not be resolved" and to make sure "the assembly exists on disk".
I was very confused, because my DLL was very clearly in the location that the reference was pointing to. VS didn't seem to highlight any errors, until I tried to build the solution.
I finally realized the problem (or at least what I suspect was the problem). I was building the library file in the same solution. So even though it existed on the disk, it was being rebuilt in that location (somehow in the process of the library getting rebuilt my other project - in the same solution - that referenced the library must have decided that the library didn't exist)
When I right-clicked on the project and built that only, instead of the entire solution, I didn't get the error.
To fix this problem I added the library as a dependency to the project that was using it.
To do this:
I right-clicked on my Solution in the Solution Explorer and selected
"Properties"
Then in "Common Properties" I selected "Project Dependencies".
Then in the Projects drop-down menu I selected the project that
relied on the library, and
Checked the box next to the library found under "Depends On"
This ensures that the library project gets built first.
First I would verify that your project's generated information isn't corrupt. Do a clean and rebuild on your solution.
If that doesn't help, one thing I've seen work in the past for designer issues is opening up a windows forms project, then closing it again. This is a little chicken-entrails-ish, though, so don't hold your breath.
A trickier situation I ran into was:
Project one targets the 4.0 full framework with Microsoft.Bcl.Async package installed.
Project two target the 4.0 full framework but would not compile when reference a Project one class.
Once I installed the Async NuGet package on the second project it compiled fine.
In my case, I find the reference in the VisualStudio have a triangle, and a exclamation mark as this image,
then, I right click remove it, and add the dll reference correctly again, the problem was solved.
I had a similar issue: The compiler was unable to detect a folder inside the same project, so a using directive linking to that folder generated an error. In my case, the problem originated from renaming the folder. Even though I updated the namespace of all the classes inside that folder, the project info somehow failed to update. I tried everything: deleting the .suo file and the bin and obj folders, cleaning the solution, reloading the project - nothing helped. I resolved the problem by deleting the folder and the classes inside, creating a new folder and creating new classes in that new folder (simply moving the classes inside the new folder didn't help).
PS: In my case I was working on a web application, but this problem may occur in different types of projects.
This one worked for me. In your class, where the class name is defined, eg: Public class ABC, remove one character and wait a little. You error list will increase because you have changed the name. Now put back the character that you have typed. This worked for me, hopefully it will work for you too. Good Luck!!!
[Facepalm] My issue was that I had added the dependency in the C++ way of doing things.
Go to the project that won't build, open up the 'References' folder in Solution Explorer, and see if your dependency is listed.
If not, you can 'Add Reference' and choose the dependency on the Projects tab.
Boom Shankar.
Check the Build Action of the .cs file containing the missing type. Make sure it's C# compiler.
Click on the .cs file containing the missing type.
Press F4 to bring up Properties.
Make sure Build Action is set to C# compiler.
Before:
After:
It even happens in Visual Studio 2017.
Restart Visual Studio
Clean project that fails to build.
Rebuild the project.
Had the same errors, my story was following:
after bad merging (via git) one of my .csproj files had duplicated compile entries like:
<Compile Include="Clients\Tree.cs" />
<Compile Include="Clients\Car.cs" />
<Compile Include="Clients\Tree.cs" /> //it's a duplicate
If you have a big solution and more than 300 messages in the errors window it's hard to detect this issue.
So I've opened damaged .csproj file via notepad and removed duplicated entries. Worked in my case.
I had same problem as discussed: VS 2017 underlines a class in referenced project as error but the solution builds ok and even intellisense works.
Here is how I managed to solve this issu:
Unload the referenced project
Open .proj file in VS ( i was looking for duplicates as someone suggested here)
Reload project again (I did not change or even save the proj file as I did not have any duplicates)
We had a weird case of this that I just fixed in a solution. There was a hidden/whitespace character in front of a "using" statement in the main project. That project would build fine and the website worked fine, but the unit test project that referenced it could not be built.
I encountered this problem when upgrading existing projects from VS2008 to VS2012. I found that two projects (the only two that I created) were targeting different .Net Frameworks (3.5 and 4.0). I resolved this on the Application tab of the projects by making sure that both projects had ".NET Framework 4" in the Target Framework box.
In my case I had a Class that was listed in the proper source folder, but was not registering in Solution Explorer. I had to do right click the project > Add Existing item and manually select that Class it said it was missing. Then everything worked fine!
I know its old, but I've found the same issue. My project did build, I then updated Visual Studio to the latest & the project wouldnt build as it couldnt find a type definition from a separate assembly. The other assembly built OK, the main project referenced it correctly & nothing had changed since it built OK.
I cleaned the whole solution & rebuilt it, it failed. I built the assembly on its own, it built OK. The project didnt build. I cleaned & built multiple times, and it failed. I then called a colleague to look at it, when I built with him watching, it all built OK.
I think Visual Studio tooling is the problem, especially as I just updated it.
In my case, I unload the project, then:
Opened myProject.csproj and update the ToolsVersion="4.0" to ToolsVersion="12.0"(I'm using vs 2017)(using Paulus's answer https://stackoverflow.com/a/64552201/1594487).
Deleted following lines from the myProject.csproj:
<Import Project="..\packages\EntityFramework.6.4.0\build\EntityFramework.props" Condition="Exists('..\packages\EntityFramework.6.4.0\build\EntityFramework.props')" />
<Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
And the problem solved.
You might also try eliminating the code you think you're having problems with and seeing if it compiles with no references to that code. If not, fix things until it compiles again, and then work your suspected problem code back in. Sometimes I get strange errors about classes or methods that I know are correct when the compiler doesn't like something else. Once I fix the thing that it's really getting hung up on, these 'phantom' errors disappear.
I know this is kicking a dead horse but I had this error and the frameworks where fine. My problem was basically stating that an interface could not be found, yet it build and accessed just fine. So I got to thinking: "Why just this interface when others are working fine?"
It ended up that I was actually accessing a service using WCF with an endpoint's interface that was using Entity Version 6 and the rest of the projects were using version 5. Instead of using NuGet I simply copied the nuget packages to a local repository for reuse and listed them differently.
e.g. EntityFramework6.dll versus EntityFramework.dll.
I then added the references to the client project and poof, my error went away. I realize this is an edge case as most people will not mix versions of Entity Framework.
Adding my solution to the mix because it was a bit different and took me a while to figure out.
In my case I added a new class to one project but because my version control bindings weren't set I needed to make the file writable outside of Visual Studio (via the VC). I had cancelled out of the save in Visual Studio but after I made the file writable outside VS I then hit Save All again in VS. This inadvertently caused the new class file to not be saved in the project..however..Intellisense still showed it up as blue and valid in the referencing projects even though when I'd try to recompile the file wasn't found and got the type not found error. Closing and opening Visual Studio still showed the issue (but if I had taken note the class file was missing upon reopening).
Once I realized this, the fix was simple: with the project file set to writeable, readd the missing file to the project. All builds fine now.
I had the same issue. One night my project would compile the next morning ERRORS!.
I eventually found out that visual studio decided to "tweak" some of my references and point them elsewhere. for example:
System.ComponentModel.ISupportInitialize somehow became "blahblah.System.ComponentModel.ISupportInitialize"
Quite a rude thing for vs to do if you as me
My case was same as discussed here but nothing solved it until I've removed the System.Core reference from the references list (Everything worked fine without it)
hope it will help someone because this issue is quite frustrating
To solve this issue it can also help to delete and recreate the *.sln.DotSettings file of the associated solution.
Ok, years later using VS 2017 .NET Core 2.2 Razor Pages I feel this answer might help someone.
If it was a snake it would have bit me.
I was throwing stuff around, changing names, renaming Models, and all of a sudden I got this error:
Error CS0246 The type or namespace name 'UploadFileModel' could not be
found (are you missing a using directive or an assembly reference?)
This was underlined in red in my .chstml Razor Page. (not underlined after fix):
#page
#model UploadFileModel
So, finally, and luckily, I found the code from someone else that I had originally used, and low and behold, the namespace did not include the .cshtml file name!!!
Here is my bad dummy error spank myself with the page name in the namespace:
namespace OESAC.Pages.UploadFile
{
public class UploadFileModel : PageModel
{
What my original code had and all I had to do was delete the page name from the namespace, UploadFile:
namespace OESAC.Pages
{
public class UploadFileModel : PageModel
{
And low and behold, all the errors disappeared!!
Silly me. But you know, MS has made this .NET C# MVC stuff really confusing for us non-computer scientists. I am constantly tripping on my shoelaces trying to figure out model names, page names, and syntax to use them. It shouldn't be this hard. Oh well. I hope error and solution helps someone. The error was right, there is no Namespace named "UploadFileModel" haha.
In my case the problem was that after changing namespace to exactly same as is in another project (intentionally), the name of assembly was changed as well by VS, so there were two assemblies with same name, one overriding the other
Had the same problem after merging some new code into a vs2019 project.
Restarted VS, unloaded and reloaded projects, ensured all projects in solution had same ToolsVersion= and TargetFrameworkVersion. None of this helped.
I had a case of project Substrate, failing to find namespace Skin (in project Skin).
Finally I opened up Substrate.csproj and checked all the ProjectReference Include entries. The others were there, but no reference to Skin, even though Skin did show up in the check box of the little project dependencies dialog. So the project dependencies dialog took the check box for Skin (and saved it somewhere) but did not alter Substrate.csproj. I then added the ProjectReference Include manually, ensuring I had the correct path and GUID for the skin project.
<ProjectReference Include="..\Skin\Skin.csproj">
<Project>{1ad4b5d7-5014-4f5f-983e-2c59ac0e0028}</Project>
<Name>Skin</Name>
</ProjectReference>
I then saved the Substrate.csproj and the problem was solved. So as others have said this is a problem with VS tooling
In my case I had a file built by external dependency (xsd2code) and somehow its designer.cs files were not processed by VS correctly. Creating a new file in Visual Studio and pasting the code in it did the trick for me.
To anyone that is getting this error when they try to publish their website to Azure, none of the promising-looking solutions above helped me. I was in the same boat - my solution built fine on its own. I ended up having to
Remove all nuget packages in my solution.
Close and reopen my solution.
Re-add all the nuget packages.
A little painful but was the only way I could get my website to publish to Azure.
I'm working on a C# 4.0 project in VS2010 and needed to use some older DLLs containing controls that were created in C# 3.5 on VS2008. When I first add the DLLs to the references, I was able to see the namespace via intellisense and create an instance of one of the controls, but when I go to build, it gives me the following error:
The type or namespace name 'BCA' could not be found (are you missing a using directive or an assembly reference?)
And I do have a using directive for that namespace already, which is now underlined in red, showing that VS cannot find it. And now, intellisense won't pick up that namespace at all.
I even tried added the controls to the toolbox (which worked) but then when I drag them to the GUI, it says that it cannot locate the DLL reference, even though it obviously knows where it is.
I even tried changing the target framework to 3.5, but still with the same results.
Any thoughts as to why this could be happening?
Edit - I've notice that in the csc.exe arguments that VS outputs, it does not have any /reference entries for the DLLs I'm trying to use. When I create the same basic project in VS2008, those entries exist. Also, I can successfully reference the DLLs in a DLL project in VS2010... it seems to just be WinForms projects that don't work.
Turns out that it was something to do with VS2010 defaulting to the .NET 4 client profile, as soon as I changed it to the regular profile it built fine. There's a day wasted...
view the target framework.. in my project, was 4.0 client profile, e the reference dll was in 4.0
I tried Build->Clean Solution and then could add the reference.
I used to have similar problem, but the profiles were not the issue, so the problem was that my class library use a special NuGet package that has Dependency... so I install the dependency package in the target project and added the project reference and works!
But I am not sure if there is a better solution for this problem??? for me VS should be smart enough to carry those dlls along with the references. (I already verified that "Copy Local" is set to True)