Related
I am developing an Android app using Xamarin.
Visual Studio shows this warning, and I don't know what it means. I've followed the instructions but I can't seem to find the temp\\file
Severity Code Description Project File Line Suppression State Detail Description
Warning IDE0006 Error encountered while loading the project. Some project features, such as full solution analysis for the failed project and projects that depend on it, have been disabled. daijoubu-app 1 Active To see what caused the issue, please try below.
1. Close Visual Studio
2. Open a Visual Studio Developer Command Prompt
3. Set environment variable “TraceDesignTime” to true (set TraceDesignTime=true)
4. Delete .vs directory/.suo file
5. Restart VS from the command prompt you set the environment varaible (devenv)
6. Open the solution
7. Check 'C:\Users\Noli\AppData\Local\Temp\\daijoubu-app_*.designtime.log' and look for the failed tasks (FAILED)
The full source is available on github.
I just followed the instructions but it did not eradicate the warning,
although I ignored it, it does not appear now.
When rebuilding the project, I noticed it takes a long time because it downloads a zipfile on your %userprofile%/AppData/Local/Xamarin/zips/*
-Make sure to not interrupt the build because it will stop downloading and will cause an invalid zip later on, thus reproducing this issue?
Another hypothesis is that I included a component(referenced a dll) and then deleted it, and then re-added it. (as I'm having trouble with intellisense)
Firstly, it's not an 'Error' it's a warning.
Here's what actually happens:
Visual studio/xamarin check for required sdkbuild tools for your project
If you have it already in your SDK then no problem
If not, your project will show above warning in most of project cases.
How to fix this :
Clean your solution
Rebuild it (at this stage visual studio will automatically try to download zips)
If you get Rebuild canceled error, then close visual studio and start again
At this stage it will definitely download required zips.
Again Clean -> Rebuild -> Build -> Close the visual studio and open it again
Or Simplest alternative is
Download all SDKBuild tools available.
Your warning will be gone.
Let me know if it works, coz its worked for me several times.
I too had both Intellisense and compilation issues.
On my Xamarin Forms and Android project, what worked for me is checking out the Resource.Designer.cs file in my Android project, quitting Visual Studio, and then re-opening it.
Hope that helps somebody.
I had this error also. The error was totally my fault, I was adding some strings to my strings.xml file and accidentally left an empty item in there
<string name=""></string>
This broke the R.java file in a really bad way, as the string/resource didn't have a name/id this is how it was created within R.java.
public static final int =0x7f080060;
As you can see it's missing its identifier. The moral of the story is: check all of your XML for any errors.
i had got this warning for 5 days. i applied this suggestion and problem is end.
to install package: 'Xamarin.Android.Support.[BLABLA]'
unzipping has failed:
Please download https://dl-ssl.google.com/android/repository/android_m2repository_r22.zip
in the C:\Users\[UserName]\AppData\Local\Xamarin\Xamarin.Android.Support.Design\23.0.1.3\content directory
Reason: File C:\Users\[UserName]\AppData\Local\Xamarin\zips\96659D653BDE0FAEDB818170891F2BB0.zip is not a ZIP archive
1) Downloading the zip and installing it didn't solve my issues, I got fewer errors, but in general, the messages stayed the same, Please install package [BLABLA], Unzipping failed,...
2) Next I took a look at the zip file they mention in C:\Users\[UserName]\AppData\Local\Xamarin\zips and indeed, 96659D653BDE0FAEDB818170891F2BB0.zip was corrupt. I deleted this zip, did build my project again, and after the build process (this takes a while, leave it 'building': you see your zip reappear and growing to 135MB) all the previous warnings/errors were gone!
Save and close your project.
Go to your path folder.
Move the bin and obj folders from the Android folder to another
location.
Run the project again.
Moving these folders means deleting them and backing them up just in case!
I solved it this way. I hope it helps. :)
I also had this annoying experience, in App2.Droid
"Warning IDE0006 Error encountered while loading the project. Some project features, such as full solution analysis for the failed project and projects that depend on it, have been disabled."
... but I seem to have fixed it on my pc.
At certain times when rebuilding my project I also had other errors than the usual ones, telling me
to install package: 'Xamarin.Android.Support.[BLABLA]'
unzipping has failed:
Please download https://dl-ssl.google.com/android/repository/android_m2repository_r22.zip
in the C:\Users[UserName]\AppData\Local\Xamarin\Xamarin.Android.Support.Design\23.0.1.3\content directory
Reason: File C:\Users[UserName]\AppData\Local\Xamarin\zips\96659D653BDE0FAEDB818170891F2BB0.zip is not a ZIP archive
1) Downloading the zip and installing it didn't solve my issues, I got fewer errors, but in general, the messages stayed the same, Please install package [BLABLA], Unzipping failed,...
2) Next I took a look at the zip file they mention in C:\Users[UserName]\AppData\Local\Xamarin\zips and indeed, 96659D653BDE0FAEDB818170891F2BB0.zip was corrupt.
I deleted this zip, did build my project again, and after the build process (this takes a while, leave it 'building': you see your zip reappear and growing to 135MB) all the previous warnings/errors were gone!
It seems manually putting the unzipped files in place didn't work because VS was still trying to unzip the corrupt zip file.
This zip file is unzipped after the first build of the droid project. I remember initially I manually stopped the building of the droid project several times because it was extremely slow and it appeared to hang: probably the first build action tried to download the zip file and unzip it,
canceling (I might have even shot down VS one time) that build that took like forever (I had a terribly slow internet connection that evening) corrupted the zip.
Note:
in C:\Users[UserName]\AppData\Local\Xamarin\zips there are several zip files, my error did tell me the name of the right one.
in C:\Users[UserName]\AppData\Local\Xamarin\Xamarin.Android.Support.Design I had several 23.X folders, one with content in its 'content' subdir, and one without: the 23.0.1.3 one, as specified in the error texts.
Edit: basically what #trycatch answered, his first option is confirmed ;)
I am developing a VB.NET (4.5 framework) solution in Visual Studio 2015, Win10 OS, and have been able to run the builds uninhibited for several months, but now I am receiving the following error upon starting the build:
vbc : error BC2012: can't open
'C:\MyProject\ProjR5\ProjR5\obj\Debug\ProjR5.exe' for writing: Access
to the path 'C:\MyProj\ProjR5\ProjR5\obj\Debug\GenTagR5.exe' is
denied.
At first, VS2015 would give me the option to run the last successful build, but even that is no longer an option. After exhaustive internet searches on this problem, none of the dozen or so given solutions are solving my issue.
Here is what I have tried in order to resolve the error so far:
Ran sfc /scannow (elevated prompt)
Using ProcessExplorer, find handle or DLL substring that included my project
Made sure there were no hanging procs (including procs with my project name, devenv.exe, [project].exe, [myproject].vhost.exe, etc.)
Restarted VS2015
Restarted VS2015, running "as Administrator"
Restarted Computer
Full Shutdown of computer
Complete Rebuild of Solution
Build->Clean Solution
Build->Clean Solution, then Build->Build Solution
Build->Rebuild Solution
Uninstalled and Reinstalled VS2015
Disabled all indexing
Removed "Read Only" attribute from entire project folder and files within
Checked startup scripts for like- or identical processes
Disabled all AV apps
Disabled all antispyware apps
Disabled all firewalls
Verified that Application Experience (services.msc) wasn't disabled (I'm using
Win10 ... it isn't even in the list of services)
Set Tools->Options->Projects and Solutions->Build and Run->Max. parallel
builds to 1
Rerun aspnet_regiis.exe (under .NET\Framework)
Checked Local Security Policies and verified account was listed under
"Impersonate a client after authentication"
Removed \bin and \obj folders
Put \bin and \obj back when removing them didn't help
Removed \bin and \obj folders, then Rebuilt
None of these have worked. Any suggestions?
The problem ended up being Samsung Magician's Rapid Mode losing data during its write-caching phase to my solid state drive. I turned off Rapid Mode, and now the project builds without any problems.
Sorry for came too late, but i had this problem and i wanted to show how i fixed for the next devs who need a solution:
It's quite simple, just change your proyect assembly name:1) On your solution explorer: Right click on your proyect.
2) Properties>> aplication>> assembly name>> change it.
3) Compile, run to test it.
4) Change the name again if u wanted the original name.
Adding a description:
Changin the assembly name
New 2 programing in VS but i had same problem of Access or Write exe file ON BUILD.
Problem came out of nowhere. I didn't use or make changes 2 exe file in months,
made exe file, used it now and then and forgot about it....
Then after few months i wanted 2 start exe but no icon on desktop ??? ....tried everything, lost 3 days of searching inside code for error in VS and then called Google....
I read last comment ABOVE which mentioned Bitdefender, opened it and found BitD did block and isolate exe files ..... so i tried exluding files and folders which made problems inside BitD but no help....
So i went back 2 VS.
Within debug i got some X86 processor error which didnt make problem to build but it was warning (free component name in error description helped me ), - errors you can ignore but they are here on build ....
So i made last move before starting it all over again. Removed COMPONENT from application, deleted it on PC ...started VS from start .. and ALL was OK !!!
So in my case it was all about FREE component i used in app inside VS .... Bitdefender found some add / virus in it and blocked build progress.
BitD deleted or blocked exe file in start....
Hope this help anyone with similar problem !
The cause of this error for me was that Team Foundation Server had pulled in a bunch of files to my work space as Read-only. Not sure why it pulled them down from the server with read-only checked, but all I had to do was uncheck it.
Ok. Create a new solution and add its directories to the exception list and copy all your work, except for the '.vbproj' and except for the '.csproj' and the directory files to the directory of the directory of the new solution. I have tried that and it works, due that I have Bitdefender, it will be the only way to sort that issue. After doing so, try to build the app again. If it does not work, then I am definitely out of ideas.
Visual Studio (and possibly TFS) has somehow (I think perhaps during a source control merge) become confused about the path of a project within my solution.
It thinks it is here (example paths for simplicity):
C:\My Projects\ExampleSolution\ExampleProjectWrong\ExampleProjectCorrect.csproj
whereas actually, the project file is located here:
C:\My Projects\ExampleSolution\ExampleProjectCorrect\ExampleProjectCorrect.csproj
I cannot for the life of me get it to recognize the correct location. I have tried:
Removing and re-adding the project from the correct location. An error message comes up saying The project file at C:\My Projects\ExampleSolution\ExampleProjectWrong\ExampleProjectCorrect.csproj could not be found.
Manually editing the .sln file to ensure all references to ExampleProjectCorrect.csproj have the correct paths.
Doing a find in files on the solution directory for both the correct and incorrect paths, to try and track down where studio is hiding the incorrect path.
Deleting the cache directories for VS and TFS
I'm tearing my hair out because I can't recreate the solution as it has near as makes no difference 100 projects in and is tied in to source control with several other developers working on it.
Can anyone point me in the right direction as to where it is storing this incorrect path and/or how to reset it so the damn thing will load correctly?
Go to Manage Workspaces (either through the File/Source Control menu or the workspace drop down in Source Control Explorer)
select edit for your workspace.
You should see, under working folders, a mapping for the source
control directory to the old/wrong project directory.
Select it and click remove.
Close VS and delete the suo file.
It still references the wrong directory. Maybe rebinding might work at this point but I didn't try that. Reload your project and you should be good to go.
Simply deleting the solutions .suo file worked for me.
I was facing this issue after performing a migration from Visual Source Safe 2005 to TFS 2012. I couldn't wait for the "Conversion Wizard" due out in the next couple weeks so I just ran VSSConvert.exe. This took 6 or so years of history and moved it into TFS.. while I didn't get the actual timeline history.. I got a bunch of entries on the same day with the comments indicating the actual check-ins of the history.. not bad.
So after it ran all night (Successfully, yay!), I was having trouble loading my projects just as this question stated. For some reason, a few projects were being referenced to an incorrect directory. I checked the .sln, the .vsproj files, and getting latest, deleting re-getting, adding removing, etc.. I tried everything noted here... even upgrading my workspace, which I'm not sure what that even did.
FINALLY... I deleted the *.suo files and viola. It worked.
I spent a couple hours on this one.
A slightly different solution.
TFS was displaying a non-existing path for a particular Solution. Previously, I had a laptop with a separate D: drive, but now, I just have a C: drive. TFS still thought my project was stored on D:\Project\MikesProject
I didn't have a .suo file to delete, the D: path wasn't mentioned anywhere in my Workspaces (buried away under the File\Source Control\Advanced\Workspaces menu), TFS showed that I did have the latest files in my (no-longer-existant) D: directory, and TFS in VS2013 didn't have a "Remove Mappings" option for this project.
But what did work was to simply do a "Get latest version" on the project.
After doing so, a fresh copy of the code was written to my C: drive, and (interestingly), now the Local Path was shown underlined.
Previously, the D: path wasn't shown like this.
Odd. Very odd.
We've had similar issues with moves and renames.
Deleting the local directories and then getting again solved it.
Even after deleting the .suo file and .vs folders, I had to edit the .sln file and remove the old relative url from SccProjectName# despite the SccLocalPath# being correct. Apparently VS also uses the name as a hint path.
Try to delete or rename .suo file (including extension). This file is at the same location where your solution file is. It worked for me.
Just guessing, but perhaps some of your other projects references your project from the wrong location? In this case, you have not just to delete and re-insert the project into your solution, you will also have to delete and recreate the references from the referencing projects (stored in their .csproj files).
After trying many recommendations I deleted the suo file ( again ). The last time worked. Why it did not work earlier I do not know. In general I find deleting the suo file one of the first steps I do.
I had my asp.net website solution opened from my Dev Branch.
Then for some other purpose I opened same solution from Main branch.
I made a change to one of my .ascx.cs file in the dev branch and set breakpoint. When I ran the debugger, all my break points were hit in the Dev Branch except for the .ascx.cs which was hitting the Main branch. Have not idea.
Tried cleaning the Temporary folder but didn't work.
What worked:
Closed all instances of Visual Studio
Opened the solution from Dev branch again.
Run again and the break points started hitting.
In my case i copied the *.sln file into the project folder and changed the path to project into the *.sln file. Only this resolved the problem (vs 2015 sp1, winservise project).
Delete *.suo does not helps for me.
Yet another solution worked for us - after trying the delete of suo and almost everything mentioned in this thread. We had a project in the solution which was showing a ghost version of the csproj file. We deleted that file and our paths fixed on another project we were trying to add.
Deleting obj and bin files would solve the problem...
I know it is an old line. I just went through the same problem. We recently migrate the TFS, so I created a new workspace to map to new server and kept the old one. Every time when I open a solution which is supposed to target to my new workspace, VS always tried to load projects from my old mapping directory, till I removed my old workspace.
In showing a colleague how to use SVN yesterday, we created a test folder and file within our existing Visual Studio Solution. We'll call it "Test" folder with two files, "Test.ascx" and "Test.ascx.cs". We added it (or Visual SVN added it, 'cos it's awesome), and committed it. We also added and committed other files elsewhere in the project.
We can see it in the repository (and the other files).
Doing an update on my own machine to pull down these new files resulted in the other files being pulled down correctly, BUT the Test folder does not appear. No matter how many times I try Updating from various points in VS and in TortoiseSVN (urgh) Repo browser, it can't see that there are any changes to pull down.
Where am I going wrong?
This is a known problem.
You can use
$ svn update --depth=infinity
to force the update. With TortoiseSVN, use the "Update to revision" command in the Submenu, then change the depth combobox to "fully recursive".
I've had ghost errors like this before and found the easiest work around is to delete the parent folder and update it's parent:
Project Root
Project
NewFolder
Delete Project, then Update Project Root
We can see it in the repository (and the other files).
...
No matter how many times I try Updating from various points in VS and in TortoiseSVN (urgh) Repo browser, it can't see that there are any changes to pull down.
So you can or cannot see it in the repository browser?
Did you commit and update the parent folder of your Test folder?
I don't know, svn is always telling me to clean, did you try that?
It's not an answer, I know, but I have tried all the solutions you guys have kindly suggested and I just end up with conflicts, crashed TortoiseSVN and built up Karma. Therefore, a trusty edit in the .svn/entries file sorted it.
I have until now been a single developer using SVN just to manage my source code. Other people don't have problems, and I just check in stuff. I use Visual SVN as a layer to frig SVN for .NET (which it isn't great with) and I seem to constantly run into issues. I am performing very simple operations, not even branching/tagging. Simple simple simple. And yet I have issues with it?
Recently I started to get this message randomly:
Metadata file '...\Release\project.dll' could not be found in Visual Studio
I have a solution with several projects in it. The current build mode is Debug and all projects' configurations are set to Debug. But when I try to run the main project - sometimes it gives me a few errors, all of which are "Metadata file '...\Release\projectX.dll' could not be found" - and, look, it says about RELEASE folder, though current mode is Debug. Why? I tried to search for reference to "Release\projectX.dll" inside all solution files, and I found one in ResolveAssemblyReference.cache file.
I made a good search over the Internet and found a few people with a similar problem, but there was no solution, or at least no working solution.
I tried to delete references to those projects and read them, but in some time I start getting these errors again.
It seems like a bug. Why does it search for referenced projects in Release folders when I always use Debug mode?
PS. For those who met this problem: I couldn't solve it in an easy way. It disappeared only after I reinstalled Windows :(
Everyone is correct...try everything...(in order of a little to a lot of time wasted)
Do you have bad code? Fix that first.
Clean Solution & Restart Visual Studio
Remove / Add References
Check your build order w/ larger projects and verify
Manually rebuild sub-projects
Manually copy dlls between projects into associated bin folders
Go get some coffee, play some pinball and come back tomorrow...you may think of something else in the meanwhile.
I had the exact same problem. Big visual studio solution with 50+ projects.
All references were added as projects.
Project build order was correct (right click on project and select build order).
However when building some of the higher level projects the "root" project they depended on were not built.
The problem was that these projects were not selected to build under the current configuration (don't know how this happened).
To check this select "Configuration Manager" (Build menu) e check if the problematic projects are set to build.
When you say you deleted references to those projects and re-added them, how did you re-add them, exactly? Did you use the "Browse" tab in the "Add Reference" dialog in Visual Studio? Or, did you use the "Projects" tab (which lists neighboring projects in your solution)?
Edit: If you use the "Browse" tab, and manually add the reference to your .dll that is located in the /Release folder, then Visual Studio will always look for the .dll in that location, regardless of what mode you're currently in (Debug or Release).
If you removed the actual .dll file from the Release folder (either manually or by doing "Clean Solution"), then your reference will break because the .dll does not exist.
I'd suggest removing the reference to ProjectX.dll, and add it in again--but this time, use the "Projects" tab in the "Add Reference" dialog. When you add a reference this way, Visual Studio knows where to get the appropriate .dll. If you're in Debug mode, it will get it from the /Debug folder. If in Release mode, the /Release folder. Your build error should go away, and you also will no longer be (improperly) referencing a Release .dll while in Debug mode.
Well, my answer is not just the summary of all the solutions, but it offers more than that.
Section (1):
In general solutions:
I had 4 errors of this kind (‘metadata file could not be found’) along with 1 error saying 'Source File Could Not Be Opened (‘Unspecified error ‘)'.
I tried to get rid of ‘metadata file could not be found’ error. For that, I read many posts, blogs etc and found these solutions may be effective (summarizing them over here):
Restart VS and try building again.
Go to 'Solution Explorer'. Right click on Solution. Go to Properties. Go to 'Configuration Manager'. Check if the checkboxes under 'Build' are checked or not. If any or all of them are unchecked, then check them and try building again.
If the above solution(s) do not work, then follow sequence mentioned in step 2 above, and even if all the checkboxes are checked, uncheck them, check again and try to build again.
Build Order and Project Dependencies:
Go to 'Solution Explorer'. Right click on Solution. Go to 'Project Dependencies...'. You will see 2 tabs: 'Dependencies' and 'Build Order'. This build order is the one in which solution builds. Check the project dependencies and the build order to verify if some project (say 'project1') which is dependent on other (say 'project2') is trying to build before that one (project2). This might be the cause for the error.
Check the path of the missing .dll:
Check the path of the missing .dll. If the path contains space or any other invalid path character, remove it and try building again.
If this is the cause, then adjust the build order.
Section (2):
My particular case:
I tried all the steps above with various permutations and combinations with restarting VS few times. But, it did not help me.
So, I decided to get rid of other error I was coming across ('Source File Could Not Be Opened (‘Unspecified error ‘)').
I came across a blog:
http://www.anujvarma.com/tfs-errorsource-file-could-not-be-opened-unspecified-error/#comment-1539
I tried the steps mentioned in that blog and I got rid of the error 'Source File Could Not Be Opened (‘Unspecified error ‘)' and surprisingly I got rid of other errors (‘metadata file could not be found’) as well.
Section (3):
Moral of the story:
Try all solutions as mentioned in section (1) above (and any other solutions) for getting rid of the error. If nothing works out, as per the blog mentioned in section (2) above, delete the entries of all source files which are no longer present in the source control and the file system from your .csproj file.
I've had this problem before and the only way I've found to solve it is to run Clean Solution and then restart Visual Studio.
For me it's usually the target framework being off (4.5.2 instead of 4.6) If you fix the target framework of the project to match the target framework of the solution and build, a new .dll will be created.
Re-open Visual Studio as Administrator.
Most of the answares say that you need to remove the libraries of your solution, this is true but when you re-add the libraries the error will be shown again. You need to verify if all the libraries referenced have a compatible .net framework with the .net framework of your solution. Then fix all the errors in your code and rebuild the solution.
Did you check the Configuration manager settings? In the project settings dialog top right corner.
Sometimes it happens that between all the release entries a debug entry comes in.
If so, the auto dependency created by the dependency graph of the solution gets all confused.
I've also seen this error in solutions where I have multiple projects (usually netTiers projects where I've updated one or more of the sub-projects to target the 4.0 framework). It can be problematic to remove. Oftentimes it can be resolved, however, by first fixing all other errors in sub-projects (eg, any missing references), individually rebuilding those sub-projects, then removing/adding back any references to those sub-projects in Visual Studio. Personally, I've had little luck resolving this error by cleaning the solution alone.
We recently ran into this issue after upgrading to Office 2010 from Office 2007 - we had to manually change references in our project to version 14 of the Office Interops we use in some projects.
Hope that helps - took us a few days to figure it out.
In my case it was caused by two things (VS.2012):
1) One of the projects was configured for AnyCPU instead of x86
2) A project that was referenced had somehow the "Build" checkbox unchecked.
Do check your Build | Configuration Manager to get an overview of what is being built and for which platform. Also make sure you check it for both Debug & Release as they may have different settings.
In my case, I had some errors in my code. Visual Studio showed the error you had instead of the actual errors, like syntax errors or unknown class names. Try cleaning the solution and building project after project. This way you will discover the actual errors.
Again, this is just what cause the error for me.
I had this problem and took long while to figure it out. Problem came up when I removed projects from solution and replaced those with nuget packages.
Solution seemed to be fine but the .csproj file still contained those projects multiple times as reference.
Seems that VS does not clean that file appropriately. It was still referencing the removed projects under the hood. When manually removed the references from csproj file all works again! wohoo
This problem is due to pdb files or CodeContracts.
To resolve it:
Clean your output folder and rebuild the solution.
Re-Configure the CodeContracts or disable it for temporary build.
We have that problem quite often, but only with references to C++/CLI projects from C# projects. It's obviously a bug deep down in Visual Studio that Microsoft decided not to fix, because it's 'too complex' and they promised an overhaul of the C++ build system which is now targeted for Visual Studio 2010.
That was some time ago, and maybe the fix even went into Visual Studio 2008; I didn't follow up on it any more. However, our typical workaround was
Switch configuration
Restart Visual Studio
Build the solution
I had the same problem myself.
Visual Studio 2013 only told me that it couldn't reference to it, and it couldn't find the metadata. When I opened my solution (which has multiple projects in it) it said that I was using projects lower than the framework version of one of my projects.
So I switched everything to version 4.5, and it worked again.
I seem to recall having a similar problem a few months ago. I solved it temporarily by copying the referenced DLL to the Release folder, thus satisfying Visual Studio's expectations. Later, I discovered the reference to the Release DLL in my actual code. You should try doing a search through the entire project for \release\project.dll.
Also, I have noticed that Visual Studio unit test projects sometimes put a "DeploymentItem" attribute on each of the test methods pointing to your target DLL, and if you switch between Debug and Release, Visual Studio can get confused if the DLL is no longer in the expected location. In my experience, these attributes can be safely deleted if you didn't put them there yourself as part of a "single deployment" scenario.
I had this problem and it was due to an invalid method in the offending library (dll) that did not return a value, e.g.
public bool DoSomething()
{
//I never bothered putting code here....
}
When I commmented this out everything compiled :)
Sometimes VS2010 switches my configuration from Any CPU to Mixed Platforms. When this happens I get this error message.
To resolve it I switch back to Any CPU:
1. Right click on the solution and select properties.
2. Click on Configuration Properties and then the Configuration Manager... button.
3. Under Active solution platform select Any CPU
I find that this usually occurs to me when i still have a method declaration in an interface, which a class implements, but that i had later removed and had forgotten to remove it from the interface as well. I usually just save the entire solution every 30mins n then just revert back to an earlier version if i cant find the error.
I ended up deleting my references (I had added them properly using the projects tab, and they used to build just fine), hand editing my .csproj files and removing bizarre entries that didn't belong -- and setting my outputs for debug and release, x86 and x64 and any cpu to all be "\bin" -- I built it once, then re-added the reference (again, using the projects tab), and everything started working again for me. Didn't have to restart Visual Studio at all.
For me this was caused by the Build target having been rewritten to not output the dll. Removing this to fall back on the default Build target fixed the issue.
For me was to remove/delete entire .vs folder(that is an invisible one) and then:
- Build
- Rebuild
and done.
in my case i was working on a branch off master. so i checked out master branch, ran a build and then checked out my branch. It fixed the issue. If you already are on master, i suggest you check out previous commit and then build it.
It seems to happen when you checkout a solution with multiple projects that have references between them, and you haven't built it before. If you have references directly to the dlls, instead of referencing the project, you'll get this message.
You should always use the Projects tab in the Add Reference dialog to add a reference to a project in the same solution. This way, VS can know the correct order in which to build the solution
same happened to me today as described by Vidar.
I have a Build error in a Helper Library (which is referenced by other projects) and instead of telling me that there's an error in Helper Library, the compiler comes up with list of MetaFile-not-found type errors. After correcting the Build error in Helper Library, the MetaFile errors gone.
Is there any setting in VS to improve this?
I had the same problem. I noticed that my db context (EF4) that was located in the project dll wasn't recognize for some reason. I deleted it and created another one instead. and that solved it for me.
Had the same problem today.
My application, a Windows Forms applications, accidently had a reference to itself. Weird.
Once removed, the error went away.
The reference got added each time I dragged a user control, located in the Windows Forms project itself, to a form.
I had the same problem. Manually removing and adding the dlls did not help. ClassLibraries did not compile for all the projects and were missing in the ...\bin\Debug folder for the project [because I cleaned solution by mistake]. Since the class library did not compile that means there may be some errors somewhere in one of those sub projects.
Solution: Since my dlls were there for the ...\bin\Release folder, I tried to rebuild on Release mode and found an error on one line in one of the sub projects. Solving the error and rebuilding the solution got rid off the build error.