I'm having trouble understanding a behaviour of Nuget. I've created a basic package that deploys a single Test.cs file into an "HtmlHelpers" folder in a project. I'm following the "convention based working directory" method described on the Nuget site.
The issue I'm having is Resharper file analysis isn't enabled for this file (the file doesn't compile currently, I've left off a semicolon):
But, if I rename the file from "Test.cs" to "Test2.cs" then Resharper analyses the file correctly showing the syntax error:
Has anyone got any idea what's happening here? Is there a list somewhere of Nuget-supplied source files that are then excluded from Resharper analysis? The file properties are the same as for any other C# file, set to Build Action "Compile" etc.
EDIT1
To answer questions from Stephen below, this is Resharper 8, I'm not currently on 9. I've tried closing and re-opening the solution and excluding and re-including the file, neither of which help.
Interestingly, with analysis working correctly on the renamed "Test2.cs", if I then rename it back to "Test.cs" the analysis switches off again :S
EDIT2
Just to add some more info to this, if you Nuget-deploy C# files using the .pp extension, Resharper analysis works correctly on the resulting .cs files. Go figure.
ReSharper excludes source code that has been delivered as part of a NuGet package from analysis - it treats it as third party code that you did not write and do not want to maintain. E.g. it won't show any inspection results for files such as jquery.js or angular.js - you don't own these, don't intend to maintain them as part of your project, and any changes you do make are likely to get overridden the next time you update the project. So, inspections are disabled for these files, but the files are still indexed to allow navigation.
Just in case anyone else has this issue it only happens if Nuget delivers a .cs file. If you get Nuget to deliver a .cs.pp file, Resharper correctly analyses the resulting .cs file in your solution.
I was new to Nuget when I started this work and it turns out I needed to make them .cs.pp files anyway in order to use the correct project namespace when importing. So the problem has gone away.
I have a sln with > 50 projects, and recently, when I moved to VS2013, every time I press F5 for a build, it will rebuild all the projects, even though I have just performed a build. The diagnostics show, that each project is marked as not up to date with the following error:
Project <PROJECT NAME> is not up to date. Missing input file 'c:\users\USER\appdata\local\temp\2\.netframework,version=v4.0,profile=client.assemblyattributes.cs
I have read these threads:
In Visual Studio 2010 why is the .NETFramework,Version=v4.0.AssemblyAttributes.cpp file created, and can I disable this?
https://social.msdn.microsoft.com/Forums/vstudio/en-US/15d65667-ac47-4234-9285-32a2cb397e32/migration-from-vs2008-to-vs2010-and-netframeworkversionv40assemblyattributescpp?forum=vcgeneral
but the suggestion there is to add the following line to the proj file:
<Target Name="GenerateTargetFrameworkMonikerAttribute" />
I did and it did not work. Suppressing the warning as MS suggestion will also not work as the project will remain "not up to date".
I am using VS2013, C# and VB projects. With the very same project and VS2012, such error is not raised and the projects are up to date.
Any suggestions?
UPDATE
Perhaps it is worth mentioning that I do have a few build definitions in the solution, where all of the projects are building for AnyCPU except one: http://screencast.com/t/fuw9k4IubN
I had the same problem and solved it by upgrading the ToolsVersion attribute in *.csproj files:
ToolsVersion="4.0" replaced with ToolsVersion="16.0"
(I’m using Visual Studio 2019, which is v16.x internally).
<Target Name="GenerateTargetFrameworkMonikerAttribute" />
Well, not a good idea, that accomplishes the exact opposite of the problem you are trying to solve. It forces MSBuild to create the AssemblyAttributes.cs file, inevitably your project needs to be rebuilt since the file is new. The Q+A you found addresses a completely different issue, these were C++ programmers that were trying to come to grips with a new linker warning in VS2010. They hate warnings that appear from nowhere from files that are not part of their project. Well, don't we all. The marked answer on that SO question is quite evil btw, that other guy posted a much better answer :)
Missing input file 'c:\users\USER\appdata\local\temp\2\.netframework...
There's a signal in this message, note the presence of the \2 subdirectory in that path name. That is a Big Red Flag, it is not normal. This auto-generated .cs file normally lives inside the TEMP directory, not a subdirectory of that folder. Surely this has something to do with your real problem.
MSBuild doesn't do anything special and simply uses System.IO.Path.GetTempPath() to generate the folder name. That method isn't special either, it simply delegates the job to the GetTempPath() winapi function. The diagnostic therefore is that on this build machine, that OS function sometimes generates an odd-ball path, picking a subdirectory of the TEMP folder. And that it doesn't always generate the same one, thus causing your projects to getting rebuilt.
There is at least one good theory for this behavior, mentioned by commenter #Darran Rowe to this blog post:
No, this is Terminal Services at work. When you log in over remote desktop, Windows will set the temp directory for the logon session to %LOCALAPPDATA%\Temp\<session id>
Rings a bell?
Try deleting the hidden .vs directry which is in the same folder than the solution file.
This worked for me
Close visual studio and Deleted the .sou files from the projects
I was getting the same error and I solved it by removing the project from my solution and re-adding it. It is a pain because then you have to add the inter project references back in.
I am having issues with check in my code files because of some changes I have made to the project and solution. I have renamed project files, added different project files in the solution and added many files in the existing project.
Now I am getting an error while checking in the code.
The error details are:
Check In: Operation not performed Could not find file
'....Console.csproj.vspscc'.
How do I create a vspscc file if it does not get created on its own?
Any help would be great and thanks in advance.
This looks pretty stupid on my part. I restarted my Visual Studio and I could perform the check in because Visual Studio created the vspscc file when it opened the projects and solution.
Answering my own question as fast as possible so nobody else prints my own negligence before me.
And for anybody who needs an answer as how to create a vspscc file, restart the visual studio IDE
I have also seen this in another situation (VS2012) where a simple restart didn't do the trick.
I had a number of new projects which I had added to an existing solution but in the wrong place. Undoing and re-adding seemed to be fine until check-in, where it complained that the newly added projects and related .vspscc files could not be found. It was looking for them in the original location rather than where they are now.
Resolution was to go to the Source Control Explorer, which still had check-in items against these files in their original (but non-existing) locations, as well as the files in their correct locations. Selecting these errant references and "Undo pending Changes" for these files did resolve the issue.
I'd try using File/SourceControl/ChangeSourceControl dialog and unbind (if necessary) then rebind the project to TFS to recreate the .csproj.vspscc.
I removed projects and have same issue, so my solution was to re-create the same projects with same name, then remove them cleanly :-) I hope this helps
I had a similar problem, but in my case I Visual Studio/TFS couldn't fine the .csproj file. Anyway, with the help of a colleague I was able to determine that the issue was within TFS itself. TFS may have a different view of your source code than Visual Studio does. I had created the wrong type of project (I'll call it Proj1) and deleted it from within VS. Then created the correct project type, which I'll call Proj2. When I when to check it into TFS it complained about Prog1.csproj, which confused me because I couldn't see it within VS. What I learned was that you have to go into TFS's Source Control Explorer. From there you'll see how TFS sees things. Sure enough, there was Proj1.csproj (and some other related files to Proj1). What I had to do within Source Control Explorer was undo the pending check-in's of those files and folders which I didn't want to check in and no longer existed anyway. Then TFS was happy and I could perform the check-in.
I used to be able to debug using Visual C# Express 2010 with no problem before. However, since I've opened my project using MonoDevelop (to port it under MacOS), I can't seem to be able to debug anymore.
The exact error message is available below:
A lot of people says to go in the configuration manager, which I'm familiar with, however, I can't seem to find it in the Express version.
Since you didn't have this issue prior to opening in Monodevelop, it more than likely changed something within the solution and/or project files. There are a number of posts on stackoverflow...
stackoverflow: no symbols
stackoverflow: no symbols when crossing module boundries
(From Răzvan Panda comment on the question)
... that talk about missing symbols. However, based on the information provided about monodevelop, I'd venture to guess that the IDE changed something within the solution and/or project files.
If your solution is under source control and you don't see any differences in these files, let me know. Otherwise, you could create a new blank solution/project file (from Visual C# Express 2010) and re-add all your files to it to get the default settings back and see if that resolves your issue.
EDIT: Also, keep in mind that there are ".user" files that I guess "might" have an effect on build/debugging configurations. If re-adding your files to blank solution/project files doesn't work make sure all the "extra" files like ".user" are not in the directory. Usually files like ".csproj.user", and ".suo". I've never had an issue deleting these they store local configuration changes that are not usually checked into source control.
I had same problem with Symbols when I added some dll to my project so what I did was to manually adding them. you can try going to tools > option > Debugging > Symbols and from there you can add the file root (in this case monoDevelop) and it automatically looks for all .pdb files and adds them to your environment. After rebuild it should be Okay.
Cheers
As George Duckett said:
Re. configuration manager, enable expert settings first. Tools->Settings->ExpertSettings. Then find it under Build->ConfigurationManager
Then changed it to Debug.
I am working on a WPF, C# 3.0 project, and I get this error:
Error 1 Metadata file
'WORK=- \Tools\VersionManagementSystem\BusinessLogicLayer\bin\Debug
\BusinessLogicLayer.dll' could not be found C:\-=WORK=- \Tools
\VersionManagementSystem\VersionManagementSystem\CSC VersionManagementSystem
This is how I reference my usercontrols:
xmlns:vms="clr-namespace:VersionManagementSystem"
<vms:SignOffProjectListing Margin="5"/>
It happens after every failed build. The only way I can get the solution to compile is to comment out all my user controls and re-build the project, and then I uncomment the usercontrols and everything is fine.
I have checked build orders and dependencies configurations.
As you can see, it seems to have truncated the DLL file's absolute path... I have read that there is a bug with the length. Is this a possible problem?
It's very annoying and having to comment, build, and uncomment, the build is becoming extremely tiresome.
I just had the same problem. Visual Studio isn't building the project that's being referenced.
Written Instructions:
Right click on the solution and click Properties.
Click Configuration on the left.
Make sure the check box under "Build" for the project it can't find is checked. If it is already checked, uncheck, hit apply and check the boxes again.
(Optional) You had to do it for both Release and Debug modes on the solution properties.
Screen capture Instructions:
They say a picture is worth a thousand words. Click on the GIF to zoom in, and hopefully it will be easy to follow:
This can still happen in newer versions of Visual Studio (I just had it happen on Visual Studio 2013):
Another thing to try is to close Visual Studio and delete the .suo file that is next to the .sln file. (It will be re-generated the next time you Save all (or exit Visual Studio)).
I've had this problem when adding new projects to the solution on another machine and then pulling the revisions in, but the .suo file can be corrupted in other cases as well and lead to very strange Visual Studio behaviour, so deleting it is one of the things I always try.
Note that deleting the .suo file will reset the startup project(s) of the solution.
More on the .suo file is here.
The suggested answer did not work for me. The error is a decoy for another problem.
I found out that I was targeting a slightly different version of .NET and this was flagged as a warning by the compiler, but it was causing building to fail.
This should have been flagged as an error and not a warning.
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 four errors of this kind (‘metadata file could not be found’) along with one 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 Visual Studio 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 two 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 Visual Studio a 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 post: TFS Error–Source File Could Not Be Opened (‘Unspecified error ‘)
I tried the steps mentioned in that blog post, 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.
In my case it was caused by a .NET Framework version mismatch.
One project was 3.5 and the other referencing project 4.6.1.
Visual Studio 2019 this worked for me:
Close Visual Studio
Delete the hidden .vs folder
Reopen Visual Studio and rebuild the solution.
Closing and reopening Visual Studio 2013 worked for me!
Well, nothing in the previous answers worked for me, so it got me thinking about why am I clicking and hoping when as developers we should really try to understand what is going on here.
It seemed obvious to me that this incorrect meta data file reference must be held somewhere.
A quick search of the .csproj file showed the guilty lines. I had a section called <itemGroup> that seemed to be hanging onto the old incorrect filepath.
<ItemGroup>
<ProjectReference Include="..\..\..\MySiteOld\MySite.Entities\MySite.Entities.csproj">
<Project>{5b0a347e-cd9a-4746-a3b6-99d6d010a6c2}</Project>
<Name>Beeyp.Entities</Name>
</ProjectReference>
...
So a simple fix really:
Backup your .csproj file.
Find the incorrect paths in the .csproj file and rename appropriately.
Please make sure you backup your old .csproj before you fiddle.
In my case, I have my installed directory in mistaken ways.
If your solution path is something like "My Project%2c Very Popular%2c Unit Testing%2c Software and Hardware.zip", it cannot resolve the metadata file, perhaps we should prevent some invalid words like %2c.
When a repository is cloned from certain sites, the directory name is URL encoded. Which would convert space characters in directory names to %20, forward slashes to %2f, underscores to %5f, etc. Although, I'm not sure why the % symbol is breaking things.
Renaming the path into a normal name resolved my issue.
I also met this problem. Firstly you have to manually build you DLL project, by right-click, Build. Then it will work.
In my case, the problem was caused by a simple build error,
error CS0067: The event 'XYZ' is never used
that, for any reason, did not show up in the error window.
Because of that, the Visual Studio build system seemed to miss the error and tried to build dependent projects, which in turn failed with the annoying metadata message.
The recommendation is -as stupid as it may sound-:
First look at your Output Window!
It took me half an hour before this idea hit me...
I got the same error "Metadata file '.dll' could not be found", and I tried several things described above, but the reason for the error was that I was referencing third-party DLL file which was targeting a .NET version higher that my project target .NET version. So the solution was to change the target framework of my project.
I added a new project to my solution and started getting this.
The reason? The project I brought in was targeting a different .NET framework (4.6 and my other two were 4.5.2).
For me, it was trying to find a DLL in a path that used to contain the Project, but we'd moved it to a new directory. The Solution had the correct path to the Project, but Visual Studio somehow kept looking in the old location.
Solution: Rename each problem Project - just add a character or whatever - then rename it back to its original name.
This must reset some global cache of some kind in Visual Studio, because this clears both this issue up and several like it, while things like Clean do not.
It looks like such kind of errors related to the fact that Visual Studio doesn't provide correct information about an error. The developer doesn't even understand the reason for the failed build. It can be a syntax error or something else. In common, to solve such problems you should find the root of the problem (for example, look at the build log).
In my case the problem was in fact that the Error List window didn't show any errors. But really there were syntax errors; I found these errors in the Output window, and after fixing them, the problem was solved.
For me it occurred when I included a new project to a solution.
Visual Studio automatically selects .NET framework 4.5.
I changed to version .NET 4.5.2 like the other libraries, and it worked.
If you have a space in your solution name, this will also cause the issue. Removing the space from your solution name, so path doesn't contain %20 will solve this.
Coming back to this a few years later, this problem is more than likely related to the Windows maximum path limit:
Naming Files, Paths, and Namespaces, Maximum Path Length Limitation
For me the following steps worked:
Find the project that is not building
Remove/add references to projects within the solution.
I was pulling my hair out with this problem also, but after trying the previous answers the only thing that worked for me was to open each project in my solution 1 by 1 and build them individually.
Then I closed Visual Studio 2013, reopened my solution and it compiled fine.
It's strange, because if I clicked each project in my Solution Explorer and tried to build them that way, they all failed. I had to open them alone in their own solutions.
In my case the issue was that I'd manually deleted a non-compilation file which was marked as "missing". Once I deleted the reference to the now-missing file and recompiled - all was well.
My instance of the problem was caused by a common project that had a duplicate class name in it (under a different filename). It is strange that Visual Studio could not detect that and instead just blew up the build process.
I got this problem in Visual Studio 2012 in a solution that had many projects. Rebuilding each project in the solution manually in the same order as the Project Build Order (right-click and rebuild in Solution Explorer) fixed it for me.
Eventually I got to one that gave me a compile error. I fixed the error, and the solution would build correctly after that.
I too had the same error. It hides as in the below path.
The path which I referred to for the DLL file is like "D:\Assemblies Folder\Assembly1.dll".
But the original path in which the assembly referred was "D:\Assemblies%20Folder\Assembly1.dll".
Due to this path name variation, the assembly could not be retrieved from its original path and hence throws the "Metadata not found" error.
The solution is in Stack Overflow question How do I replace all the spaces with %20 in C#?.
Most of the methods explained here did not solved the problem for me.
Finally, I fixed the problem by applying the following steps:
1. Close Visual Studio.
2. Delete all the contents in the bin folders of each project.
3. Open solution and rebuild.
I hit and solved this problem today on VS2022 in a solution with a Blazor project.
The underlying problem is that I had introduced a routine C# compilation error
in C# code declared in a .razor file. VS2022 was dropping the display of the error from the Build Error List tab. I found the C# error by scanning the build output in the Output console log tab where my C# error was described as expected.
p.s. In case you are wondering, I had a Unit Test project referencing my Blazor web project. The project DLL reference from the Unit Test project to the Blazor app was complaining about the missing Blazor DLL.
Based on the error message I don't believe the file path is being truncated. It looks to just be incorrect. If I'm reading the message correctly it appears to be looking for the DLL file at ...
WORK=-\Tools\VersionManagementSystem\BusinessLogicLayer\bin\Debug\BusinessLogicLayer.dll
This is not a valid path. Is it possible that you have a macro definition in the build process set to an invalid value?
I'd faced the same problem. In my case I'd referenced to a class library project with higher .Net version than my project and VS failed to build the project and raised the same error you posted.
I simply set .Net version of my class library project(the one that had broken the build) identical to the .Net version of referenced project and problem solved.
Just pointing out the blatantly obvious: if you don't have "Show output window when build starts" enabled, make sure you're noticing if your build is failing (small "build failed" error in lower left)!!!!
I had this error when I was trying to publish a web application. Turned out that one of a class properties was wrapped into
#if DEBUG
public int SomeProperty { get; set; }
#endif
but the property usage was not. The publishing was done in Release configuration without the DEBUG symbol, obviously.