Related
I am using Visual Studio online to manage my sources. I am also using Continous Integrations which means my source is compiled in the cloud on the TFS(Visual Studio Online).
I have my own build process template and also a few code activities. Since now everything works fine. After I edited the activities and also the template, everytime I start a build, I get the following error:
TF215097: An error occurred while initializing a build for build definition \BuildTest\BuildTasks:
Exception Message: Expression of type 'Microsoft.TeamFoundation.Build.Workflow.Activities.AgentReservationSpec' cannot be used for return type 'Microsoft.TeamFoundation.Build.Workflow.Activities.AgentReservationSpec' (type ArgumentException)
Exception Data Dictionary:
MS.TF.Diagnostics.Logged = True
A strange side effect is, that the order of the arguments of the build template in Visual Studio is now mingled and there are also some arguments, which are not defined in the template. This happens not only for my custom template, but also for the default templates from Microsoft.
Can anybody help me?
The cause of such errors is due to two versions of the assembly providing the erroneous type being visible simultaneously. The value being assigned from is from one and the value being assigned to is from the other.
This happened to me when I accidentally checked in a load of Microsoft.TeamFoundation assemblies into my custom activities location in source control. Removing these assemblies made the issue go away for me.
Also worth looking out for is if you have more than one version of the TFS API installed on your build controller (multiple versions of Visual Studio will do this). You may need to use explicit versions (full strong name syntax) in the references to TFS assemblies in your projects to ensure the correct API version is loaded.
I had the same problem with our local TFS instance. I removed all my DLLs from the CustomActivities-Folder in TFS and the error was gone.
Now second steop is to identify the CustomAction causing the problem ...
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.
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!
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
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.
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.
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.
It just happened to me that different projects were referencing different copies of the same dll.
I made sure all referenced the same file on disk, and the error disappeared as I expected.
Unloading and reloading the class library in Visual Studio solved this for me.
For me, this was caused by the project both directly and indirectly (through another dependency) referencing two different builds of Bouncy Castle that had different assembly names. One of the Bouncy Castle builds was the NuGet package, the other one was a debug build of the source downloaded from GitHub. Both were nominally version 1.8.1, but the project settings of the GitHub code set the assembly name to BouncyCastle whereas the NuGet package had the assembly name BouncyCastle.Crypto. Changing the project settings, thus aligning the assembly names, fixed the problem.
It didn't work for me when I've tried to add the reference from the .NET Assemblies tab.
It worked, though, when I've added the reference with BROWSE to C:\Windows\Microsoft.NET\Framework\v4.0.30319
I had this issue on a newly created solution that used existing projects. For some reason, one project could not "see" one other project, even though it had the same reference as every other project, and the referenced project was also building. I suspect that it was failing to detect something having to do with multiple target frameworks, because it was building in one framework but not the other.
Cleaning and rebuilding didn't work, and restarting VS didn't work.
What ended up working was opening a "Developer Command Prompt for VS 2019" and then issuing a msbuild MySolution.sln command. This completed successfully, and afterwards VS started building successfully also.
one of main reason can be the property of DLL
you must before do any thing to check the specific version property if it true make it false
Reason:
maybe the source code joined with other (old)version when you build it , but this Library upgraded with new update the version now different in the Assembly Cash and your application forbidden to get new DLL ,and after disable specific version property your applacaten will be free to get the new version of DLL references
Maybe a library (DLL file) you are using requires another library. In my case, I referenced a library that contained a database entity model - but I forgot to reference the entity framework library.
This can also mean you use a library, which exposes (public) types that are defined in a library. Even when you do not use these specifically in your library (the one that doesn't build).
What this probably prevents is you writing code that uses a class (which in its signature has the types from a library not referenced) that you cannot use.
For me the reason why the error appeared was that the WebForm where the error was reported has been moved from another folder, but the name of its codefile class remained unchanged and didn't correspond to the actual path.
Initial state:
Original file path: /Folder1/Subfolder1/MyWebForm.aspx.cs
Original codefile class name: Folder1_Subfolder1_MyWebForm
After the file was moved:
File path: /Folder1/MyWebForm.aspx.cs
Codefile class name (unchanged, with the error shown): Folder1_Subfolder1_MyWebForm
The solution:
Rename your codefile class Folder1_Subfolder1_MyWebForm
to one corresponding with the new path: Folder1_MyWebForm
All at once - problem solved, no errors reporting..
The type 'Domain.tblUser' is defined in an assembly that is not
referenced. You must add a reference to assembly 'Domain,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.
**Solved:**
Add reference of my domain library layer to my web app libary layer
Note: Make sure your references are correct according to you DI container
In my case this was because I used
Implicit Operator
between BLL and DAL classes.when I want to use BLL Layer In Application Layer I got this error.
I changed
implicit operator
to
explicit operator
it be OK.
Thanks
In my case the version of the dll referenced was actually newer than the one that I had before.
I just needed to roll back to the previous release and that fixed it.
I have a similar problem, and I remove the RuntimeFrameworkVersion, and the problem was fixed.
Try to remove 1.1.1 or
My problem was that the Output Type for one of my projects was set to Console Application. To fix this, I right-clicked the project, chose Properties, clicked the Application tab, and change Output Type (from Console Application) to Class Library. After I re-compiled, this error went away.
Clean your solution and rebuild worked for me (in Visual Studio, these are options you get when you right click in your solution explorer), the error is gone in my project.
I am calling a static method on a class like
Foo.bar()
Visual studio's intellisense recognizes Foo and autocompletes bar for me (it highlights Foo and everything like it is working fine). Everything looks fine until I go to build the project, and it throws an error saying the name Foo doesn't exist in current context.
I am using this static method call in other files, so I know the class is ok. The situation is too big to post code, so I am mostly looking for reasons to start looking into that would cause intellisense to function normally but get errors on compile like this.
I've seen this error caused by differing versions of the .NET framework in the different projects. The Class Library I built was 4.5 and the application was 4.0, but the only error it gave was namespace errors. Changing the framework version on the class library and rebuilding it, then the application, resolved the error.
This can occur when namespaces, classes and variables become tangled when they have the same name. I have suffered with this before. Intellisense told me I was right, the compiler told me I was wrong! I trusted the compiler!
You have 2 options that I can think of
Search your code for Foo, and see it it is being used for something other than the static class.
Fully qualify the Foo.bar() call. MyApplication.This.That.Foo.bar();
Do it in that order...it's better to elegantly resolve the issue so you can just call Foo.bar() as this is more readable and maintainable than having MyApplication.This.That.Foo.bar(); all over the place!
In my case I was missing a } at the end of one of the methods in the middle of the code which was causing the program not see the rest of the code and complain about the Methods I have defined after that point.
Old thread I know, but I've encountered this issue when referencing a static method from within a unit test project - intellisense said the method was there, but when I tried to build/run the test (in Debug mode) I got the error 'name doesn't exist in current context'. In order to fix it I had to rebuild the project containing the referenced static method in Debug configuration (it had only previously been built in Release configuration) - after this the test built and ran OK.
I know this is a bit old topic, but I just experienced the same and for me it was because the file was not actually included in the solution.
I properly happened because I had renamed the class and then the file, which caused Visual Studio to still know the class and the namespace, but the compiler did not get the file as the renamed file was not included.
Consider doing a Clean and then a Build on the project with the problem. It is possible for the editor and Intellisense to correctly discover the class, while the compiler works with files that are out-of-date. (I had this same problem, and that's how I resolved it.)
this is an old article I know, but I just encountered this issue and has been puzzling me for couple of days, and eventually got to it: click on the class file, in Solution Explorer, then look at the Properties tab; make sure Build Action is set to "Compile".
Adjust the related file. If the error code in Default.aspx.cs, you need to change the top line in the file Default.aspx as below:
Replace "CodeFile=" with "CodeBehind"
Hope this can help.
-Thanks, Thai_FUV
I have run into this probelm a few times and so when I do, the first thing I check is if the assembly not recognized has any Nuget packages. In my cases they always have and I simply forgot to install the same packages in the assembly of which the reference to the un-recognized assembly is in. A re-build command and problem fixed. I hope this helps someone. This same error message can be given for multiple things so this particular case, may not apply. If you have not used Nuget than I would suggest trying the other answers
I also was running into this issue creating a data access layer and had static methods being called with the same symptoms: Intellisense finding it but not the compiler. I tried many of the above, including fixing the .Net version.
When adding the source files to the project I also changed the namespace.
With the file with the issue, I forgot to change the namespace to match when it was imported at another time.
Closing all tabs of MonoDevelop. Then Closing MonoDevelop. Finally opening MonoDevelop again solved the problem for me.
Mine was a little more convoluted solution. Project A referenced projects B and C: both references had Copy Local to true and both produced assemblies with identical names. When building the referencing project, the output assemblies from projects B and C were copied and one overwrote the other because they had the same name. VS was then looking for the references within the build directory and only found the assembly that had "won."
In my case I had to reload the project that was marked "missing".
Project > Unload Project
Project > Load Project
Clean, Build Solution
My solution to this problem that occurs every now and then:
Find the class that is giving you problems in the Solution Explorer and "Exclude From Project"
Rebuild that assembly (let's call it "A")
The project that used the file ("B") will ask you to "Reload" project, wait
Add the file back into assembly A, that you just removed it from, and rebuild
Now, reload project B
Then the file was found in VS and all was well.
Changing the id of the control resolved the issue for me. Apparently the id of the control existed in another part of the solution.
In my case, I was missing the following lines in my csproj file
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
<DefineConstants>TRACE</DefineConstants>
<DebugType>full</DebugType>
<DebugSymbols>true</DebugSymbols>
</PropertyGroup>
Once I added this, I could see the variables while debugging
Hej All,
I upgraded my solutions of a project from vs2008 to vs2010.
But right now I have a weird problem. I reference a project in multiple solutions (3 solutions)
In 2 of those solutions the referencing goes wrong.
I am able to add the reference (project reference) but when I build I got the warning the referenced project x does not exists. And errors that I have to add an reference.
I already deleted and added the project again, same with the references but no result.
Does anybody have any idea?
Greetz,
Jonathan
I had the a similar problem and the other solutions didn't help. What worked for me was opening the project file in a text editor. There were duplicate references to a library, one as a project reference and one as a dll reference. I deleted both. Then I opened the solution in Visual Studio, and re-added the reference as a project reference. Only one reference got added and I stopped getting the warning.
Make sure your project is not using the ".NET Framework 4 Client Profile" as target framework, this is the most common source of these problems.
You can check this in the project properties under Target Framework.
From MSDN:
If you are targeting the .NET
Framework 4 Client Profile, you cannot
reference an assembly that is not in
the .NET Framework 4 Client Profile.
Instead you must target the .NET
Framework 4. For more information, see
Troubleshooting .NET Framework
Targeting Errors.
I was experiencing the very same issue although I was correctly referencing .NET 3.5 in all the projects migrated from VS 2008 to VS 2010 (all references to System assemblies were using a runtime version v2.0).
Weird however, the error only occured if my solution (and the projects in this solution's subfolders) were located in certain path... I could "solve" the problem by moving the projects or renaming the projects (only the project file, not the output binaries) ?!
Double clicking the reference in the project opened correctly the Object Browser where I could find all the artifacts defined in the referenced project !
I did start to delete everything from the project (classes, resources, references, etc...). At the end, I had only two projects (A referencing B) without any other references and with only one empty class in each. I still had the message "referenced project '..\B\B.csproj' does not exist.". Suddenly, trying to copy the source to another PC and next back into the original path on my machine (kind of black magic to solve the problem), I did get the message "Cannot copy. Resulting file name is too long".
Wierd² !!! I did delete every thing on my PC and did copy back again the sources from the other PC. It passed successfully ! I did recopy again back from the other PC (overwriting now the existing local copy) and again I got the message "Cannot copy. Resulting file name is too long". So the problem occurred only when overwriting existing files.
I found that the error occurred only if the existing file was "readonly". Removing the flag readonly solved this issue. However, this error was the sign of something possibly at the root cause of my initial issue: "referenced project '..\B\B.csproj' does not exist."
So, I decided to check if the project path length was the issue by renaming one of the folder but not changing the total length! The error still occurred (reference not found).
Next (I knwow, you already think I am crazy or stupid. But all those steps were validated by various colleagues), I did copy the solution in a new folder (with a longer path). Surprise, the error did not occurred anymore !!!
But moving the solution back to a folder with the same length (possibly another name) was reintroducing the error (after a "Clean" of the solution otherwise the meta in obj helped to solved the reference).
I was also able to reproduce this by renaming the project file B instead of a folder in the path. A longer or shorter project filename was solving this issue.
The length of the project filepath is "195" :
D:\TFS_Builds\5\XXXX 1.1\Release 1.11\Sources\Release 1.11\Exception Repository\XXXXXX.Framework.ExceptionHandling.Repository.ServiceHost\XXXXXX.Framework.ExceptionHandling.Repository.ServiceHost
Also, as I can be very creative when trying to identify the root cause of a problem, I did create the very same path on C:\ and put the solution in there... Same error occurred.
I never found (until now) the reason of this and have posted a question on MSDN :http://social.msdn.microsoft.com/Forums/en/msbuild/thread/f0eb6aed-5854-4678-9546-09c1a7705e30
Here is what fixed my problem:
I had a refference to a project named "Utilities.Proxy3.5", which would give me a the following warning:
"The referenced project
'..\..\Utilities.Proxy3.5\Utilities.Proxy3.5.csproj' does not exist."
Renaming the project folder and the project files to "Utilities.Proxy35" and re-adding the reference solved the problem. Note: I have only removed a dot between the numbers 3 and 5.
I hope this will help someone.
I had the same issue.
What solved it for me was that i opened each of the reference projects on its own first. VS asks for a permission to fix some of the files. Allow it to do so.
Then open the top project and it will work.
Apparently it was issues with the version of VS that created the original project.
Good luck
Check the lengths of the following:
The path of the referencing project's directory
The relative path to the project it references
If those paths add up to exactly 259 characters, you will experience a bug in the .NET implementation of Path.GetFullPath that will cause VisualStudio 2010 to behave as if the referenced project does not exist.
I have a WPF/ASP.NET project which I haven't worked on for a while (ResourceBlender.NET - http://resourceblender.codeplex.com/). The project contains a DataLayer and a Core layer, these are both used by the WPF application and ASP.NET project in the solution.
If the WPF project is set as the startup project and I try to build the application, I get "The type or namespace name 'whatever' could not be found (are you missing a using directive or an assembly reference?)".
The error list shows these when I try to build, run or debug, but double clicking and going to the error shows no actual errors in the editor and everything is highlighted as normal.
The ASP.NET project builds fine. I'm absolutely clueless on this one, as there are no obvious errors to fix - could it be metadata somewhere?
Check that all assemblies does not target the 3.5/4.0 Client Profile (It is probably the WPF application that is the culprit). This will cause exactly the error message you're describing.
This type of thing is really hard to debug without being able to see your solution setup, but here are the things I would try:
Expand the references in your WPF project, make sure they are all resolving
Double-check that none of your references have "specific version" set to True and point to an old/nonexistent version
Do a "Clean" on your solution, close VS and delete your bin and obj directories, etc. to clear out potentially old copies of dlls that may be messing up your build
Good luck!
Try the following:
Right-Click on the solution on do a "Clean Solution"
Try to build each project separately
Check the references on your projects for missing assembly references
Compile issues like this can be overwhelming. It's usually best to troubleshoot one project at a time as suggested in these tips:
5 Debugging Tips for a Solution That Won't Compile
Actually read the Output window text.
often errors or warnings that are pertinent appear in there but aren't obvious when following the Error List window links.