Issue: Just started today, all references to any assembly outside of the solution fail to resolve, with The referenced component 'SomeComponent' could not be found. when trying to build. This happens for both 3rd party components (all 15 or so of them) as well as all .NET Framework assemblies - basically anything that isn't another project in the same solution.
Trying to load some other solutions produced the same issue. Creating a new WinForms project worked without a problem, however. (Scratch that, it worked before reinstalling VS, now that doesn't work either. I created a new WinForms app as well as a WPF app, and the designer can't load the assemblies either. I tried targetting 3.5 and 2.0 and no luck.)
Things I've tried:
Repair Visual Studio installation
Rebooting computer
Started VS with /resetsettings flag
System Restore to 2 days ago when it was known to be working
Uninstalling VS and reinstalling
Fresh checkout from SVN
Does anyone have any experience with this and know of a way to get this working again? My strongest Google-fu has failed me, so I'm asking here. Can mark community wiki if requested.
Update:
I tried "upgrading" Windows (to the same version) since I didn't see a repair option for Vista and it's still a no-go. I reinstalled everything that seemed relevant. So far, it's looking like I'm just gonna have to back up and reformat I guess unless a solution comes up sometime before tomorrow.
Update2:
I just backed up data and reformatted, so I'm no longer able to verify any ideas that I haven't tried yet, so I'll just leave the bounty to expire on its own to the top voted answer and as a reference to anyone else who may have this problem later.
I had the same problem. It turns out that something was wrong with NuGet. I removed the following part of the *.csproj-File (opened in a text editor). This has solved the issue for me:
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
</PropertyGroup>
<Error Condition="!Exists('$(SolutionDir)\.nuget\NuGet.targets')" Text="$([System.String]::Format('$(ErrorText)', '$(SolutionDir)\.nuget\NuGet.targets'))" />
</Target>
In my case, the solution was completely different. It looked like it was an issue with NuGet paths (caused by my moving the project to a different solution and then back again.
I edited the .csproj and removed all references to NuGet and associated packages. I also removed the packages folder from the solution folder.
The system components then magically reappeared.
Suggested next debug step: review Project Designer: References -> Reference Paths to verify that the paths to your system and third-party components appear correctly. (Watch out for things that can slip past the old Mark I Eyeball like drive letters.)
Try running VS after turing on Assembly load logging with fuslogvw. You'll be able to see additional errors captured by the runtime when it tries to locate and load the assemblies.
In Vista, you'll have to run fuslogvw as an administrator and somtimes specify an explicit path to save the logs.
You can also try debugging Visual Studio by attaching to it from another instance, or with the basic debugger included with the .NET SDK.
I had this similar issue not too long ago.
I found that the issue was caused by git not properly creating .exe's when jumping from branch to branch(we have nuget.exe in a path and it was getting deleted/added when jumping branches). When you would try to run nuget, windows would throw a fit over the exe.
After reseting the branch many times, I finaly got the exe to run properly. Then I noticed that the security on all the directories in the repo had been reset, so I had to deal with that.
After all of that, visual studio then started to play nice.
Hoped this helps someone!
It may also be a problem with references of other projects in the same solution. I only wanted to build one project, but got this message about references in another project. Although the problem in the other project was correct, I think the message was not correct:
I did not expect the message about another project (the other project was no dependency, so it did not 'need' to be built)
I could not 'interpret' it, because it did not mention the project it was about).
Well, if you click on the error, in VS 2012 RC, and then debug it, the error is gone...
I know that this is an old question but it is still happening in the latest version of Visual Studio (2015). I fixed it in a different way that might not have been available back when the question was asked. Basically, it is related to the fact that VS can't find the .Net Library package. To fix in the latest version of Visual Studio (2015):
Right Click on your solution in the Solution Manager. Choose "Manage NuGet Packages for Solution..."
in the NuGet Window, go to "Installed".
If you have something related to Microsoft.Net such as "Microsoft.NetCore.UniversalWindowsPlatform", remember the name and uninstall the package.
Now go to the browse tab and find the package and install it again. Don't forget to select the correct needed project.
Everything should be ok now.
I hope this helps somebody!
I hate to say it, but it sounds like the system is pretty borked. There has to be a point when it is quicker to reinstall the OS than it is to continue trying to fix the current install.
I just hope you take this in the right spirit... sorry.
Shot in the dark here, but I've run into the same (similar) problem. The issue I ran into was related to having a 64bit machine and running a project that had a mixture of 64bit and 32bit 3rd party dll's. The solution was to ensure I had the correct bits (32v64) and then to have the project build in 32 bit mode: project properties > build > platform target: x86.
Another time this occurred I had to remove all the 64bit dll's and reinstall with the 32bit dll's
HTH's
.nuget folder was missing. add the .nuget folder with nuget files (usually 3 files). open the solution and no warnings on references. My submodule has nuget references and when I pulled the latest version, the solution needs .nuget folder in the project folder.
i.e.
project
/.nuget
/submodule
/.nuget
Visual Studio was unable to find any of my references.
What i did, and following some solutions above, was:
Right click solution entry in Solution Manager window;
In the newly opened NuGet window go to installed, select all entries and update.
The problem gets solved!
Check your output with ILDASM to make sure the references are showing up correctly -- compare them to an assembly that works, and see if anything jumps out at you.
I once encountered a problem, which is in the *.csproj file. It defines an Error node in the Target node, that if one reference/nuget-library doesn't exist, it throws the error while building. The problem is VS do not show correct status for other libraries, thus all the referenced libraries looks like non-loaded, that the local file path cannot be found in the property window.
Here is a sample.
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. xxx.</ErrorText>
</PropertyGroup>
<Error Condition="!Exists('..\packages\...\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\...\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props'))" />
<Error Condition="!Exists('..\packages\NOT-Exist.targets')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\NOT-Exist.targets'))" />
</Target>
...
Related
This morning I upgraded to VS 2017 15.3 and now am getting yellow triangles for most of my references. The project runs fine (build is good in CLI and VS and restore has been run multiple times) that I can tell (and even better on dotnetcore 2.0 actually) but these remain. Has anyone else had this happen or have a suggestion? Thanks.
Link to project.assets.json file --> https://www.dropbox.com/s/c85yuyjiu4pnget/project.assets?dl=0
Also issue of greyed out usings and red references although everything builds and runs fine.
Update: VisualStudio twitter account responded to me to note that this is a bug and they are working on a fix for the future on this....
I have two responses to my post:
1) The using issue noted with things greyed out was actually a ReSharper issue. If you upgrade to VS 2017 15.3 and use R# make sure you update it as well to 2017.2.
2) The Yellow triangles issue is being looked at by the Visual Studio team but honestly I believe it to be linked to warnings in the build that those references are being coerced to either lower dependencies (ie Newtonsoft at different levels) or previews. The quickly evolving .NET 2.0 world may have exacerbated this issue. Yellow triangles have traditionally meant missing but check your warnings to see if that is related and then review the dependency chain. I will update this answer once I hear back from VS team (shout out to them and Damian Edwards + Scott Hanselman for helping me with this on Twitter).
I was experiencing the yellow triangle on references issue after updating the projects in my (.NET 4.6.1) solution to the new .NET Standard .csproj format that comes with VS2017. The references I was getting warnings for were ProjectReference type (although it seemed to spill over into PackageReference for common packages in the projects in question).
I did not have any build warnings and there was nothing in the verbose build output to indicate what the cause could be.
I could follow all warnings back to a single project in my solution. I was able to solve by removing that project from my solution and then adding it back and re-adding only the necessary project references.
It seems the issue was related to unnecessary project references (or possibly circular) caused by the new transitive dependencies support. After removing the project and adding it back with only the minimum ProjectReferences and relying on transitive dependencies support to propagate the dependency, the warnings all disappeared.
This also solved an issue where the project in question was failing compilation during a command line msbuild initiated build on my CI server which only has VS2017 build tools installed (not the full IDE).
I had the same issue, some of the references were marked with the yellow triangle. However, I was able to build and run my project.
I managed to remove these warning by following steps from this answer:
.Net 2015 References with yellow triangle for Nuget packages on portable libraries
I turned on tracing for Visual Studio, I had next warnings in log files for all uncorrectly loaded references:
Encountered conflict between 'Reference:Microsoft.Win32.Primitives, Version=4.0.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL' and 'Reference:C:\Program Files (x86)\Visual Studio\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\ref\Microsoft.Win32.Primitives.dll'. Choosing 'Reference:C:\Program Files (x86)\Visual Studio\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\ref\Microsoft.Win32.Primitives.dll' because AssemblyVersion '4.0.3.0' is greater than '4.0.2.0'.
To be precise, I did next steps:
Removed error condition from my .csproj file
Removed <Private>true</Private> parameter for not-loaded references in .csproj file
Deleted not-loaded packages from \lib and \ref folders in corresponding MSBuild folder.
Deleted packages from \packages folder in solution.
Restored nuget packages.
I'm not sure all these steps are necessary, but it worked for me.
You could check my answer on relative topic here: https://stackoverflow.com/a/59704420/7969733
Just for documentation purpose for new person with this issue try
this and you will rememberme :D
If you go to: Tools > NuGet Administrator > Configurations. and you
have "Allow nuget...." and "automatically check...." cheked.
The only thing than you have to do is click con the button "Clear
All NuGet Cache(s)"
That's it, you don't have to edit manual thinks than can be dangerous,
believe me, I use to need to done some of the steps than describe here
a lot of time, and try more than 5 steps of the official Microsoft
documentation for that issue you could check it here:
https://learn.microsoft.com/nuget/consume-packages/package-restore#restore-packages-automatically-using-visual-studio
But just cleaning the cache solve all the problems
To "Clear All NuGet Cache(s)" in Visual Studio 2019
Tools->NuGet Package Manager->Package Manager Setting
Mismatched Windows SDK Version between the referencing project and the references will cause it. In the vcxproj file it is "<WindowsTargetPlatformVersion>SDK Version</WindowsTargetPlatformVersion>"
I was upgrading from VS2012 to VS2017. Everything was good, then I upgraded to a new version of libtomcrypt and libtommath. Rather than tweak my existing projects, I up-converted the projects from the distributions from VS2008 -> VS2012 -> VS2017. In the process, I picked up Windows SDK Version 10.0.17763.0 in both the new projects. However, all of the projects that referenced those were 8.1, and thus the warning.
I know that this was ready to solve it, and one of my answers was ready to say something about that, but, maybe some of you present the same error and none of this solution listed here solves the problem... I don't know why this problem comes with the global installation of .net 6, but, if you present this issue again, you need to go to
C:\Users\YourUsername.nuget
And delete all the content, don't be afraid, that's a cache generator than will be created again if is need it.
I had a similar issue with visual studio 2017. And discovered that, if when I changed the dependency settings of the package I wanted to install (from lowest dependency to highest) everything worked fine.
Today faced the same issue with an imported project.
FAILED ATTEMPTS: Tried updating nougat packages, checking improper imports and everything imaginable. No help.
SOLUTION: At last just tried building the solution and it worked!
PS: Try building the project first. If it does not work then go for solution hunting.
I've had a problem with my Windows 7 after an update, neither Safe Mode nor Recovery Mode could resolve the problem. I was forced to reinstall Windows completely. To develop on my projects I need Visual Studio 2010.
I always had ReSharper installed and got used to its features, so I installed it aswell.
Everything setup I tried building my solution but encountered a problem ...
(The underlined file can be found here: https://up.zone/aj)
After hours of trying to resolve the problems, I figgured out that ReSharper was the problem. I can build the solution perfectly fine without ReSharper installed. Having it installed, even if all features are turned off and the services are suspended, causes these errors in the picture above to show on build.
I managed to resolve two out of three errors by following the instructions of this Reddit user on his post: https://up.zone/ag
Now I am left with one more exception I cannot figgure out how to resolve. I couldn't really find anything helpful googling, which means you guys are my last hope. I really do not want to go back to developing without ReSharper.
This is the one:
Any idea?
Thank you!
Update 1
I figgured out that the problem must be in the NuGet.targets file, located in the .nuget folder in our solution.
I managed to find a workaround following the suggestion of this post, I am now able to build the solution without any errors.
To summarize, remove this line out of your *.csproj file
<Import Project="$(SolutionDir)\.nuget\nuget.targets" />
Although this works, I don't think this can be the solution. This line is there for a reason I assume. Anybody with a deep understanding of NuGet who might know how to properly resolve this problem?
Update 2
I found out that as soon as you reload your solution/project, the line gets added once again. Also, if you have certain dependencies nuget should download for you - it won't, because the line which makes that call and handles this got removed.
I'm now at a point where I know where the problem is but not why it is caused.
Does ReSharper change anything in the way NuGet behaves? As far as I can tell, nothing gets added or removed to or from the NuGet.targets file due to ReSharper.
There were one more report on this topic, at https://youtrack.jetbrains.com/issue/RSRP-462271 .
The best guess so far is that this is caused by two things happening at once: (a) using MSBuild tasks in C# source code form inside MSBuild XML files rather than DLLs and (b) having some of the MSBuild opensource DLLs shipped with the latest version of ReSharper for its own project file handling needs.
The source code gets compiled into a task DLL during an MSBuild run (not a much common thing to have; Roslyn would do this rather than ship a DLL? seriously?). When building from within Visual Studio (rather than with msbuild.exe), the in-process MSBuild instance is used, and it would run in the same appdomain as ReSharper, so it uses the common assembly reference resoluiton. If it's not too accurate, then it might accidentally pick the wrong DLL version by the short name, which would break the task compilation (that's a separate error, maybe cached away) and then result in the task-not-found error later at runtime (SetEnvironmentVariable task not found in here case).
I've tested on sample solutions with source code based tasks and could not get it broken. So trivial cases are OK. Never heard back from the original issue reporter, so there was no further progress.
Now I've got a hint that this is Visual Studio 10 (any other VS versions installed on that machine?) and maaaaybe it's Roslyn tasks. We might know for sure if you run MSBuild with more detailed logs (by setting the logging options at Tools | Options | Projects and Solutions | Build and Run | MSBuild project build output verbosity to at least Detailed) and building just the faulty project.
I'll also try this out with VS10 and update this reply with new data.
I know there have been other references to this issue. But I didn't upgrade from one version of VS to another. I am currently using VS 2013. The project builds fine, and has even deployed successfully in the past. This is a brand new app. So it wasn't something inherited from another project. Where can I start looking? What can I post here that may be helpful for you guys to hopefully help me? It is a web api 2 site. I am using the publish command within VS2013.
Adding the lines below to my .csproj file seems to solve the same error for me:
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
As part of trying to resolve the issue, I've also installed the MSBuild.Microsoft.VisualStudio.Web.targets Nuget Package. But I'm still not sure it was necessary in order to resolve the issue.
If you get this MSB4057 error from a WebJob project using "Publish as Azure WebJob" using Visual Studio 2013/update 4 - you may need to update the NuGet package Microsoft.Web.WebJobs.Publish
Check MyWebJob\packages.config and if the version is 1.0 you need version 1.02 or higher.
From the package manager console run
Install-Package Microsoft.Web.WebJobs.Publish -Version 1.0.2
With VS 2013 Update 4.
There seems to be issues with the template of a Webjob project so that the reference to webjobs.targets is wrong, even though you've installed the Microsoft.Web.WebJobs.Publish package.
Make sure There Import statement at the bottom of of the project is correct in terms of the path, I tested twice and found it was malformed.
<Import Project="..\..\packages\Microsoft.Web.WebJobs.Publish.1.0.2\tools\webjobs.targets" Condition="Exists('..\..\packages\Microsoft.Web.WebJobs.Publish.1.0.2\tools\webjobs.targets')" />
Also, better avoid using the below, since it binds you to a specific VS version.
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
FYI, same issue on VS2019, same solution:
Install the nuget Microsoft.Web.WebJobs.Publish
Install the nuget MSBuild.Microsoft.VisualStudio.Web.targets
For those who are deploying a WebJob, this error might also be due to a missing webjob-publish-settings.json file (it should be located in the Properties folder of the WebJob project). Its structure should be e.g:
{
"$schema": "http://schemastore.org/schemas/json/webjob-publish-settings.json",
"webJobName": "MyWebJob",
"startTime": "2017-01-27T03:00:00+00:00",
"endTime": null,
"jobRecurrenceFrequency": "Hour",
"interval": 1,
"runMode": "Scheduled",
"is_singleton": true
}
(this is for an hourly scheduled job).
Having just re-installed VS 2017 (15.5.6) I ran into this with one of three WCF projects. I picked through the csprojs for all three and could find no difference between them, cutting and pasting the various imports, paths etc from the working ones didn't make any difference.
Adding the nuget package MSBuild.Microsoft.VisualStudio.Web.targets (v14.0.0.3 was the latest, i.e. VS2015) has fixed the problem...for the moment. I can't believe this has gone away for good though.
Just bumped into this exact error with VS 2015 Update 3. The latest Microsoft.Web.WebJobs.Publish was installed, and I tried unstalling and re-installing for good measure. Still didn't work but there was an error on install that I didn't see the first time around:
install.ps1 cannot be loaded because running scripts is disabled on this system.
This is something that most who have ever run a PowerShell script have run into at one time or another and easy to fix (solution is here), but the error message itself is easy to miss.
Just run the below on the project you want to publish ( and make sure your VisualStudio is running as "Administrator" )
install-package Microsoft.Web.WebJobs.Publish
In order to fix the issue for Visual Studio Enterprise 2015 Update 3, I had to install the following packages and edit the Web job's project file as follows.
STEP 01:Install Packages(Run VS as Administrator for script execution)
1. install-package **MSBuild.Microsoft.VisualStudio.Web.targets**
2. install-package **Microsoft.Web.WebJobs.Publish -Version 1.0.2**
STEP 02: Edit WebJob Project File(Unload the project from VS and Edit/Save .csproj then reload)
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
I got this error in a project with a project.json for the nuget packages.
When I removed the project.json and used the packages.config everything worked fine.
Mind that I did set the ExecutionPolicy for Windows PowerShell before I tried this, (see solution of #Jon Crowell), this might be necesary too.
If anybody finds a way to solve this with a project.json please let me know!
I hit this same problem with a project loaded in Visual Studio 2017. It was previously working on a different machine, but not when I migrated to a new one.
After trying all of the suggestions in the answers here (the question is somewhat duplicated several times on StackOverflow), I finally ran across someone elsewhere who mentioned installing the Azure SDK for VS2015.
This isn't supposed to be needed for VS2017, but it solved the problem for me. I'd previously used 2015 on my old machine but had switched to 2017. Apparently, the SDK bits still mattered.
To add to the answer by #Uri Golani, a switch to the new PackageReference way instead of with the traditional nuget that uses the packages folder, meant it looked like I could delete the packages folder. Whelp, apparently, those references in the csproj to the packages folder (which folder I had deleted) were the problem. I'm not sure how to get the right reference to something else (whatever cache the PackageReferences refer to), so for now, just re-adding a packages folder, with the Microsoft.Bcl.Build.1.0.21 and the Microsoft.Web.WebJobs.Publish.1.1.0 nuget folders seemed to fix this.
First off, let me start by saying that Nuget is awesome. I love it. That being said, there is one thing about it that I have just discovered which is really getting very annoying.
We have an in-house framework which we use for almost all of our projects. So, I recently created a Visual Studio project template for it, along with the VSIX.. had a few problems along the way due to Nuget.. it wouldn't create the new project from a template when the template was referencing the framework.. because the framework was using Nuget and it couldn't find the nuget folders in the new project created from the template. So, solution was to remove nuget from the framework project and only use Nuget for the other projects (anything but the framework). Okay, great.. that solves the problem!
However, now with every Nuget managed project that I open, it automatically adds these 2 lines back into the .csproj of the framework:
<RestorePackages>true</RestorePackages>
and
<Import Project="$(SolutionDir)\.nuget\nuget.targets" />
This is frustrating because we now need to either stop using Nuget altogether OR to keep removing these lines from our framework's .csproj file every time we want to rebuild the template.
Is there any way I can tell Nuget to ignore one project in the solution? In my case, to ignore the framework project...
With a suggestion from Nailuj and also from what I found here: http://samritchie.net/2012/09/17/nuget-packages-in-vs2012-templates/, I tried something that I thought would work, but it didn't serve my needs; that method is just for including the packages in with the new project, which for me is not helpful and doesn't solve the problem (error about missing .nuget targets folders). So, I played with it a bit and came up with something that is not ideal, but is acceptable:
Remove anything and everything to do with Nuget from the project which is to serve as a template. This then causes a problem with the referenced framework, because the framework project is expecting to be managed by Nuget and from this solution it's not, so error occurs... so:
Remove the framework project from the solution and only reference the DLL so it will build, but not complain about missing nuget folders
Rebuild
Export to template
Build VSIX using exported template
Install template
Create a new project from the newly installed template
Enable Nuget package restore on solution of new project
Open Package Manager Console
Notice message about missing packages and agree to download and install them (about 1 minute)
Remove framework DLL reference and replace with actual project (Right-click, Add Existing Project)
Rebuild and run
Celebrate!
I hope this helps anyone else who may find themselves in this predicament. If anyone has a better idea, please let me know. The bounty is still open for another 6 days, so I won't mark this as answer yet.
Why do I get the following error when building a setup project?
An error occurred while validating. HRESULT = '80004005'
One project in solution had ToolsVersion="4.0" (in .csproj file), changed it to ToolsVersion="3.5" and setup project builds fine.
Both of the reasons I found are already in other answers, but they are in separate answers and not fully explained. So, hopefully this will combine the possibilities and give good means of debugging each. :)
Common Reason
My problem was not a dependency error. However, that does seem to be the common reason. So, basically, you need to check your MSI file and make sure that all dependencies are still valid. Probably the best blog response on how you can easily resolve this if it is a dependency issue is An error occurred while validating. HRESULT = '80004005'.
Extract from blog:
Follow steps below to troubleshoot.
If you have multiple project outputs in your solution, identify the project that is giving the problem. You can do that by removing one project at a time from the Setup Project(S) until error goes away.
Once project is identified, identify the reference that could be giving the problem.
Check if the project(A) is referencing to a project that has been removed from solution. - Remove such references if any.
Check if the Project(A) is referencing to a project that was moved to a diffenrent physical location after it was added as a reference. - Remove and add such references.
Rebuild setup project after fixing the reference accordingly to see if error goes away.
Alternative Reason
My problem had to do with Visual Studio versioning, however. So, if your dependencies are valid and you still are getting this problem, then you resolve this if it is a problem with VS2010 .
Basically, if you run MSBuild and see this warning:
Project file contains ToolsVersion="4.0", which is not supported by
this version of MSBuild. Treating the project as if it had
ToolsVersion="3.5"
Then the problem is Visual Studio versioning. This means that one project was opened or created in Visual Studio 2010 and then saved or added to an existing 3.5 solution. I simply searched all files in my project for ToolsVersion="4.0" and found the offending .csproj file, opened it in a text editor and manually changed the 4.0 to a 3.5.
This error is related to a dependency error. I removed all references to my primary output project and added them again. It now compiles OK!
I ran up against this issue today. The solution in my case? Restart Visual Studio 2008.
In my case my solution (VS2008) had a project that was also referenced from another solution (VS2010). In the VS2010 solution I had upgraded the project to .NET 4.0. When I later realized the project was also used in another solution I downgraded it to .NET 3.5. For some reason everything seemed to be changed correctly in the csproj file except one place which is mentioned here: Error in setup project HRESULT = '80004005'
I know this is already solved somewhere else but I wanted to shed some light on this from another problem angle.
While simply removing and re-adding the project dependencies will work in many cases, it is important to note that:
The error message "An error occurred while validating. HRESULT=80004005."
usually happens when project is referenced to the other project which is
not added into the currect [sic] solution. Setup project only supports
dependency projects within same solution.1
I have spent enormous time on this one myself, though none of the above worked. But I have found another solution with a registry hack, you need to add a new DWORD (EnableOutOfProcBuild) value of (0) to HKCU\SOFTWARE\Microsoft\VisualStudio\14.0_Config\MSBuild\EnableOutOfProcBuild
Note: this is for Visual Studio 2015
In my case I had installed Visual Studio 2010 alongside Visual Studio 2008. My setup project, when opened in Visual Studio 2008 gave the same error, but was OK in Visual Studio 2010.
If copied to another machine that did not have Visual Studio 2010, but did have Visual Studio 2008, then it would compile.
I installed Visual Studio 2010 and converted the solutions to that version. Because of performance issues I changed my solutions back to Visual Studio 2008. Everything was better now but I got an error when I tried to compile the setup project. I realized that I had a Visual Studio 2010 Test Project in my solution so all I had to do was unload the Test Project and Build the setup project again.
Summary: unload any Visual Studio 2010 project in solution.
I hope it helps.
I know this is kinda old news, but my particular issue and solution are not specifically stated here (as far as I can tell - if I missed it, I apologize).
I had same problem. It would not compile my project, but had no errors. All I could see was "Build Failed". I opened up the "Output" file (Click View--> Output on menu), and it told me exactly which reference (in my case a .dll) was causing the problem.
I deleted and recreated the reference and it changed the reference name from Microsoft.Office.Core (which was appearently only a 32 bit version) to "OFFICE". Then everything worked great. -- Make sure to make a note of the path to the file you are referencing in the properties window... My new path was exactly the same, but the reference name changed anyway.... still scratching my head on that one...
So the moral of the story is... When you get no errors and your build fails, check the "Output" tab and it might help.
I read this answer from another post on Stack Overflow, and it has worked for me.
Open your setup project file (.vdproj) in Notepad (or any other text editor). Delete these lines at a beginning of the .vdproj file:
"SccProjectName" = "8:"
"SccLocalPath" = "8:"
"SccAuxPath" = "8:"
"SccProvider" = "8:"
Build again - the error is gone. That error didn't stop me from deploying, building, debugging (or anyting) my project; it just annoyed me. And it came on even if I set all projects to be build in a current configuration and the setup project not to.