I checked related question in stackoverflow. It doesn't resolve my issue. I tried all that solution mention in stackoverflow. Unfortunately I can't resolve the error.
I tried these solution:(which is mentioned in SO)
Check the Target framework version are all same.In my project I used .Net framework 4.5.1.I checked that.
Reference properties->Copy Local-> True.
Clean and ReBuild the solution.
In my project floder does not contain the specified project dll file.(projectfloder/bin/Debug)and I checked (obj/Debug)
I tried these above methods even though still I getting this issue.
Metadata file:'projectfloderpath\bin\Debug\projectname.dll' could not
be found.
Means application shows that it can't able to find the dll.
Make sure your project .Net FrameWork Version same as to all project in the solution.
If your FrameWork Version 4.5.1 means, Make sure all your project having the same FrameWork Version 4.5.1 in your solution.
Hope it helps
May be you have a mistake in the configuration of app work directory so the app looks in the wrong directory?
Or you may have incompatible platform settings of DLL and main application.
Make Sure build configuration of your projects is same. Any CPU/x86/x64
Click Project > ProjectName Properties > Target Framework: Change from Client Profile to .NET Framework 4 or any version
This error is solved to me like this: In the solution explorer press "show all files", then ReBuild project by project and then ReBuild the Solution, I hope it is the solution for you!
I wish to test the core class of a plugin by directly referencing the plugin project and instantiating the plugin class. When I create a test Console App project and add a project reference to the plugin project, I get a warning icon (yellow triangle with exclamation mark) next to the reference in the References list.
When I instead add a reference to the dll, the assembly build output of the plugin, I get no such warning. What could this warning be trying to tell me?
As mentioned in the question's comments, differing .NET Framework versions between the projects can cause this. Check your new project's properties to ensure that a different default version isn't being used.
Encountered the same issue with a ASP.Net Web App and two library class projects which needed to be referenced within the Web App. I had no information provided on why the build failed and the references were invalid.
Solution was to ensure all projects had the same Target Framework:
In Visual Studio 2015- Right Click project > Properties > Application > Target Framework
Save, Clean and Rebuild solution. The project references should no longer appear as yellow warnings and the solution will compile.
My Web App was targeting .Net 4.5 whereas the other two dependent library class projects targeted .Net v4.5.2
Make sure all versions are same for each projects click each projects and see the version here Project > Properties > Application > Target .NET framework
a. Go to Tools > Nuget Package Manager > Package Manager Console Type Update-Package -Reinstall (if not working proceed to 2.b)
b. THIS IS CRITICAL BUT THE BIGGEST POSSIBILITY THAT WILL WORK. Remove < Target > Maybe with multiple lines < /Target > usually found at the bottom part of .csproj.
Save, load and build the solution.
For both of (or all of) the projects that you want to use together:
Right click on the project > Properties > Application > Target .NET framework
Make sure that both of (or all of) your projects are using the same .NET framework version.
Reinstall all packages in all projects of the current solution:
Update-Package -Reinstall
Try closing and opening VS.
Seems silly but after 1 hour of following the above and finding everything lined up OK. I restarted VS 2017 and the problems were gone.
Make sure you have the projects targeting the same framework version. Most of the times the reason would be that current project ( where you are adding reference of another project ) points to a different .net framework version than the rest ones.
For me, I ran into this issue when referencing a .NET Standard 2.0 class library in a .NET Framework 4.7.1 console application. Yes, the frameworks are different, but they are compatible (.NET Standard is supposed to jive with both .NET Core and .NET Framework.) I tried cleaning, rebuilding, removing and readding the project reference, etc... with no success. Finally, quitting Visual Studio and reopening resolved the issue.
Check NETFramework of the referred dll & the Project where you are adding the DLL.
Ex:
DLL ==> supportedRuntime version="v4.0"
Project ==> supportedRuntime version="v3.0"
You will get warning icon.
Solution : Make dll version consistence across.
It's been a long time since this question was asked but if someone is still interested - I recently ran into similar icons. I was compiling a C#.net project using VS 2008. I found VS could not locate the assemblies for those references. When I double clicked VS refreshed the references and removed the icons on some of those[EDIT: which it could NOW locate]. For remaining references, I had to compile the respective assemblies.
Adding my 2 cents to the #kad81 answer,
Go to Visual Studio -> BUILD -> Configuration Manager
In the "Active Solution Platform" drop down in top right hand corner (mine is VS 2012), if it is "Mixed Platforms", change it to the appropriate platform based upon your reference third party assemblies.
Then in each of the project in the list, make sure you select same platform for all the project. (if x86 not exist, then select "", then you can select "x86".)
Rebuild the library projects first and then referencing projects.
Hope this helps.
In Asp.net core sometime it shows alert if you changes the project name space or name. To remove this kind of alerts you just Unload Project and load it again.
If issue is still there means you it can not find your Assembly reference.
Using Visual Studio 2019 with all projects targeting .Net Core 3.1 the solution was to:
Clean / Build / Rebuild.
Restart Visual Studio 2019
Also happens if you explicitly reference a project that was already implicitly referenced.
i.e
project a references project b
project c references project a (which adds implicit ref. Expand and see)
project c references project b
you will see an exclamation mark next to b under project references.
I had these icons for a different reason. We have one big solution for all our projects (nearly 100). I made a subselection of the projects I was interested in and made a new solution. However the references where project references instead of references to the compiled dll's....
After some research I found this link on GitHub which explains this is new behaviour in VS2015.
On the GitHub page they explain a workaround for converting project references to binary references.
To fix some not working stuff it has sense to remove some libraries sometimes, how would not that sound weird.
Anyways, I believe the problem is too wide and might be caused by different factors, so want to share my situation/solution.
I had a project (brought by customer) with Xamarin Forms and Telerik libraries. The thing was in general related to the components, which libraries are not included into packages folder, nor available via Nuget (paid ones).
The whole project References were "yellow", it looked horribly and scary.
The solution was just to remove those Telerik references (including a few controls in code which were using that). Right after that all the references magically got their common normal grey color and the errors (mostly) disappeared.
"Mostly" - because "all red around" error messages about "the element is not defined anywhere" sometimes happen still. That's weird, and brings inconvenience, but I still able to compile and run the project(s): just need to clean solution, restart Visual Studio, pray a little bit, clean again, remove obj/bin folders, restart again, and it works well.
The key thing is remove not available libraries references, as the error messages say absolutely another stuff. (For instance, something like "Xamarin.Build.Download.XamarinDownloadArchives not found or cannot find something" etc., but that just might mean you don't have some references available.
Then remove packages folder, reload/reopen the project/solution, go to "Manage Nuget Packages" and click "Restore" button.
In a multi-project solution, If every other thing failed... On the startUp project, check.
Dependencies->Assemblies and see if the erring referenced project is there. Remove it and re-build.
I had the same issue in a solution with projects targting .NET Core 3.1, .NET Standard 2.0 and .NET Framework 4.8. The issue was on this last one.
The trick that solved the issue for me, was to change the target framework to .NET Framework 4.5, then back to .NET Framework 4.8.
I have absolutely no idea why this fixed the issue, but it did.
The IDE was Visual Studio 2019.
Open the YOURPROJECT.csproj file with a text editor then at the end of the file remove these lines inside the target tag, and then build the project again!
be sure the Package folder is in the correct path which mentioned in < Reference > < HintPath >
<Error Condition="!Exists('.......
Enjoy it ;)
I also faced the same problem but my case was a bit different the ones above. I tried to open a project created in a different computer. I found that the path to package folder is not updated when you add a reference so restarting VS, changing .NET version, or any mentioned recommendation does not solve the problem. I opened the csproj file in notepad++ and corrected all the relative paths to packages folder. Then; all the warnings are gone. Hope it helps.
in VS 2017 Do a Clean then Build
Thank you all for the help. Here is a breakdown of how I fixed my problem:
Right click on your project > Properties
Under Application change the target Framework. In my case ImageSharp was using .Net 4.6.1. You can find this in your packages.config.
Go to your project references. You'll notice SixLabors has a yellow triangle. You have to update the NuGet package.
Right click on References > Manage NuGet Packages.
Update SixLabors.
You might have slight code updates (see below) but this fixed my problem.
Convert ImageSharp.Image to ImageSharp.PixelFormats.Rgba32?
In Visual Studio 2019, one of my projects target framework was .net core but it was referencing another project whose target framework was .net standard. I changed all of the projects to reference .net standard and the icons went away. To see what your project is right click it and click properties and look at Target framework. You can also normal click the project itself and look at the < TargetFramework > tag under < PropertyGroup >
I had created a new .sln which was put in a subfolder. The .nuget folder was missing from where that .sln file was added. Moving the .nuget folder from the root into the subfolder where my new .sln file was solved the issue for me.
I came back later and added the .sln file to the root and deleted the subfolder. Doing this originally would have solved the issue as well.
Based on the answer from #AljohnYamaro (sorry, couldn't comment on your answer, new account without enough reputation yet, but upvotaded you), I've checked the .csproj file.
On my file, besides the standard project reference:
<ProjectReference Include="..\ProjectA\ProjectA.csproj">
<Private>true</Private>
<CopyLocalSatelliteAssemblies>true</CopyLocalSatelliteAssemblies>
</ProjectReference>
There were also a directy link to the compiled dll from the referenced project:
<ItemGroup>
<Reference Include="ProjectA">
<HintPath>..\ProjectA\bin\Debug\netcoreapp3.1\ProjectA.dll</HintPath>
</Reference>
</ItemGroup>
Removing this second reference solved the issue.
One of the reasons to get this annoying yellow triangle is that you are adding a reference to a project twice, meaning:
Reference one: MyProjectOne (which contains already a reference to MyProjectTwo)
Reference two: MyProjectTwo
By deleting the Reference two, the yellow triangle will disappear.
If you're using the newer style Sdk projects add OutputType to the ProjectGroup element with a value of Library in the project you're referencing.
It'll also give you grief if it's in the project you're referencing and it references a project without the setting.
find your .csprojc file and open it.
find your packages path. I fixed my project by this issue.
..\packages\EntityFramework.6.1.3\lib\net45\EntityFramework.dll
this .. means vs will find this dll in parent directory.
you should confirm your package path, and your will fixed this issue.
one more simple answer : exit visual studio and re-open it, it has solved for my problem.
I've got a Solution with lots of projects and all but one of them is behaving. The one that is not working is a ConsoleApplication, and it relies on C# Class Library project. I've added a reference to the library project, and add the namespace (which I've checked is correct), but everywhere I reference the classes in my library, I get:
The type or namespace 'MyClass' could not be found (are you missing a using directive or an assembly reference?).
The library project is building successfully (I can see the DLLs appear in the bin folder) and I've tried a project reference, and also a reference to the DLL itself. Neither works.
Also, all projects are set to build with a platform target of 'Any CPU'.
I've tried pretty much every suggestion I've come across on forums with no success. Can anyone shed some light on what's going wrong?
Thanks
This solved the problem:
The console application had a Target framework of .NET Framework 4 Client Profile, whereas the library just had .NET Framework 4. I set the console app to .NET Framework 4 and it all builds perfectly.
My bet is on a framework mismatch between your library and you app...
Check if your library is not building with a superior version than you app, or if your app is building with a Client profile flavor
It is probably that one of your DLLs references some part of the .net framework that is not referenced in your console application. For example if one of your class library projects has asp.net server controls in and references System.Web, but your console application does not reference System.Web it will not build and you will get that error. But it is not obvious because the DLLs referenced are stored in the GAC so they would never appear in your bin folder.
I had to simply restart visual studio for reference to work but make sure you have reference added in .csproj file.
If you still experience the issue, make sure the class you're referencing is public and that Asp.net core Framework version match.
Sounds weird,
Have you tried to remove the reference of the project and add it again? Check if your console app has got all the right references.
You could also inspect the .csproj file and see if everything is correct in there.
Just Check that you "Class Library" project has classes in it or if it is a data access layer project which include only a .edmx Model check the Model designer is found and it generates fine.
Good Luck
I worked with syncing the framework, but still, it was giving issue.
So I tried another way.
Right-click on the dependency, and select Add project reference. I added the required project then the error was gone.
I'm writing an application in .Net 3.5.
I have 3 projects in the solution so far. When adding the references to the other projects from my main project, the intellisense manages to find the classes from the other project's dlls but at compile time it seems to be "loosing" the reference.
This might be because I initially created the project with target framework .Net 4.0. However since I needed to use the ASP.NET web services I had to downgrade to 3.5.
Any help will be greatly appreciated.
The referrenced projects must be Copy Local : True
Referrence -> Properites ->Copy Local : True
Batch clean all projects in your solution, make sure all the projects in your dependency graph target the .NET 3.5 framework. Check the reference's HintPath in your .csproj file (open with text editor) for references to external DLLs and make sure they're all <=3.5.
However since I needed to use the ASP.NET web services I had to downgrade to 3.5.
There are also several different web service projects in .NET 4. I don't quite understand this move.
You have project references, intellisense sees your referenced classes but when compiling, the compiler seems not to find the referenced assemblies.
I see two possible reasons for this behaviour:
Your main project references a lower version of the .NET framework than your library projects (this is the most likely cause).
Your library projects won't get built at all / or in the wrong order (check the settings in the configuration manager. Open it with a right click on your solution in the solition explorer).
I have 2 projects in a solution, 1 a dll, the other an exe. Both were using .net version 4.0 however no 4.0 specific libraries were used so it should be possible for me to safely change them to 3.5
I did this under both project properties, I built the dll fine. Now when i try to build the exe it cannot find the dll's namespace. I have readded the reference, but it still cant see it. When I reverted the .net version it did say I might have to modify the project files before it builds. I have tried to search for a solution via google but the key words I am using are too commonly used. Can anyone advise?
Many thanks, Chris
Edit:
Tried the following already..
Reference DLL specifically whilst ensuring not 4.0 copy
Delete bin and obj folders
Restart VS
Rather than referencing the output DLL, have you tried setting it as a project reference instead.
Also, have you done a clean build of the solution incase any .Net 4.0 files were lingering? You can manually clean the project by deleting the bin and obj folders.
Have you tried removing the projects from the solution, creating a new .net 3.5 project and compiling that. Then add in the ddl project (Add -> existing project) and compile, then add in exe project without reference, compile then add in the references.
Odd question, but have you check the name spaces still. Can you call in your project the namesapce, i.e. using mydllproject.model.myengine
I would open your project files as XML. To do this, close the soltion and reopen the projects only by clicking the down arrow on the File/Open button and selecting Open With... XML (Text) Editor. Check to make sure each project has a ToolsVersion="4.0" in the header. Check the RootNamespace and TargetFrameworksVersion elements to see if they have the values that you expect. At the bottom of the file, check the ProjectReference element within the ItemGroup. Make sure the GUID in the project reference matches the GUID that is defined in your solution file.
Finally, make sure you clean your project before you rebuild it. If you're using source control, check out the project into a new, empty sandbox.
Good Luck!
-Put dll and exe in 3.5
-Compile the dll only
-Delete the reference to the dll and readd it
-Rebuild the solution
Check the DLLs that you are referencing what kind of target runtime they require, especially the "Engine.dll". You could do this with the .NET Refractor for example. If they are compiled for v4.0, then yuou need to get versions for an earlier version of .NET runtime.
I had a very similar problem to this. In my case it I had two projects, a 'class library' and a windows forms application in the same solution.
After changing the target framework of both the projects to .NET4.0 framework, and adding a reference to the class library in my windows forms application, it wouldn't detect the namespace of my class library.
Here is what I did that finally solved the problem:
Created a new project with .NET 4.0 framework as the target framework. I imported all my forms and classes into this project from the original solution.
Added the existing class library as a new project.
Added a reference to the class library project from my windows forms project
For each of the class files under the class library project, I set the 'Build Action' to 'Compile'
Right-clicked the class library project and selected to 'Rebuild'.
Then when I go into my windows forms projects, I can see the namespace when I use the
'using namespace_name' statement.
Note: Maybe you do not need to create a new project like I did in the first few steps. But changing the Build Action definitely did the trick.
Hope it helps.