I have what is basically a default ASP.NET Core 2.2 project created from the default Razor Pages templates.
Now, in solution explorer -> Dependencies there is a node called "Analyzers".
First of all, at first I had no idea what it was for. I think I know now but it's still kind of fuzzy.
Secondly, why does it have a warning icon? Same with its child nodes.
Note: I'm not under the "NuGet" node, so this is not a question about missing dependencies or anything like that.
And thirdly; why is this "feature" there if it's only there to confuse me?!
I had the same issue. After I restarted Visual Studio with Administrator privileges, Analyzers titles started to show the name instead of the path and the "warning" is gone.
EDIT
There is a GiHub issue about it.
A temporary fix would be to close the solution and to delete .dtbcache file in the .vs folder.
The warnings under each analyzer assembly are issues found in your code. Found by rules in those assemblies.
With the introduction of the Roslyn compilers it has become easier to analyse your sourcecode even before the compiler runs. These rules are packaged in special nuget packages. When these rules run they show in the error window and in this list.
If a rule misbehaves, or you want to turn it off or you want to look at just the MVC rules, this view is quite useful.
When analyzers themselves run into issues (some are not as good as others) the respective issues are also shown here. It looks like the RS* rules are actually issues with the rules themselves.
In my case, the warnings disappeared after I set net core 3.1 as target framework in project properties.
I've had the same issue. I think its because of the "C:\Program Files\dotnet" folder perssion.
you can open the visual studio by Run as Administrator or give the folder all permission in security folder. I did it and my proplem was resolved.
All my project (from the same solution) references are marked with a yellow triangle. The projects are all set to the same .NET version (4.5.1). The error log says:
The project 'CommonLibrary' cannot be referenced.
A way to temporarily fix the issue is to either:
Remove and re-add the references
Right click and choose Add Service Reference and immediatelly cancel.
However, the triangles come back every time I start the solution.
The solution is build successfully regardless or the issue. The real issue is that Resharper acts like the references don't exist.
Another thing that might be relevant is that I have 2 projects that are supposed to be unloaded but they become active every time I load the solution.
Any idea what to do with the issue?
I had similar issues and it usually comes down to the Target Framework (Project>Properties>Application). I was working on a solution using .NET 4.6 and for some reason the default framework for new projects have a different target (in my case it was 4.5.2). So make sure you check all your project at the very least have the same target framework.
Do the following:
In vs choose: tools->options->resharper->options-> general-> click the clear caches button.
then close all your opened tabs and shut down vs2013.
finally, start vs2013 again.
Let me know if that worked for you.
Try switching to managed compatibility mode in VS2013
you can do that by going to tools->options..->General tab and check the Use managed compatibility mode
I had the same thing happen but didn't suspect the 24 warnings I was getting was related to this error: Error 1 Unable to locate the .Net framework aspnet_merge.exe tool on path '~\Photo Archive\Main\etc\tools'. You need to set the msbuild property 'AspnetMergeToolPath' to the folder containing this tool. ODOT.PhotoArchive.Web
Trying to set the MS build property led to a lot of research just to find out WHICH property to set. So, Agent Ransack to the rescue -- searched my drive for the most recent version of the tool and copied it to the directory Visual Studio was complaining about.
Rebuilt the project with the idea of clearing the error but then the 24 warnings also disappeared.
FYI -- this is an MVC project which will replace a classic asp project. This might be peculiar to MVC projects.
At any rate, there was a lot of chasing snipes before this was finally tried. So, where this is happening, try handling any errors no matter how remote the possibility is they're related to the issue.
I had the same problem as you can see in this picture.
Its reason was the hidden folder. I had hidden the folder containing the project files. I got rid of this problem by unchecking the hidden attribute of the root folder containing the project files and restarting the visual studio.
Check it once, you might have checked the folder to be hidden.
while doing the build of my dontnet 4.0 project setup i'm getting following errors
An error occurred generating a bootstrapper: Unable to finish updating resource for E:\project\Setup\Debug\setup.exe with error 8007006E E:project\Setup\Setup.vdproj Setup
General failure building bootstrapper E:\project\Setup\Setup.vdproj Setup
Unrecoverable build error E:\project\\Setup\Setup.vdproj Setup
I am using dotnet framework 4 and MSVS 2010.
This happens because The .NET framework version required by the setup project is different than the .NET framework version targeted by the application.
To change verify this:
In Solution Explorer, click the Setup project.
On the View menu, point to Editor, and then click Launch Conditions.
Click .NET Framework.
In the Properties window, change the Version property to the version of the .NET Framework that you want the Setup project to check for and install.
And also you need to Make sure that the Setup.exe program also checks for and installs the correct version of the .NET Framework.
Right click on the setup project -> Properties -> Prerequisites -> Select the correct ones.
When I turn McAfee real-time scan off, it works. I spent 2 hours on figuring this out :(
I googled a lot on this issue after trying all i just disabled my antivirus(NPAV) and this issue was solved.
turning off mcafee real time scanning worked for me as well on Windows 8.1
Here is yet another solution, this one is unlike the rest...
We recently added NTFS replication to our build tree root to provide some additional data redundancy and to begin to sync our old build machine with the new server. The NTFS replication caused some projects to fail with the exact same three error reported, and yet other projects work just fine. Set the replication on only run at night and the problem stopped occurring...
K
I got the same error when I changed targeted framework to 4.0 but neglected to change prerequisits for click once from 3.5 to 4.0 as well.
Fixing prerequisits resolved the problem.
Instead of disabling the Anti-Virus, I would suggest to just create an exclusion for your Solution Folder. See documentation if you are using Windows Defender. Microsoft Support
I've just had this same error and then realised Dropbox was running. I closed Dropbox and then the build completed successfully.
Thank you qwerty13579! How stupid of me, the solution is obvious. I have tried all sorts of things suggested over the internet, and even with the most recent version of VS Community 2017 (15.9.9), the bootstrapper failure pops up erratically, but with increasing frequency, to the point of frustration this past week. The principle: It doesn't succeed reliably, so it also doesn't FAIL reliably. The solution: Click the Publish Now button and watch the output panel. When it's that clear that it's failing, click the Publish Now button again immediately. Keep at it until it succeeds! Each round only takes a couple of seconds, much less time that it takes to re-build, take down anti-virus, and all that fancy stuff.
In my case, I traced the problem to an incorrectly dated setup.exe file in the bin\Release\app.publish folder of my application. When it fails, Publish Now creates an setup.exe that's two years earlier than the current day. When it succeeds, the setup.exe file is correctly dated.
Got the same problem. I disabled Windows Defender real-time protection and it worked. I also added the folder where the solution is saved in exclusions for Defender, and that allowed me to publish as well.
I have a problem which has received plenty of attention which, despite much googling, I have been unable to resolve. I have a Test Project attached to my Visual Studio 2010 MVC 2 Application. When I attempt to run my tests, I get:
"no tests were run because no tests are loaded or the selected tests are disabled."
Following this, I followed the instructions in these posts, to no avail:
MSTest: No tests are run because no tests are loaded or the selected tests are disabled = my GUIDs are right, and the assembly IS being built - I can see the file in explorer.
MSTest Not Finding New Tests = reopening the solution & rebuilding didn't result in any change
http://richallen.blogspot.com/2008/05/ms-test-re-enabling-ignored-tests.html = the tests do not even appear in the test list browser under "loaded tests"
Furthermore, the output console reports:
"Could not load file or assembly 'file://\shared\shared\IT\Development\TPS\TPS.Tests\bin\Debug\TPS.Tests.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)"
I have confirmed the build settings on the Test Project are the same as those for the main project (Any CPU targeted).
Therefore, is it a problem accessing the resource over network share? Otherwise, does anyone have a suggestion?
If you want to continue using a network share to host assemblies in .NET 4, you can change a Visual Studio configuration option to grant those assemblies full trust. You need to edit C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe.config and add the following line:
<loadFromRemoteSources enabled="true"/>
To the configuration/runtime element. This is described in (slightly) more detail at http://msdn.microsoft.com/en-us/library/dd409252%28VS.100%29.aspx. I would not recommend making this change without understanding the security implications of doing so, some of which are outlined in that MSDN article.
In general, though, I agree with the previous answer. Hosting Visual Studio projects on a network share is going to create a large number of problems for very little benefit.
Having your source code on a share is plain wrong (period) and will lead to all sorts of 'gremlins'.
Do yourself a favour, use Source Code Control and have a local copy of the source code. You will waste a lot less time, and as a bonus you will be able to track who changed what.
If you go with TFS, the Visual Studio TFS Branching Guide 2010 is a valuable resource.
If you use SubVersion, then the Red Bean Book is excellent.
I was running all local but still had the problem. I found that what caused it was removing an xml tag during manual editing.
add:
CodedUITest() inside of tag brackets
on the line immediately above your class where all your test methods are.
add:
TestMethod() inside of tag brackets
on the line immediately above your test methods you want to run.
build project and run.
I tried the following steps while encountering this problem and luckily the issue got resolved...
Close the solution and open the empty VS editor and Check out the testrunconfig file
Open the solution and under CodeCOverage column, uncheck and check the dll's available( these dll's would be having a warning symbol)
Rebuild the solution and now run the test cases.
Hope this resolves the issue... :)
I struggled with this for days, and didn't find the answer (for my situation) anywhere, so though I'd jot down my experience...
So I had the same problem, doing what I thought was local testing on a test project created locally.. (I'm a novice...) but returning the same error mentioned above : /
Anyway it seems that VS2010 had by default placed my project dir within the library folder, which was classified as network, subsequently all files within were 'unavailable offline'.
By moving my project dir to c:// my project files became index-able. (much to my relief!)
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.