The type is defined in an assembly that is not referenced, how to find the cause?
Solution 1
When you get this error it isn't always obvious what is going on, but as the error says - you are missing a reference. Take the following line of code as an example:
MyObjectType a = new MyObjectType("parameter");
It looks simple enough and you probably have referenced "MyObjectType" correctly. But lets say one of the overloads for the "MyObjectType" constructor takes a type that you don't have referenced. For example there is an overload defined as:
public MyObjectType(TypeFromOtherAssembly parameter) {
// ... normal constructor code ...
}
That is at least one case where you will get this error. So, look for this type of pattern where you have referenced the type but not all the types of the properties or method parameters that are possible for functions being called on that type.
Hopefully this at least gets you going in the right direction!
Solution 2
Check target framework in the projects.
In my case "You must add a reference to assembly" actually meant, that caller and reference projects didn't have the same target framework. The caller project had .Net 4.5 , but referenced library had target 4.6.1.
I am sure, that MS compiler can be smarter and log more meaningful error message. I've added a suggestion to https://github.com/dotnet/roslyn/issues/14756
Solution 3
In my case this was because doing a NuGet package update had only updated references to a dll dependency in some but not all projects in my solution - resulting in conflicting versions. Using a grep-style tool to search text within *.csproj files in my solution it was then easy to see the projects that still needed to be updated.
Solution 4
When you get this error, it means that code you are using makes a reference to a type that is in an assembly, but the assembly is not part of your project so it can't use it.
Deleting Project.Rights.dll is the opposite of what you want. You need to make sure your project can reference the assembly. So it must either be placed in the Global Assembly Cache or your web application's ~/Bin directory.
Edit-If you don't want to use the assembly, then deleting it is not the proper solution either. Instead, you must remove all references to it in your code. Since the assembly isn't directly needed by code you've written, but instead by something else you're referencing, you'll have to replace that referenced assembly with something that doesn't have Project.Rights.dll as a dependency.
Solution 5
In my case, I was referencing a library that was being built to the wrong Platform/Configuration (I had just created the referenced library).
Furthermore, I was unable to fix the problem in Visual Studio Configuration Manager -- unable to switch and create new Platforms and Configurations for this library. I fixed it by correcting the entries in the ProjectConfigurationPlatforms
section of the .sln
file for that project. All its permutations were set to Debug|Any CPU
(I'm not sure how I did that). I overwrote the entries for the broken project with the ones for a working project and changed the GUID for each entry.
Entries for functioning project
{9E93345C-7A51-4E9A-ACB0-DAAB8F1A1267}.Release|x64.ActiveCfg = Release|x64
{9E93345C-7A51-4E9A-ACB0-DAAB8F1A1267}.Release|x64.Build.0 = Release|x64
Entries for corrupted project
{94562215-903C-47F3-BF64-8B90EF43FD27}.Release|x64.ActiveCfg = Debug|Any CPU
{94562215-903C-47F3-BF64-8B90EF43FD27}.Release|x64.Build.0 = Debug|Any CPU
Corrupted entries now fixed
{94562215-903C-47F3-BF64-8B90EF43FD27}.Release|x64.ActiveCfg = Release|x64
{94562215-903C-47F3-BF64-8B90EF43FD27}.Release|x64.Build.0 = Release|x64
I hope this helps someone.
Comments
-
afaf12 almost 2 years
I know the error message is common and there are plenty of questions on SO about this error, but no solutions have helped me so far, so I decided to ask the question. Difference to most of similar questions is me using App_Code directory.
Error message:
CS0012: The type 'Project.Rights.OperationsProvider' is defined in an assembly that is not referenced. You must add a reference to assembly 'Project.Rights, version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.
Source File:
c:\inetpub\wwwroot\Test\Website\App_Code\Company\Project\BusinessLogic\Manager.cs
Following suggestions here and here, I have deleted all instances of Project.Rights.dll inside C:\Windows\Microsoft.NET/*.* According to this, I checked if .cs files in question have build action set to "Compile". They do. I have also double checked that the .cs file containing the "Project.Rights.OperationsProvider" type is deployed to App_Code directory.
For some reason, application is not looking for the type in the App_Code directory. Since I've deleted all instances of Project.Rights.dll (that I know of), I don't know which assembly the error message is mentioning.
-
afaf12 over 10 yearsI can't use the assembly, that is a requirement. I need to get rid of it and store the class inside App_Code directory. I know how it sounds, believe me. Being tasked to alter an application so all business logic is stored inside App_Code instead of DLLs... is not fun.
-
Adriano Repetti over 10 yearsNo, it means he's using something with a reference to it (not that he's using directly). @afaf12 if you have to get rid of it...you have to check who is using it (imagine this as an indirect reference). You can't simply paste code in App_Code directory, any compiled assembly will still reference original (and external) one...
-
Athari over 9 yearsNote about extension methods: if two classes have extension methods with the same name, parameters from one type can "infect" usage of extension method from another type.
-
ykh about 8 yearsI had a similar and your post helped a lot. In my case i had an assembly "A" referenced. This assembly was using another assembly "B". I kept getting an error that assembly "B" is missing though i added it to my project. Once i copied assembly "B" to my bin directory the problem was solved. The reason is that my project wasn't using assembly "B" but assembly "A" was using and it didn't found it and thus throw an exception. Thanks.
-
Ryanman over 6 yearsThanks for this answer - I figured it was something close to this but was glad to see it. Put another way - my parent project (service) calling a constructor with an optional parameter in my data layer had not had that reference added to the .csproj. Comparing the child and parent .csproj files should illuminate an ItemGroup that should be in the parent that's not.
-
Michael Freidgeim over 6 yearsVisual Studio Package Manager window for the Solution ( not for individual project) has Consolidate tab, that shows which packages have different versions in different projects. It provably better than grep-like tool
-
Dave Cousineau over 6 years@Athari thank you, I never would have figured that out
-
Stephen Kennedy over 6 yearsI suggest you can make your answer more helpful by also explaining how you fixed it.
-
Diane over 5 yearsJust chanced upon this answer after a while of looking. This is exactly my problem and your explanation was very helpful. Thanks loads.
-
Robert Iagar over 5 yearsBut what if I don't want to use the constructor with the reference? I want to use the other ones, without adding a reference. It seems like this should be possible.
-
Tolu almost 5 yearsThis seems really odd, but I got this error because I had a mismatch in the case of one of the assembly names (looks like nuget was case sensitive?)! I had a library C reference libraries B and A. Library B also referenced library A but packaged A as a dependency using the name 'a' rather than 'A' . Building library C, I kept getting this error until I corrected the name of the dependency in B!
-
scor4er about 4 yearsFor me it was similar. VIsual Studio have changed GUIDs for some of my projects from
FAE04EC0-301F-11D3-BF4B-00C04F79EFBC
(C#) to9A19103F-16F7-4668-BE54-9A1E7A4F7556
(ASP.NET). After I changed them back everything gone well. -
Cale Sweeney over 2 yearsAlso make sure you know the difference between framework types. They have similar slightly confusing names beginning with .NET, and close version numbers, but they are incompatible. docs.microsoft.com/en-us/dotnet/standard/…
-
Anthony about 2 yearsYea it turns out this is the only way to workaround. The only problem is, if I need to debug my solution, I have to run msbuild in Developer Command Prompt, then press F5 in VS and choose the last successful build.