Anyone can help us here - we have been having this error for several months and had many a stab to remove it, but we still havnt figured out why its there or how to remove it. How is this warning resolved or removed?
Warning 351 A custom tool 'GlobalResourceProxyGenerator' is associated
with file 'App_GlobalResources\GridLocalization.bg-BG.resx', but the
output of the custom tool was not found in the project. You may try
re-running the custom tool by right-clicking on the file in the
Solution Explorer and choosing Run Custom Tool.
After checking out the csproj file and discussing it in the group, we came up with the following answer:
When the resources were added to the project they were added using the wizard. This wizard added the designer files also, so for each reasource file there was also a .designer file.
This was seen as something that was not needed for the language specific resources and the designer files were deleted.
However the csproj files maintained the custom tool reference.
Deleting this reference (to "GlobalResourceProxyGenerator") for each of these resource files removed the issue.
The issue is that Visual Studio 2010 does not automatically remove this tool reference when the designer files are removed manually, creating this warning.
In my case this was caused by a <LastGenOutput> entry in the csproj file that referred to a non-existent file. Removing that line got rid of the warning.
In Visual Studio 2017 I had the same issue with the following error
Warning A custom tool 'ResXFileCodeGenerator' is associated with file <snip name>, but the output of the custom tool was not found in the project.
Removing the reference to
<Generator>ResXFileCodeGenerator</Generator> within the resource file declaration, fixed the issue.
In VS 2019, I also fixed the error:
Warning A custom tool 'ResXFileCodeGenerator' is associated with file , but the output of the custom tool was not found in the project.
By removing the reference to ResXFileCodeGenerator
found within the project's " .csproj" file!
Related
So I just made some c++ application, using NotificationIcon sample from Microsoft as a reference, and thus I'm stuck with the NotificationIcon.exe output file. The name is really lame and I'd like to change it. I've tried renaming the exe, renaming the solution, the project - whatever else - and my programm just exited with code 0x00 after building. What else should I try?
I tried to do the same thing, but there were a few steps I had to follow in VS2019 just to get set up. If you are not in a similar state, the rest of the answer might not apply.
Downloading the sample: I had to install the Windows 7 SDK, as the download page didn't seem to exist anymore. I'm not sure if you found it elsewhere, in which case you might be starting from different sources.
Converting the .vcproj file to .vcxproj. Visual Studio no longer supports .vcproj, and opening the solution triggered this conversion automatically.
Now, once I have a .vcxproj file, there are two routes to setting the name of the exe:
Right-click the project in VS, click Properties, and find the Target Name field. This defaults to $(ProjectName) so I would have expected that renaming the .vcxproj would have renamed the .exe file.
Edit the .vcxproj file directly, adding <TargetName>Foo</TargetName> into the section that starts with <PropertyGroup Label="Globals">
The problem
Suddenly, Visual Studio (2015 RC) started throwing error CS7069 in my face a lot. It states
Reference to type '...' claims it is defined in '<assembly>', but it could not be found.
Yet VS's functionality "Goto reference" did function and squigglies weren't consistently present, so I figured something weird was going on.
How I created the problem
It started when I was refactoring/splitting a project. I was moving .cs files from one project to a new one. Types that I moved to the new project couldn't be found anymore by the compilation process of a project that referenced both projects.
What I tried
I verified that the relevant assembly was indeed referenced, present and had the type with public modifier. I rebuilt it, checked version numbers (of target frameworks etc), removed the relevant reference and re-added it, cleaned solutions and projects, checked configuration manager settings, removed all VS's temporary files and whatnot, and I couldn't fix the bug for 4 days. 4 long days, might I add.
Googling didn't result in anything either, so I hope that the next poor fellow who made the same mistake as I did finds this page, as I finally found out what was going on:
I had two projects with identical assembly names...
Renaming the new assembly in its properties menu made all errors vanish.
Fixed bug on Visual Studio 2015.
Go to Tools menu, Options, Debugging, General: Check: "Use the legacy C# and VB expression evaluators"
Try to clean/rebuild the project. It helped me.
Also try to remove all of the *.suo and *.user files in your solution folder
http://blog.galasoft.ch/posts/2014/01/quick-tip-what-to-do-when-visual-studio-freaks-out-and-everything-is-red/
I had this problem and it turned out I had the wrong build configuration selected. The reference projects and the project I was building were not selected for that build configuration. Simple to fix, but not something I looked at for a while.
I am trying to clean and rebuild a solution file with multiple projects from the command line using MSBUILD. For some reason my build fails (about 10% of the built projects fail) and I get multiple errors which all look like:
error CS0234: The type or namespace name 'foo' does not exist in the namespace 'bar' (are you missing an assembly reference?)
Now if I clean and rebuild the same solution file from Visual Studio 2010 with the exact same configurations it will build successfully with no errors.
Is there a difference in the setup or configuration of MSBuild from Visual Studio that needs to be changed that I am not aware of?
I just had to deal with this issue and it turns out that msbuild likes to move built binaries into the binaries\release directory and reference those instead of the projects themselves when it builds things. After building it copies the files to this directory. This explains why it works in visual studio and not msbuild (I'm currently using TFS 1010).
In my case I had an old binary version of a dll being referenced by a project that was being built after the one that should have generated the correct file. The old one (binary) was overwriting the new one (built from source) as the solution referencing the binary one was being built later in the build.
I assume there's a difference in how the project is built, because Visual Studio does not run MSBuild, as it rather hosts the build engine itself.
This was answered here.
However, I've had similar problem.
In my case the project referenced an external library, which was placed in the project's child directory, unluckily named "packages".
After running MSBuild the folder's content was deleted, supposedly to be downloaded again by Nuget.
The obvious solution was to rename the folder and it worked.
Summary: Set Debug/Release mode in Visual Studio to the same settings as MSBuild to check for compilation errors.
I encountered the same problem:
Tried deleting all "bin" and "obj" folders.
Made sure all related projects are indeed being referenced and not just liked to compiled dlls. ex. Project B references A. Remove A from solution. Then add again. B would then reference A but via compiled dll only. Remove reference and re-add the project.
Finally switched to "Release" in Visual Studio. Turns out I had conditional compilation in some code (eg. #if DEBUG). So what was running in MSBuild and Visual Studio were actually different hence the error "The type or namespace name 'foo' does not exist in the namespace 'bar' (are you missing an assembly reference?)"
Try checking the paths to the references that MSBuild can't find in the non-building library's project file. Sometimes when you use VS or ReSharper to automatically add a reference for you the path ends up being to the \obj directory. VS seems able to cope with this, but MSBuild not so much.
For me the problem was that the some projects in the solution were not included in the build configuration for the solution. Those projects were dependencies for the projects in the build configuration, so all the projects in the solution failed.
After marking the dependcies projects with build in the solution configuration the msbuild ran successfully.
My issue was found in the solution file.
Remove all lines which reference 'ANY' for CPU and leave the 64 bit ones in.
In my case I had one PCL referencing another PCL with different targets. Visual Studio showed me a warning in the references list of the first library, but compiled the solution, whereas MSBUILD refused to compile. I fixed the problem by retargeting the PCL. Hope this helps somebody.
See my answer here.
Basically - Try running msbuild in a new cmd window everytime as a temporary workaround.
I was facing a similar issue. But after spending a lot of time, I finally came up with a solution (that performs similar to VS)
Use the following command to build your solution
"msbuild.exe project.sln /restore /t:Build /p:Configuration="Release";RunCodeAnalysis=False;RestorePackagesConfig=true”
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.
I am currently working on a server control for other applications in our company to interface with a WCF service. Every time I make a change code change and recompile the control, I increment the the AssemblyVerison and AssemblyFileVersion class in the AsseemblyInfo.cs by one. For example, my latest build went from 1.0.07.0 to 1.0.08.0.
When the consuming application updates the file by copying the latest file in the bin directory and tries to compile, they receive the following error:
The type or namespace name 'MyControl'
does not exist in the namespace
'MyNamespace' (are you missing an
assembly reference?)
In order to resolve this error, they have to delete the current reference and re-add the reference.
Is there any way to update the server control without having to delete and re-add the reference?
I am not strong naming the server control.
#JPunyon - Do you mean have the consuming application add the server control project to their solution?
In my case it was a project defined using Target Framework: ".NET Framework 4.0 Client Profile " that tried to reference dll projects defined using Target Framework: ".NET Framework 4.0".
Once I changed the project settings to use Target Framework: ".NET Framework 4.0" everything was built nicely.
Right Click the project->Properties->Application->Target Framework
Right-click the assembly reference in the solution explorer, properties, disable the "Specific Version" option.
If none of the solutions above worked, try this 10-second fix.
Navigate to the startup project in solution explorer. Right click, properties > Application > Target framework. Change the target framework to anything else. Press Yes for the confirmation dialog. Give the changes a few seconds to take effect, then switch the framework back to what it was before.
The error will hopefully go away for you like it did for me!
Are you strong-naming your assemblies? In that case it is not a good idea to auto-increment your build number because with every new build number you will also have to update all your references.
I bumped the answer that pointed me in the right direction, but...
For those who are using Visual C++:
If you need to turn off auto-increment of the version, you can change this value in the "AssemblyInfo.cpp" file (all CLR projects have one). Give it a real version number without the asterisk and it will work the way you want it to.
Just don't forget to implement your own version-control on your assembly!
If the code is working previously and is throwing errors now, as mentioned in the above answers one of the config could have been modified. In brute force approach, close the VS editor and delete .vs folder in the same directory of the .sln file. All the config will be cleared and picked up from the repo files.
In my case, I had to change the Copy Local setting to true (right-click assembly in solution explorer, select properties, locate and change value of Copy Local property). Once this setting was changed, publication of my WCF service copied the file to the server and the error went away.
I encountered this error with an Azure DevOps Services (MS-hosted) build pipeline on a TFVC repo.
In my case, I was working within a branch and had accidentally added the reference from the package folder in trunk instead of from the branch. Once I added the reference from within the branch, it started compiling successfully.
I.e., while working on \branch-beta\sierra.csproj, I accidentally referenced \trunk\packages\delta.dll. Obviously, I needed to reference \branch-beta\packages\delta.dll instead. The mixup occurred because the path is not prominently displayed in the Add Reference window and I didn’t check carefully enough.
I found this issue in Visual Studio 2019 Version 16.4.4
I resolved most issues by discovering that the
packages.config
was missing the appropriate reference
eg:
<package id="System.Runtime" version="4.3.0" targetFramework="net461" />
Delete 'Web.Debug.config' and 'Web.Release.config' file for your solution directory,it should remove all errors
While creating new Blank UWP project in Visual Studio 2017 Community, this error came up:
After restoring the NuGet cache the reference resurfaced in the Project.