I am trying to rebuild a project from the clearcase vob and i get the following error code :
error PRJ0019 .
Any help is very much appreciated ..
thankyou
Try taking a look at the MSDN page for this error
http://msdn.microsoft.com/en-us/library/yzk29wdw(VS.80).aspx
The most likely candidate for causing this problem is a custom build step or script which returns an error code. You'll need to look at the build output log and see which is the last tool that ran as it's the most likely source of the problem.
Related
I ran into this problem today while migrating a VS2008 solution to VS2010. The problem occurred in either of the following scenarios:
Rebuild Solution
Clean followed by Build Solution
If I did a second Build after either of these, the problem did not show up. Using Google, all I really came up with was year-old blogs from Microsoft saying they are unable to reproduce the problem, or that it is fixed in a future release.
The best thing I found was here: Mikazo Tech Blog: Solve MT.exe Errors in Visual Studio 2010
In the above article it said that the problem is related to Manifest generation, and that the solution is to turn off Manifests in settings under Linker-->Manifest. I don't need Manifests for this project, but I still wasn't satisfied.
I have solved this, and am simply going to answer my own question, because I haven't found this specific error (code 31) on StackOverflow.
WARNING: This exact error can also happen as a result of having a Windows Explorer window open in the folder containing the *.exe which you are currently attempting to build.
For example: Explorer open in /.../MyProj/Debug/ while trying to build the Debug version of your code in Visual Studio.
I was angry with myself for ~10min before realizing this.
Using process monitor and dbgview I discovered msmpeng (Microsoft Security Essentials) was accessing the file, just when mt.exe wanted to have it exclusively. Excluding the development directory solved the problem.
It is still a workaround of course.
In my projects, the Intermediate and Output directories were set to:
Intermediate Dir : $(Configuration)\
Output Dir : $(SolutionDir)bin\$(Configuration)\
Under C/C++-->Output Files, I had the following:
ASM List Location : $(IntDir)\
Object File Name : $(IntDir)\
Program Database File Name : $(OutDir)\$(TargetName).pdb
Under Linker-->Manifest File, I had:
Manifest File : $(IntDir)$(TargetName)$(TargetExt).intermediate.manifest
The cure was to remove the trailing \ from my C/C++-->Output Files section (because it's already part of those variables):
ASM List Location : $(IntDir)
Object File Name : $(IntDir)
Program Database File Name : $(OutDir)$(TargetName).pdb
Normally, the double-up of using $(IntDir) or $(OutDir) with a trailing \ doesn't seem to cause trouble, even though it's bad practice. I can't remember now whether I did it by accident or if the conversion process did it, but for whatever reason, it seems to have been messing up MT.exe.
I hope this is useful to anyone else who encounters this problem. Your settings may well be different, but consider that it may be related to improperly formed filenames.
Try turning off Windows Defender (or possibly other anti-virus related software). Windows Defender is known to lock files because MT.EXE runs after the linker is finished. WD jumps in the middle to check up on the newly built EXE and locks it up for the MT.EXE.
Giving credit to https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/c5a3e2c3-fbf4-4268-a551-8cee195be586/test-case-13-for-vista-certification?forum=windowscompatibility, I found this was resolved by fixing the '-' character in the post build commandline. I believe some bad copy/paste efforts have replaced a hyphen with a dash.
deleting the "program debug database" in "debug" folder worked for me.
This problem happened when I was running the .exe in the debug folder on high priority.
Run VS as administrator. It solved the problem for me.
I have a project (*.sln) written in visual studio c 8.0. It was migrated to VC10 recently. When I choose the "Release mode", it was compiled sucessfully. But if I choose "Debug mode", the error " MSB6006 mt.exe code 31" happened.
I found that, in the debug mode, it used a wrong sub-project to startup.
After fixing the startup sub-project, it goes fine so far.
---- new status ---
This won't fix the problem. It just makes the problem disapear temporalily by rebuilding-all. Also, there are other faults caused by the migration. The "resources.h" is missed from the new project and the "winres.rc" is shorten.
In my case it was a problem with TortoiseGit. Removing Debug and Release folders from the GIT repository solved the problem.
Check if you have any anti-virus software like AVG. Exclude the manifest files in the anti-virus software exclusion list.
Look for an MSB8012 warnings. Likely you have a different output specification for the C++ output value and the Linker Output value.
Try Sysinternals/Procmon and filter on process = "mt.exe". It might tell you that a build input cannot be found.
I am trying to migrate an old MFC project to VS 2012 and one of the errors I get is this one:
From what I read is that it has something to do with Help Files, which are not supported on Windows 7.
I thought that maybe Windows is searching for the hcw path so I added to the Environment Variables, but I still get the error. From the code I can see that the command is called inside .mak files:
start /wait hcw /C /E /M "hlp\$(InputName).hpj"
Anyone has an idea how can I get rod of the error ?
Just ran into the same issue. VS 6 project promoted to VS2013.
To eliminate the error. remove the Projectname.hpj file from the project.
Your project requires Microsoft Help Workshop.
Could be a problem in the post build step.
I've been stuck with this error for a couple days now with one of our C++ products. This only occurs when I trigger the build in TFS.
Here are the details:
It is a VS2005 solution with a few C++ projects in it
We are using TFS2012 Update 3
MSBuild Platform is x86
Opening the solution in VS2005 and building does not generate this
error
Full error message, cl : Command line error D8022: cannot open
'xxx.rsp'
I've tried:
Changing the intermediate and output directories to point to
different locations
Changing project dependencies so projects are dependent on each other
Disabled parallel builds
Gave my build account admin rights
Any insight would be greatly appreciated! :)
EDIT
After looking around the logs some more, it seems like the build isn't generating the .rsp files before attempting to locate them.
I noticed when building locally my log displays some warnings before it creates the .rsp file, while the build server lacks these warnings. They both should generate these warnings prior to the .rsp creation.
So my new question is, how do I resolve this race case?
Can anyone make any sense of this TFS build error? Googling produces few results and my research hasn't given me a solution.
Method not found: 'Void
Microsoft.TeamFoundation.TestManagement.Client.ModuleCoverage.set_Statistics(Microsoft.TeamFoundation.TestManagement.Client.CoverageStatistics)'.
For a previous build, where I was getting this same error, I changed Analyze Test Impact to False, and then the build worked. That's not working here though.
What does this even mean? Is it a bug? Does anyone know how to fix it?
My attempt at fixing the issue:
I did not get this exact error, but I got a similar error where built in methods were failing because of the wrong signature and missing methods, because someone installed Visual Studio 2012 on one of my servers. My guess is the new TFS Dlls that came with 2012 were GAC'd and took precedence over the 2010 dlls. I would verify this hasn't happened to you as well.
It appears that the error shown in the original question wasn't really the problem. We have now fixed this in two different solutions, two different ways.
In the first solution, the build succeeded by fixing the CA errors.
In the second solution, the build succeeded by fixing syntax in a post-build event.
I think the entire problem is that an error was showing that wasn't really the problem. I'm not sure why that method not found error would be the symptom, but it wasn't the cause.
Actually, that method not found error still shows in the build log, but the build succeeds, so sometimes you just have to move on...
I was getting this error in the webview but not in the build log file and the build was not failing. Applying the TFS 2010 SP1 patch fixed it for me.
When I try to build my project I get the following message in the build window :
========== Build: 0 succeeded or up-to-date, 0 failed, 1 skipped ==========
I tried rebuilding , then building again , but it doesn't help . Is there a way to view more detailed messages ? The "skipped" part doesn't give me any info on what's wrong . I am using Visual Studio 2005 Professional Edition .
Check with the configuration manager like CMS said and make sure that you have the right platform set. A lot of the time when you use something like the MS Application Blocks the default platform is set to Itanium.
Check on your solution properties, then go to "Configuration Properties", and make sure that all the projects that you want to build, have the build flag checked:
Yet another reason why this could happen (as it happened to me):
When your VS installation is missing x64 compiler toolchain, and you're building for x64.
To solve this, find MSVS in appwiz.cpl ("Programs and Features"), click "Uninstall/Change", then go to the x64 toolchain checkbox under C++ and check it.
This recently happened to me when I tried to compile a project that was apparently orphaned from it's parent solution.
When I finally did get it to compile, it wouldn't work because some library from another project was missing (that was supposed to be part of the solution to get a successful build).
Hmmm... I remember cursing at that one once? Just guessing from my awful memory, but perhaps the output directory path doesn't exist?
I have found the solution *.sln file to be the problem.
Reverted back to a previous version and it fixed the problem.
Often the project references a project that is the actual offender, so try and build up the reference list to see where the problem is.
I generally run into that when the PC is low on resources (RAM), after closing things the build runs fine.