Develop Reference

Visual Studio 2019 Project Dependency with Yellow Icon

I have two brand new C# .NET Standard libraries. They each have a project reference to an older .NET 3.5 Framework library. Only one of the two have a yellow icon on the reference.
Everything builds and runs fine but the triangle still exists, why?

I would hope they have a better way to report reference issues
than an unlabeled yellow icon.
Not sure if it's your real question. But you can check the Error List window to get details about why yellow icon displays on the References.
Everything builds and runs fine.
For some scenario, the build in VS can succeed although some build warnings occurs. And it will only fail when some build errors exist.
I add reference to ForTest.dll in my project, this assembly is missing or not compatible with current project, then it displays yellow icon in References. Now since in my project, it doesn't call functions from the ForTest.dll, so it won't exactly affect my build process. Then the project builds successfully and runs fine.
I have tried looking at the build log, in detailed mode, for an error
message, but cannot find anything obvious.
When building a solution with several projects, and set the log in Detailed mode, it's easier to get lost in the hundreds of build logs. Since the yellow icon only displays for one project, you can right-click the project=>rebuild to build the project, it makes the message in build log more clear.
Or just use the Error List window as I suggest above to check the warnings and errors instead of hundreds of logs during Trouble-shooting.
In addition: If you can't find any info in Error List window, then maybe the reason why the yellow icon occurs is because VS didn't load the project well. Please try right-click the project=> unload and reload the project in solution explorer. If it persists,close all vs instance and delete the .vs folder in solution directory, and restart vs.

According to Microsoft, these yellow warning signs get added for every new reference and then removed once the reference is successfully added (=assumed guilty until proven innocent). If some yellow warning remains in the solution explorer, VS knows only that that reference is missing, but doesn't know why and can therefore not display a warning message in the Error window.
Not being able to find out why there is a warning sign is very annoying. The problem was reported, but Microsoft's standard response is: "This problem seems not to be requested enough to be resolved, but if you like, you can contribute your own solution."
So if you read so far, can you please go to developercommunity.visualstudio.com: tell me what's wrong with the reference 2 and vote this issue up, telling MS they should indeed fix this.
After spending hours trying to solve a none existing error, I gave up and closed VS. When I started it again, the problem was gone.

These errors also occur when adding a NuGet package that is not compatible with the current .NET (such as .NET Framework app under .NET Standard or .NET Core, or a .NET version such as referencing .NET Framework 4.8 library from an older .NET version).
Check that the package dependency is the same as the project you're working with.

It could also mean that the third party assembly you have on your machine is not registered in the gac and hence not being found. For older projects mostly if I have to hand copy over the dlls, I will then register them with this powershell script in the directory they reside in:
gci *.dll | % { gacutil /i $_.Name }

Predefined type 'System.String' is not defined or imported

I have an MVC5 application which I'm trying to run offline. I installed VS2017 offline but when I try to build the project it throws multiple errors relating to it missing all the .NET assemblies and dlls. When I try to add these assemblies they're not available to be added. Anyone please help.
PS: there's NO internet on the machine.

I also have that problem from time to time. What usually helps is to do a dotnet restore. This is different to running restore from the solution explorer within VS, you have to do it through the command line. In order to execute it, you need to have the .NET Core SDK installed. dotnet restore is usually very good at fixing some project problems such as corrupted .json files that VS creates behind the scenes and I would guess that it is able to repair those files without internet connection, but I haven't tried.

Try cleaning and rebuilding your solution. I had this issue and something went funky with my dll's.

It's obvious omnisharp error same as mine. I changed omnisharp path version from c# extension(c# > unistall > install another version) and reopened to vscode. It worked for my project. All error has gone.

A dependent dll was not found

My app does not run on "Release x86" when running the app it crashes immediately after the splash screen. Output shows the following exception:
The program '[8204] dfz.exe' has exited with code -1073741515 (0xc0000135) 'A dependent DLL was not found'.
It also tells me the module is build without symbols, however in build settings I have set debug info to Full.
The first time I build the app for the Windows Store it built correctly and I also published that version to the store. When I did a manual rebuild to check if ads where inserted correctly it would not run.
However, I can run the app on ARM and X64 with no problems on release. Only x86 with .Net native toolchain will throw the missing dependant DLL.
What I have tried so far:
Created a new project, Added all my files and Nuget packages, No dice
Removed and updated all my existing references.
Tried to debug the release version so i can find out what DLL is missing from the package. However it keeps telling me there are no symbol files.
I am looking for any suggestions I can try because I am really at a loss here of why it will not run on x86.
Edit:
A blank UWP project also returns the DLL error when i run it. It looks like i have a broken development environment.
Edit2:
Just did a remote debugging session to another laptop and the app worked with no problems. So the problem is an environment related issue.

Could one of the projects in your dependencies be configured specifically for x64?
Another thing to check is that one of your projects is not set to build for that configuration (I vaguely remember some problem I had years ago that sounds kind like your situation ... although not for windows store apps ... and it turned out one of my projects wasn't set to compile for the configuration I was selecting ).

Add FreeImage .NET to solution

I have followed the posts on this, but i am still not getting a few steps. I am new to C#, and that is probably the issue. I would love a little help (I have been banging on this all day).
I can open the FreeImage.NET solution (Win7 64 bit machine btw) in Visual Studio. This post says i need to Build it to get the C# dll. When i build it, i get hundreds of errors "type or namespace 'Name' could not be found".
Does it need the C++ DDL added first? I dragged and dropped it onto the solution, but still the errors.
Am i doing something simple and wrong?
Specifically what i am trying to do is add FreeImage to project in C# Visual Studio Express 2012.
Thanks,
Dan

After downloading the version of FreeImage.NET , I opened the following VS2005 Solution File in VS2012.(Thats the only one I have)
FreeImage3154\FreeImage\Wrapper\FreeImage.NET\cs\FreeImage.NET.2005.sln
After upgrading the project and building it for the first time, I saw around 491 errors. If you open the references of the UnitTest.2005 project, you will see that the nunit.framework assembly is missing. If you have nuget installed , in VS2012 you can
Right Click references > Manage NuGet Packages > Search for NUnit and install it.
In the image below we see that the nunit.framework assembly is correctly linked.
After doing this there were only 50 errors remaining and they were all because the Xml Documentation file checks were enabled. You can disable this check as shown below in the Library.2005 project.
Build again, and it should succeed.
NOTE: The FreeImage website provides only a 32-bit version of the DLL, thus to use this DLL you will have to ensure that you set your project version to 32-bit. To obtain a 64-bit version of the FreeImage DLL you will have o download their source code project and manually do a 64-bit build as show in this blog.

Upgraded to .NET 4.0 & getting Could not load file or assembly reference to old version of DLL that was removed

System.IO.FileLoadException: Could not load file or assembly 'FOO, Version=1.0.3975.20137, Culture=neutral, PublicKeyToken=2aec35e026e7fee4' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: 'FOO, Version=1.0.3975.20137
I have a C# program that we constantly update and it gets reinstalled and it seems that since I've upgraded the project from VS2005 to VS2010 and .NET from 2.0 to 4.0 I'm getting this strange error where its trying to reference the old version of the dll from the last install.
When I go to the directory where its installed Prorgam Files(x86)/.... the latest version of the DLL is in there. In the code there are no references to the old DLL. The only way to fix this is to uninstall the program manually and reinstall. After that the program works fine.
I am lost and confused as to why it would want to keep referencing an old DLL version when its not even there. I have tried running fuslogvw.exe but it hasnt yielded any useful information. I also thought it was possibly the setup project to I deleted and recreated one from scratch. I've also done the usual clean solution & rebuilding. I've searched all thru the forums and online but most people seem to have a problem where the old version of their DLL is still in the program directory and the new DLL didnt get installed. My problem is the opposite.

I've had this error appear when the Clean action for some reason forgets to remove all the dlls in my project's bin directory, and I've had to manually delete those dlls. You might want to check that all the relevant dlls are getting removed as part of the update process. I'm guessing that's what happens when the program gets uninstalled, which is why it works then.

I would start with Who deployed the last breaking version.
It's possible that their machine incorrectly references a bad / old version, whether in the GAC or a hangover from a BIN directory. Also, you mention reinstalling "manually".. Does this mean that you have some build server or other deployment automation in place? It's possible the assembly reference is being picked up by it.
Basically, you'll need to track down exactly how the bad app is being deployed to that machine and fix it.