I've been through the similar questions and their answers don't seem to apply.
Keep getting this error. Works ok with VS6.0
Checked all the settings and can't see NETFramework,Version or simialr anywhere in the project properties. Checked linker settings and can't see the input file NETFramework or Version anywhere.
cheers
Related
Whenever I try to delete (or even exclude) any file from my VS2015 C++ project, I get the following message:
File '...' cannot be removed. The most likely reason is that the file is under source code control and cannot be removed at this time.
Trying to search for this error message gives no results anywhere - am I the only one that has ever got it?
I use perforce, and all the files are checked out, so VS should not know anything about version control.
The only solution I can find is to remove the files from vcxproj file manually, which is very tedious.
Update: the problem seems to be with Perforce plugin. Disabling it allows me to remove files again. This is strange, because I never configured it for this specific project. I also tried to switch source control to None, but it kept resetting every time I restart VS.
I just ran into this issue with Visual Studio 2017. I did some pretty extensive troubleshooting, and found a workaround:
Open the solution/project for which you are seeing this problem.
Open a connection to a perforce depot - even though your solution isn't supposed to be managed by Perforce - by using this option: File / Open Connection to a Perforce Depot...
You should see either a warning dialog or a warning line in the Output tab under Perforce Source Control that says something like "Solution is not under your client's root folder". If you don't see either, you should probably either move your entire solution somewhere that isn't in your client spec (if possible), or exclude the entire solution folder from your perforce client spec. That way, P4VS shouldn't automatically add files in that solution to Perforce.
Navigate to:
Tools / Options / Source Control / Perforce - General
...and uncheck this option to suppress the annoying warning dialog from step 3 that would otherwise appear every time you open that solution:
Warn if solution is outside workspace root
Now, you should be able to remove files again without P4VS interfering. (Fair warning: This workaround may have other side effects that I don't know about, but it has worked for me so far.)
Nothing worked for me so I just opened the project file in a text editor and manually removed the offending files. At some point my build target had changed as well, so a possible reason for this happening was I was trying to remove the files while a different build target was selected to when they were added.
Recently installed Visual Studio 2017 and opened an existing solution (previously opened in Visual Studio 2015). Everything seems to open fine. I can see the solution, files, edit files, etc... However, when I attempt to build the solution, I get the following error:
Error signing output with public key from file 'redacted.snk' -- The process cannot access the file because it is being used by another process. (Exception from HRESULT: 0x80070020)
The closest related SO question I could find is this one here. I have attempted all of the recommendations with no success, including:
Cleaning my temp folder
Editing the csproj with the UseSharedCompilation tag
Set the "maximum number of parallel project builds" to 1
Restarted my computer
I'm running out of ideas on this one. Not sure what to try next. My hunch is that the error isn't 100% accurate (i.e. the file is not being used by another process), and that this has something to do with the upgrade to VS2017.
Any help would be greatly appreciated. Thank you.
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 read around a lot and tried different things but my PhpStorm just doesn't want to compile my SASS/SCSS files into CSS files.
Here are pictures of my File Watcher configuration and the error message it causes:
I also tried doing it over External Tools, but although I tried two different approaches, both lead to the same error. The two configurations and the error can be seen in the following pictures:
Does anyone know what I have to do to get it work?
On Mac it may be required to perform additional steps outlined in this answer to make the environment the same as in Terminal for the GUI applications.
Most likely PATH is different.
Another workaround is to start PhpStorm from the Terminal:
open -a /Applications/PhpStorm.app/
currently I'm trying to create an WebSetup Project for one of our ASP.net4/Silverlight-Web Applications using Visual Studio 2010.
I created the setup Project according to this tutorial, but when I'm trying to build the Setup Project (I did a build of the whole solution before), I get the following error:
Unable to build project output group 'Content Files from MyWebProject (Active)'
According to this and almost any other site I found, this error refers to items that are included in the web-project but missing on disk.
I checked all my projects twice, there is no missing file.
Are there any other solutions to this problem?
Other things I tried:
This post: I do have .xml Files accompanying our .dlls. I also removed the xml File from my project, but it didn't help either
This post: Setting the startup project to my web application changed nothing.
Both of the above Posts are from this thread on forums.asp.net.
I had this problem also. (Visual Studio 2010 Pro, .Net 4.0) I found the missing file using "Publish..." option. Right click on the web app. Up near the top of the menu (5th from the top for me) is "Publish...". Click that. I did "Publish method: File System". Publish fails for the same reason that building the setup fails. The difference is that when Publish fails, it gives an error message.
In most cases it's due to missing files.
Expand all your projects and check that none of them is marked with the Yellow Exclamation mark.
For web applications the usual suspect is config.web and more specifically the Debug/Release versions , click on the '+' next to the Web.Config and see if they are marked as missing.
Good luck
I have faced the same issue at my side. `
[how to resolve ERROR: Unable to build project output group 'Content
Files from XYZ.xyz (Active)]
so solution ==> as per my project resolution I was just removed the reference file same name as the reference shown in the error block as [XYZ.xyz (Active) ] from the WCFSetup project followed by clean with Rebuild the solution.
The problem will be resolved and .MSI, as well as .setup file, will generated