Develop Reference

Microsoft libraries missing when compiling .NET5 project

I'm trying to decompile ASP.NET Core WebApi project and gather all methods from all controllers. When my project targeted .NETCore3.1 it worked by running this code:
Assembly assembly = Assembly.LoadFrom(assemblyPath); // assemblyPath pointed to .dll
var types = assembly.GetExportedTypes();
But after updating to .NET5, the second line (assembly.GetExportedTypes()) from above throws an exception that file Microsoft.AspNetCore.Mvc.Core.dll is missing. When I copied that file manually from an old project (compiled as .NETCore3.1), it worked!
On the top of that, when project is more complicated, has EFCore dependency and more... more files are missing when compiling the project under .NET5. These are:
Microsoft.Extensions.Hosting.Abstractions.dll
Microsoft.AspNetCore.Mvc.Abstractions.dll
Microsoft.AspNetCore.Authentication.Abstractions.dll
I have two questions:
Why these files are not copied to the output folder?
How can I properly read all endpoints/methods in Controllers having complied binaries of the ASP.NET WebApi? Am I doing something wrong?
Steps to reproduce:
Create ASP.NET Core WebApi project targeting .NET5.
Create other project that targets .NET5 and implement these two lines:
var assemblyPath = "C:\\Projects\\Other\\DotNet5Test\\DotNet5Test\\DotNet5Test.WebApi\\bin\\Debug\\net5.0\\DotNet5Test.WebApi.dll";
Assembly assembly = Assembly.LoadFrom(assemblyPath);
var types = assembly.GetExportedTypes();
Run it
EDIT:
I tried adding Microsoft.AspNetCore.Mvc.Core from nuget, but Microsoft.AspNetCore.Mvc.Core.dll is not being added to the output folder

I've had similar issues sporadically with various projects in the past. The most reliable solution for me has been to install any problematic libraries through the nuget packet manager. Remove any dependency files you manually added before doing this.

I think the issue is that Microsoft.AspNetCore.Mvc.Core.dll ships as part of the framework-dependent deployment (FDD) rather than self-contained deployment (SCD) see the accepted answer Is there any GAC equivalent for .NET Core?.
Given I saw this question of yours posted earlier, How to retrieve Controller methods from WebApi binaries? I have a feeling you are trying to execute the code from a wpf application targeting .net 5 but the app is not able to use FDD to resolve the assembly.
The answer may be that you need to change your webapi app to use an SCD deployment model, but not having used SCD for web apps perhaps google will help.

Install-Package : Failed to add reference to 'System.Runtime'

I'm trying to install the Autofac nuget package in my project using the command
Install-Package -Prerelease Autofac
but it fails with the error
Install-Package : Failed to add reference to 'System.Runtime'. Please make sure that it is in the Global Assembly Cache.
I've tried re-installing .NET Framework 4.5.2 (which is the version my project targets) but got the message ".NET Framework 4.5.2 is already installed". However, searching C:\Windows\assembly\ for System.Runtime.dll doesn't find any exact matches (although there are a few instances of System.Runtime.ni.dll, which (seem to indicate) that they are really the same assembly...).
What can I do about this?
Update: apparently I was confused about the location of the GAC. Amy enlightened me, and searching in C:\Windows\Microsoft.NET\assembly instead I do find System.Runtime.dll. Why doesn't Visual Studio?

I had the same problem.
Found the solution here: https://github.com/aspnet/WebHooks/issues/18
To fix it, I added <Reference Include="System.Runtime"/> to the .csproj
file for the project, rebuilt it and it worked.

Please make sure that it is in the Global Assembly Cache.
That is an excessively unhelpful error message. It not only doesn't describe the real problem, it also leads you drastically astray to find a workaround. An assembly reference for a .NET Framework assembly must never come from the GAC. The kind of failure modes when it does can be exceedingly nasty to diagnose. Reference assemblies must come from the C:\Program Files (x86)\Reference Assemblies directory.
Looking at the .nuspec file for the Autofac nuget package you are trying to install, it supports two distinct targets. One is for DNXCore version 4.0.10-beta-22816. Hopefully you are not using it, that project is changing rapidly.
The other is .NET Portable, profile 259. Which allows your project to target .NET 4.5.x, Store, Phone80 and Phone81. What the blunt error message is telling you is that it has trouble finding that profile. Use Windows Explorer to have a look-see, the profile is stored in the C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETPortable\v4.5\Profile\Profile259 directory. It has the required System.Runtime.dll reference assembly.
Well, surely it awol, I can't guess at the underlying reason.
They did make subtle mistakes in the .nuspec file. Do consider a more stable release of Autofac, you probably don't want to be a beta tester. And don't target 4.5.2, there is no point to that. It doesn't add anything interesting and forcing your user to update his .NET install is not very reasonable.

Find which project in my solution has a reference to Framework 1.1

My solutions contains lots of project (33), some vb, mostly c#. Now in one of those projects there is a reference to the 1.1 framework.
My solution builds successfully, but won't run. It gives me the error:
"Could not load file or assembly 'System.xml, Version=1.0.5000' or one of it's dependencies. The system cannot find the file specified".
When I install the 1.1 framework it works just fine. I want to remove it so the 1.1 is not needed anymore to run my application.
How can I find where this reference is in all those projects? I know i've had to add in once to get a external lib working but now I stuck with the 1.1 framework...
Thx for any help.

In your solution root, run this from the command-line:
findstr /I /S "1.0.5000" *.csproj
findstr /I /S "1.0.5000" *.vbproj
that will list all of the C# and VB.NET project files that contain references to any 1.0.5000-versioned assemblies.

Few days ago, I faced the same issue and in order to resolve it these steps were followed:
In Solution Explorer:
Expand Project
Expand References
Select the DLL causing issue (In your case it would be System.XML)
Right Click and select Properties
Set Specific Version property to False
This should work in your case too!

The type or namespace name could not be found [duplicate]

This question already has answers here:
Getting "type or namespace name could not be found" but everything seems ok?
(44 answers)
Closed 8 years ago.
I have a C# solution with several projects in Visual Studio 2010.
One is a test project (I'll call it "PrjTest"), the other is a Windows Forms Application project (I'll call it "PrjForm"). There is also a third project referenced by PrjForm, which it is able to reference and use successfully.
PrjForm references PrjTest, and PrjForm has a class with a using statement:
using PrjTest;
Reference has been correctly added
using statement is correctly in place
Spelling is correct
PrjTest builds successfully
PrjForm almost builds, but breaks on the using PrjTest; line with the error:
The type or namespace name 'PrjTest' could not be found (are you missing a using directive or an assembly reference?)
I've tried the following to resolve this:
Removed Resharper (since Resharper had no trouble recognizing the referenced project, I thought it might be worth a shot)
Removed and re-added the reference and using statement
Recreated PrjForm from scratch
PrjForm currently resides inside the PrjTest folder, I tried moving it to an outside folder
Loaded the solution on a different computer with a fresh copy of VS 2010
I have done my homework and spent far too long looking for an answer online, none of the solutions has helped yet.
What else could I try?

See this question.
Turns out this was a client profiling issue.
PrjForm was set to ".Net Framework 4 Client Profile"
I changed it to ".Net Framework 4", and now I have a successful build.
Thanks everyone!
I guess it figures that after all that time spent searching online, I find the solution minutes after posting, I guess the trick is knowing the right question to ask..

In my case I had:
Referenced DLL : .NET 4.5
Project : .NET 4.0
Because of the above mismatch, the 4.0 project couldn't see inside the namespace of the 4.5 .DLL. I recompiled the .DLL to target .NET 4.0 and I was fine.

PrjForm was set to ".Net Framework 4 Client Profile" I changed it to ".Net Framework 4", and now I have a successful build.
This worked for me too. Thanks a lot. I was trying an RDF example for dotNet where in I downloaded kit from dotnetrdf.
NET4 Client Profile:
Always target NET4 Client Profile for all your client desktop applications (including Windows Forms and WPF apps).
NET4 Full framework:
Target NET4 Full only if the features or assemblies that your app need are not included in the Client Profile. This includes:
If you are building Server apps, Such as:
ASP.Net apps
Server-side ASMX based web services
If you use legacy client scenarios, Such as:
o Use System.Data.OracleClient.dll which is deprecated in NET4 and not included in the Client Profile.
Use legacy Windows Workflow
Foundation 3.0 or 3.5 (WF3.0 , WF3.5)
If you targeting developer scenarios and need tool such as MSBuild or need access to design assemblies such as System.Design.dll

Another thing that can cause this error is having NuGet packages that have been built with a newer version of .NET.
The original error:
frmTestPlanSelector.cs(11,7): error CS0246: The type or namespace name 'DatabaseManager'
could not be found (are you missing a using directive or an assembly reference?)
Further up in the log I found this:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1605,5): warning MSB3275: The primary reference "[redacted]\DatabaseManager\bin\Release\DatabaseManager.dll" could not be resolved because it has an indirect dependency on the assembly "System.Data.SQLite, Version=1.0.94.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139" which was built against the ".NETFramework,Version=v4.5" framework. This is a higher version than the currently targeted framework ".NETFramework,Version=v4.0".
The solution was to re-install the NuGet packages:
http://docs.nuget.org/docs/workflows/reinstalling-packages

I solved mine because the other project was coded with .NET 4.5 and the other one was coded 4.0

The using statement refers to a namespace, not a project.
Make sure that you have the appropriately named namespace in your referenced project:
namespace PrjTest
{
public class Foo
{
// etc...
}
}
Read more about namespaces on MSDN:
Using Namespaces

I encountered this issue it turned out to be.
Project B references Project A.
Project A compiled as A.dll (assembly name = A).
Project B compiled as A.dll (assembly name A).
Visual Studio 2010 wasn't catching this. Resharper was okay, but wouldn't compile. WinForms designer gave misleading error message saying likely resulting from incompatbile platform targets.
The solution, after a painful day, was to make sure assemblies don't have same name.

It is also possible, that the referenced projects targets .NET 4.0, while the Console App Project targets .NET 4.0 Client Library.
While it might not have been related to this particular case, I think someone else can find this information useful.

The compiled dll should have public Class.

I had the same issue. The target frameworks were fine for me. Still it was not working.
I installed VS2010 sp1, and did a "Rebuild" on the PrjTest. Then it started working for me.

Other problem that might be causing such behavior are build configurations.
I had two projects with configurations set to be built to specific folders.
Like Debug and Any CPU and in second it was Debug and x86.
What I did I went to Solution->Context menu->Properties->Configuration properties->Configuration and I set all my projects to use same configurations Debug and x86 and also checked Build tick mark.
Then projects started to build correctly and were able to see namespaces.

Changing the framework to
.NET Framework 4 Client Profile
did the job for me.

For COM/ActiveX references, VS 2012 will show this error right on using statement. Which is quite funny, since it's saying that may be you are missing a using statement.
To solve this: register the actual COM/ActiveX dll even if it's in the neighbor project, and add a reference through COM channel, not project channel. It will add Interop.ProjectName instead of ProjectName as a reference and this solves this strange bug.

If your project (PrjTest) does not expose any public types within the PrjTest namespace, it will cause that error.
Does the project (PrjTest) include any classes or types in the "PrjTest" namespace which are public?

just changed Application's target framework to ".Net Framework 4".
And error got Disappeared.
good luck;
:D

check your Project Properties, your Reference Paths should be empty like this:
Regards

"An assembly with the same simple name has already been imported" error without duplicate reference

I'm getting the following error:
error CS1704: An assembly with the same simple name
'Interop.xxx.dll, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=null has already been imported. Try removing one of the
references or sign them to enable side-by-side.
Everything I've seen says that I am referencing two assemblies with the same name and I need to remove one of them. However, I've checked and I'm only referencing it once.
This also only happens when I'm using msbuild to build from the command line on my dev box. If I build through Visual Studio or do a clean build on our CI server I don't see this error.
I've tried completely removing all of my source and building from scratch to more closely resemble the build machine but no luck.

So it looks like I can't read today!
The project had a reference to the Interop and a COM reference that generated the "same" interop. So there were two and I just didn't search very well. I still don't understand why it worked in other places but this did fix it.

In the Error List window, the project that was triggering this error was listed in the Project column. I got around the error by doing the following:
I unloaded the listed project (right-click => Unload Project)
Opened the XML for edit (right-click the unloaded project => Edit {ProjectName.csproj}).
Searched for the offending .dll, and noticed it was listed multiple times in the XML
Removed the entire Reference tag related to the offending dll, and did so for every copy of the reference except the first one listed
The reason it was listed multiple times was because several referenced libraries used that dll. This shouldn't be a problem, in and of itself, so I'm not sure what caused this error to suddenly pop up for me. I'll update this answer if I figure that out.

In my case the duplicate entry was caused by a NuGet package reference and a direct file reference to the same assembly in the packages folder. I am not sure how the project got into this state, but unloading the project and searching the XML file for the offending assembly name resolved the issue for me.
Note that in my case this started happening after updating a NuGet package to a newer version with no other changes to the project, so this maybe caused by a bug in NuGet.

If this is a web project, are there any strong-named references to the other version there? Those won't show up as a project dependency, but will cause a run-time error like you describe. Hope that helps

I had this problem but in my case, I had an old copy placed in the current folder for the EXE loading my component, that was loaded together with the current one, that was loaded by hand from my projects folder. Deleting that old copy solved my problem.
I used Debug > Windows > Modules window to see which modules were loaded at that time and that solved my problem.

For others facing the same as me: if building via command line using property AssemblyName, it will overwrite all assemblies generated by all solution projects - in other words, you will end up with (N -1) assemblies named the same where N is the no. of projects - the startup one (which generally will generate an exe).
This happens because all build command line properties are global and overwrite any project-specific setting. See this and this.
From the msdn link mentioned above:
Global properties are properties that are set by using the
/property switch on the command line, or properties that are set by
the integrated development environment (IDE) before a project is
built. These global properties are applied to all projects that are
built by using this Engine.
In my specific case, where Jenkins is the CI tool, I ended up adding a windows batch command at the end to rename the .exe only to what I originally intended when passing the AssemblyName parameter.

For those developing UWP projects that have project references that include specifically the Microsoft.Windows.SDK.Contracts nuget package (or other dependencies that reference it), this is a common error when the version of the SDK contracts is targeting a different version of the runtime to how your project is configured.
For instance, when targeting Windows 10, version 1903:
Any dependencies or reference projects should target or at least support the same runtime version.
it is common thought process to update all NuGet packages when a new stable version is available, but this is not always a helpful practise on its own. Just because a new stable version of a package is available does not mean that you should or that you can easily use that version.
Even though this package for SDK contracts has a stable update, it is not compatible with my main project configuration, Nuget does not know this so it allows the update.
This package is specifically designed to provide windows dlls for project types that DO NOT have windows platform targeting support, it copies the same dlls that are included by the UWP targeting config. By installing later versions of the package the references from the satellite project will be included in the output along with those provided due to platform targeting, ultimately causing OPs error.
There are similar SDK and targeting packs for Windows IoT Device Runtimes, this information should help you identify and resolve those issues if you get stuck on this issue as my team often does :)

In my case, the issue was on wrong characters in the ProjectReference section of my csproj file.
Background
I have a project that references another library I maintain, which I publish as a NuGet package.
Whenever I make changes to my library, I usually reference the local dll in my project to test and make sure everything looks good before I publish the library as a NuGet package.
When testing, I just comment out the PackageReference line and uncomment the ProjectReference one so it references my local dll, like so:
<ProjectReference Include="..\..\my-class-library\MyClassLibrary.csproj" />
<!--<PackageReference="MyClassLibrary" Version="2.0.1"/>-->
Root cause
I had the slashes inverted, so I was using / rather than \ in the path, like so:
<ProjectReference Include="../../my-class-library/MyClassLibrary.csproj" />
Once corrected, the issue went away.

Try this instead: remove Interop.xx.dll from the reference section in Solution Explorer and Rebuild the project

In our case this error was shown when we had a duplicate reference inside the .csproj file (although I have no idea how this happened).
The difference to an already posted answer is that, in our case, one was a project reference and another one was direct binary reference to a dll.
Once we removed one of those, project correctly compiled.