Related
I have a large solution with many project. We have about six developers working on this solution using VS2013 and it is source controlled by TFS 2013.
Periodically project references and file references to DLLs are broken. The little yellow sign with the black exclamation point shows next to the reference in the project references and when I look at the properties of the broken references, I noticed that the path was empty for the elements that are broken.
I could remove and re-add the references, but I have done this a few times before and it keeps breaking again.
I Googled around and found several people talking about similar issues, but in most cases I see, after removing and adding the references, everything is ok.
I my case, this keeps happening over and over.
Is there a known cause for this? I can keep re-fixing this, but it's just a workaround and not a solution.
Assuming ProjectFirst generates the DLLs for ProjectSecond, to narrow down the issue, you can first build the ProjectFirst and then build the ProjectSecond to see whether the behavior correct. If that works, you probably need to check your build order.
In Solution Explorer, select a project or select the solution. On the Project menu, choose Project Build Order to check the build order.
On the Dependencies tab, select ProjectSecond from the Project drop-down menu. In the Depends on field, select the check box of ProjectFirst that must build before this project does.
Additionally, check ProjectSecond to see whether it by default to targeting .NET Client Profile. If it is, change it to regular .NET.
We have a solution with hundreds of projects (> 400) and tens of thousands of source files and for some unknown reason a set of updates got applied to the machine right in the middle of a build, killing the build and closing Visual Studio. When VS was reopened some projects did not load (even after close and re-open) so had to sort through > 400 projects and find those that did not load and manually tell VS to reload the missing/not loaded projects. After that things seem back to normal.
I hope someone else has encountered this because its driving me batty.
I recently got a new laptop so I've been setting up my Visual Studio solutions (VS2010 with .NET 4.0) that I saved off my old machine. One of them is a simple console app that I use to simulate some things for testing. It references 2 assemblies that I have in another solution that I am working on now. This used to all work fine as expected but ever since moving to the new machine I get the dreaded "The type or namespace name 'YourAssembly' could not be found (are you missing a using directive or an assembly reference?" error message. The references are clearly shown in the Visual Studio but when the project builds it does not copy them to the bin directory which explains the message. Initially I was just referencing the dlls the way I would any 3rd party dll but I even tried removing that and including the project files in my solution and referencing them that way and still it fails. I've verified that the dlls have their 'Copy Local' property set to true and they do. Its really bizarre because the project references several other dlls that are just 3rd party assemblies (for example NLog, GData, etc) and those all copy over fine but not these two for some strange reason.
Here's one more piece of oddness. If I add some code to the console app that references my assemblies it says it can't find it. If I then re-add the assemblies to the references, the error disappears until I try to build it again and then it returns. Is this a VS bug or what? I've never seen this kind of odd behavior before.
thanks
One case that I have seen that caused the problems you are talking about:
Including references to dlls that are built in-house, linked to a specific version of the dll. Get a new copy of the dll (with a different version number) and the build breaks.
The solution in this case is to set the DLL reference property Specific Version to false. The version of the dll is ignored (in my case, it is safe to ignore it), and the build works properly.
I've also had weird errors like this where the NTFS permissions were set on the old file with an old login, but the new machine didn't like the old permissions.
Also, sometimes the old .sln or .csproj file refers to an odd file path that you can't seem to edit from within VStudio. Try opening those files with notepad and make sure the paths aren't broken. You can usually edit and save with fixed paths and things will work again.
Hans had the answer above but I was unable to find that post through searches so hopefully if you stumble upon this question I can save you several hours of frustration.
For some bizarre reason the 'Target Framework' was defaulting to ".NET Framework 4 - Client Profile" in the project properties. I double checked and it seems to do that whenever I create a new console app. It must be version related thing in VS because I hadn't encountered this issue previously in 2010.
To fix:
Right click on your project, choose properties
Under the main Application tab, set the Target Framework to be your framework of choice but NOT one of the 'Client Profile' options
Save and build as normal
I have a simple Silverlight program that displays a bunch of images. I modified it do display more images, but it when I hit "run without debugging" is keeps running the old build with fewer images. When I copy the code into a new project and run it, it works fine for the first time, but then each subsequent change is not displayed. What could be the problem? I'm using Visual Web Developer 2008 Express.
Always check "Configuration Manager" option on "Build" menu in Microsoft Visual Web Developer. The checkBox "build" has to be checked, otherwise it won't build.
Happened to me, I hope this helps others.
I just had this happen to me in VS 2013 for Web. Had to change the Project URL in:
"Project properties"
"Web" tab
"Servers"
To a different localhost number and recreate Virtual directory.
Before my Project URL was:
http://localhost:55487/
I changed it to:
http://localhost:55488/
Then clicked "Create Virtual Directory".
Would like to know why this happened in the first place.
I found that I had to close all open instances of Visual Studio before I got it working again
This happens because your cache memory is full. just go to you bin and obj folder and delete all the temporary files. Now it will run properly.
Maybe it's a caching issue (webbrowser / proxy).
To fool the browser try to embed the xap file with an additional parameter that changes every time you open the plugin:
<param name="source" value="ClientBin/BubuApp.xap?<%=Guid.NewGuid().ToString() %>"/>
If this don't help, try to clean the project (delete obj / bin folders & xap file).
I was also suffering from this issue and none of the suggestions worked. I was building a Office.js add-in and debugging was with IIS Express.
What fixed the issue for me was deleting files in
C:\Users\<user>\AppData\Local\Temp\Temporary ASP.NET
Actually, I went ahead and and deleted the entire C:\Users\<user>\AppData\Local\Temp folder out of spite :)
I also had this issue and while some of the fixes above helped temporarily, the one that worked for me was to remove the history and caching in Internet Options.
Go into Internet Option (also available in VS via Tools > options > Environment > Web Browser > Internet Explorer Options).
On the General tab click Settings in the Browsing History section.
On the Temporary Internet Files page select Every time I start
Internet Explorer
On the History tab set the Days to keep history to 0
On the Caches and Database tab make sure Allow website caches and
databases is NOT ticked.
I'm not sure if all of the above are required, but I've made a number of changes to files and so far they have been reflected straight away in the dynamic versions without any noticeable performance problems.
I've also since realised if I set 'Every time I visit the webpage' instead of 'Every time I start Internet Explorer' I don't have to stop and restart the project to see the changes. Which is how it should be!
I used to suffer this. All of this used to be (for me) a folder's contents issue.
Maybe you can check this:
Delete %windir%\microsoft.net\framework\v4.0xxx\Temporary
IIS Express: even if you change the output file for compiled results, you will see in applicationhost.config that many times IISExpress is really "looking" to the default bin folder of your project.
It is even possible that you have different configurations for Debug or Release, so maybe IIS is looking BIN with Release code, and you are now compiling in Debug to another folder, do you understand me?
Happened to me too. Well i dont know the exact reason for this behavior. But when i close the visual C express 10 and then open again and build it builds the new saved file. I guess it still hangs on to the old file when there is an error in some debug mode or something.
Stop all incntance of VS.
Delete all /bin, not just /bin/Debug. All /bin
Remove user option .suo file in solution dir. It will create on self.
Remove all restore windows point
Stop IIS.
6 Start IIS after 1 minutes.
Rebuild solution, Buid projects
It happing on me too. Very nasty. You may restart your computer.
Check for global asembly dll.
Just delete folder 'Release' in project with old code build.
I had the same problem and none of the answers were working for me. It turns out that building the ASP.Net project did not build the Silverlight project, so running without debugging didn't update the Silverlight.
Fix: Right click the Asp.Net project. Build Dependencies > Project Dependencies. Check the Silverlight project. Now building should work.
If this is a web application, change the Project URL with a new port number.
Example :
Change from http://localhost:3688/
To http://localhost:36881/
To do this:
Navigate to Project properties -> Web
Change the URL
Hit "Create Virtual Directory"
Finally, Build and RUN
I had this issue in a web site.
The site referenced 1 of the projects in the solution, and changes to it would not reflect in the debug.
Issue was a third project was referencing an outdated dll of the same same referenced project.
I removed the project and all references in other projects and readded and re-referenced everything and it worked fine.
Check you haven't got two versions of whichever file you're updating (one for one group of users, one for a different group of users).
In my case(VS 2015) it was because of the missing dll in the .exe directory... I made a "clean solution", then additionally deleted all bin and obj folders' contents. Reason to do so was VS keeping to load old dll build. Solution was to select folder of the running debug config, i.e. everytime I rebuild project destination location with dll and a reference to it stays with warning mark for some time until intellitrace does its job. After doing the setup mentioned above, I still have to do a manual rebuild on a project that generates a dll into specified dir. Pressing F5 does nothing, I don't have time to find out why... Main thing is its working for me
I had this recently too and I didn't see the answer here. I was changing an MMI to get rid of redundant buttons, and they didn't go away.
Really old legacy code. To make it keep user settings - like language - someone had made it keep the Settings. I was not allowed to change this, they want it like that.
To get rid of the old settings and allow new ones:
open regedit
navigate to HKEY_CURRENT_USER - Software - MyProject - SubProject
here you see Recent File List and Settings.
Delete Settings completely - don't worry, it will make a new one.
Please check is there any old .tlb file present in someother folder. In my case i was using the .tlb file generated using .NET dll and then created the .tlb file using RegAsm. I tried to use the .tlb file in vb6 code, it still refers old code only. After a long search i found same .tlb file older version found in Visual Studio\VB98 folder. I removed it then it worked fine. This may not be relevent for this issue but could give you another way of thinking
There is a scroll bar at the top which has 3 options:
debug
release
configuration manager
Make sure release is selected.
I had to clear browsing data and it worked in my case
I'm unable to debug a WinForms C# application using the released version of Visual Studio 2010 Prof.
I get the following error message after the second debugging run.
Error 9 Unable to copy file "obj\x86\Debug\Arrowgrass Reports.exe" to "bin\Debug\Arrowgrass Reports.exe". The process cannot access the file 'bin\Debug\Arrowgrass Reports.exe' because it is being used by another process.
I've tried a pre-build script to attempt to delete this file, but it's locked by Visual Studio.
There are a few references to this on the net so it is a know problem. Does anyone have a hotfix or effective work-around?
I have found this issue very easy to reproduce, and the fix for me is a variation on Richard Fors' answer. If I have a UserControl open in the designer, run the debugger, and then edit the UserControl, the subsequent rebuild will fail. If I close the UserControl before running the debugger I never get this error, so I just make sure to close the designer window before hitting F5.
As of October 2012, I still have that issue so the VS 2010 SP1 didn't solve the problem. What I did, and worked consistently, was disabling the hosting process in the projects.
To disable the hosting process:
. Open a project in Visual Studio.
. On the Project menu, click Properties.
. Click the Debug tab.
. Clear the Enable the Visual Studio hosting process check box.
Source:
http://msdn.microsoft.com/en-us/library/ms185330(v=vs.100).aspx
You can try to kill the vshost.exe process:
taskkill /F /IM "Arrowgrass Reports.vshosts.exe"
You might also be lucky and simply be able to move the file in question. Moving the file can be done by adding the following lines of code to the pre-build event of your project:
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"
Disabling windows search did not fix for me. However disabling Antivirus did (our Antivirus is Symantec Endpoint Protection 11)
As such, I was able to fix this for myself by changing the Debug settings in the project to point the working folder to a path on the C: drive, and then excepting that path from the antivirus auto-protect scan settings.
I hope this helps someone.
I posted this answer in a similar question but figured I'd also say it here:
Alright... this might sound pretty crazy.
I've had this problem in VS2010 for the last couple of years. The workaround mentioned here works for me, but a lot of times I forgot to close all my forms/usercontrols first.
I've discovered that merely going to view the open files via:
Computer Management (compmgmt.msc)->Shared Folders->Open Files
will "Free up" whichever file is being locked. Very strange, but it works for me!
In my case, I did Project Properties-->Security Tab-->Uncheck Click-Once security settings (If it is checked). It worked for me. In my project, it was showing this error for a C++ dll being used in my C# project.
The condition described can also be caused by the offending DLL or EXE referencing itself; in which case the Process Explorer test described previously never returns a match (e.g. it's not running). This unexpected situation seems to be caused during some sequence of operations in VS2010 (and likely all previous versions) which insidiously adds the reference behind the scenes. The specific cause of this hasn't been tracked down (or resolved that I know of). To check for, and resolve this error simply make sure the offending DLL or EXE is not listed as a reference to itself.
Got the error ("The process cannot access the file … because it is being used by another process") when I modified the (Visual Studio 2010 C# Express with SP1) solution from two large (10 source files, ~500 lines per file) projects with one referencing the other, to lots (6) of smaller projects with lots of projects referencing other projects.
The references were to the dll- and exe files (the Debug versions of them), NOT to the projects even though the projects were in the same solution.
I then learned that references should be to projects, not files, for F12 to work properly. So I modified the references. That made F12 work (jump to the source file instead of some auto-generated interface description), and at the same time the "cannot access file" error during build disappeared.
I only got the "cannot access file" error when doing Release builds. The references were to the Debug versions of exe/dll's. I suspect that this mixing is what triggers the bug in VS.
I encountered this issue when developing windows services. I found out that it happens when the service is running. Thus, you only need to stop the service (from the services.msc console) and you're good to go !
Hope this helps.
Tidjani.
Check Task Manager for the specified process and End the process explicitly. This solution worked for me.
I cant' write to a comment since not at 50 points but for me I excluded my project folder in ESET Enpoint Security ver 5. Seems like it blocked/hogged some files. My Error did not state which exe or file was in use so it took a long time to finally get to what JoeC said about Antivirus and tried it. Seems to be working now (Visual Studio 2010 SP1)
Closing recently changed User Controls solved the problem in my scenario. Hope this will help somebody out there.
Looks like this issue has (finally!) been fixed in the VS2010 SP1
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=75568aa6-8107-475d-948a-ef22627e57a5&displaylang=en
Please try uninstalling Windows Live SYNC. Does it still happen?
I think I just found the culprit and the solution.
Go to services and stop & disable the "windows search" service.
That solved the problem for me now.
For me the solution was to change the startup project to a dll (problem only occurs in debug mode when having an application as the startup project). If your solution contains several projects (and it will, and it will contain a .dll, else you would not get the problem), switch to that .dll, no .vshost.exe, no problem.
Also, killing .vshost.exe did not work for me, since immediately after starting again, it had locked the .dll.
Also, make sure to have your references clean, especially in more complex projects, and also prefer project references to assembly references, and so on. I suppose bad references (circular and similar) are bound to cause problems, at least so I have read.
A short article by me on this problem (and my solution)
How to "clean up" your references in a solution
Adding the following to the Pre-build event of the shared dll worked for me:
if exist "$(TargetPath).locked*" del "$(TargetPath).locked*"
set exitprebuildfor$(ProjectName)=
for /l %%a in (1,1,10) do (
if defined exitprebuildfor$(ProjectName) goto :ok
if not exist "$(TargetPath).locked%%a" if exist "$(TargetPath)" move "$(TargetPath)" "$(TargetPath).locked%%a" & set exitprebuildfor$(ProjectName)=1)
:ok
set exitprebuildfor$(ProjectName)=
It's based on the solution given here but instead of just renaming the dll to .locked it keeps trying to rename it to .locked1, locked2. Using 10 I usually run into the problem once a day, but ant value can be used.
Simply make a copy of the whole project and run project from the new copy.... it will work fine.
But you will have to end process of the debug somehow in-order to delete the older project.
Stop IIS service and try building it again or if you can afford to restart your pc, give it a try. Worked for me both ways.
Cheers
My problem was that Outlook 2010 (outlook.exe) was using the same port as my ASP.NET MVC project with IIS express.
Solution: close outlook.exe, run your solution and open outlook again (so that it uses another port).
Hopefully this helps somebody, because I received the same error message as described in this topic.
Try deleting .exe file in debug or release folder (whatever you working on)
Windows will prompt that the process X has opened this and you can't delete it
after that go to task manager and in details tab end task X process
Delete obj file.And stop your service and Restart again.Then you may solve the problem
The best solution for me was to move my project files out of My Documents - which is on a server managed by the IT department - and locate them locally on my C drive. Also working: unchecking the "Enable the Visual Studio hosting process" checkbox, as stated by other people.
If you are working on a C# project which is using reference of C DLL, then you can eliminate the error by checking the Allow unsafe code check box. I know I have not used pointers in my C# project but I was using some bitwise operator in C#. May be these C-like features morphed it as 'Unsafe' code.
What worked for me was removing "read only" status on the bin folder. Once I did that, it has worked ever since.
I've had this error when the project is on a remote share (like, if your $env:homepath is helpfully redirected by your IT department to a network share). Make sure your project is resident on a local drive.
My problem started after creating a custom control and drag and drop it to the toolbox palette for use it in design forms. First appeared a warning saying that there was a redundance between the custom control source file (.cs) and the projects executable (.exe). On executing/debugging appeared the error: unable to access the (.exe) because it's being used (and it was true).
A literally removed the whole source code regarding the custom control and last problem never stopped, until I checked out the references and it was referencing itself in order to be "able to" get the former custom control. I removed the reference and done!!
So: just check the references and remove the self-reference to the project.
Delete your Bin folder and run the application.
This worked for me. :)
Simply turn off Visual Studio hosting in debug, run the project and again re on it and run project.
Open a project in Visual Studio.
. On the Project menu, click Properties.
. Click the Debug tab.
. Clear the Enable the Visual Studio hosting process check box
For Windows Project
The Visual Studio hosting process can hold the executable file pointer. To stop the host instance, open the Project properties and then go to Debug tab. Now uncheck the Enable the Visual Studio hosting Process option and then check the checkbox again to debug.
For web project
The IIS can hold the file pointer. Restarting the IIS can solve the issue.
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.