I would like to disable the linker for a particular project configuration of a VS2013 C++ project. How can I do this?
I have tried to remove the output path, remove the <Link> parts of the project file, but this only results in error messages ("error : The OutputPath property is not set for project" / "error: The output paths do not match" etc.)
The reason is that this particular configuration does preprocessing to file so no object files are created, which always results in a linker error.
There is a compiler switch /c to "compile only". Unfortunately this is only available outside of Visual Studio. So you would need to build the project on the command line using cl.exe.
Related
I'm performing code coverage on an application using the Visual Studio 2019 instrumentation tool (VSInstr.exe).
In the command prompt (run as admin), I run "vsinstr.exe -coverage ApplicationName.exe #ExcludeList.txt". The result should be an instrumented .exe and .pdb file with the appropriate libraries and functions excluded, but it always fails with an error: "Unable to backup original file".
The problem is apparently in the excludes list text file, as it runs fine without #ExcludeList.txt. I've looked through the excludes list and made sure none of the exclude statements had any syntax problems. The file is formatted correctly, with no other statements or blank lines, and there are no access restrictions on it.
The executable was built with the Linker profile switch set to 'Yes' (Project => Linker => Advanced => Profile), so it is instrumentable. The .exe, .pdb, and the excludes list text file, ExcludeList.txt, are all in the same directory.
What could be the issue?
I have an existing wxWidgets project which I am trying to compile under Visual Studio 2010 (the project was created probably with older version of Visual Studio - could be even VS2003). I compiled wxWidgets library (also included paths in my project). When compiling my project now, I get this error:
1>------ Build started: Project: Terminals, Configuration: Debug Win32 ------
1>Build started 8/24/2015 10:56:23 AM.
1>InitializeBuildStatus:
1> Touching "Debug\Terminals.unsuccessfulbuild".
1>ClCompile:
1> All outputs are up-to-date.
1>ResourceCompile:
1> All outputs are up-to-date.
1>ManifestResourceCompile:
1> All outputs are up-to-date.
1>Link:
1> All outputs are up-to-date.
1>Manifest:
1>
1>wx\msw\wx.manifest : general error c1010070: Failed to load and parse the manifest. The system cannot find the path specified.
1>
1>
1>Build FAILED.
1>
1>Time Elapsed 00:00:01.59
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
Can someone help?
This happens if your project's path has a space in it, for example in my case the project is within my Windows account, so the path begins with "C:\Users\Adam Reece...". I then get "C:\Users\Adam" within a "cannot find" like error when building the manifest.
This is 100% a bug with Visual Studio recently of which Microsoft refuses to recognise. You are not in the wrong for having a space in your path as it's been supported since Windows 95. However as a workaround you either need to make sure there are no spaces in the full path to your project, or disable generation of the manifest. (Project properties -> Linker -> Manifest File -> Generate Manifest -> Change to No (/MANIFEST:NO).)
Based on your description, I suggest you to validate your manifest file and make sure it is correct. You can use Manifestchk.vbs or “ mt.exe -manifest 1.manifest -validate_manifest “.
Moreover, from your error message, you need make sure the complier can find your manifest file configure your configuration correctly.
Go to “Configuration Properties -> Linker -> Manifest File”; turn the
“Generate Manifest” to “No”.
Go to “Configuration Properties -> Manifest Tool “; add your manifest
file path, like: (give mainfest file name like “f:/xxxx.manifest”) to
“Additional Manifest Files”; and turn the “Embed Manifest” to “No”.
Eventually, rebuild again.
If you have any more questions, please feel free to let me know.
This error message always happen when Visual Studio could not find the file. There are some potential causes:
Numbers or spaces in the project name
Project name too long
Started creating the project from a blank project that doesn't have
all of the parts.
I'd suggest trying each of the following to see if it fixes the issue- but backup your project/solution directory first.
A) Clean and rebuild the solution
B) Right click on the solution for the project (in Solution Explorer) and rename the solution to a very simple name (e.g., soln). Then do the same for the project (e.g., rename to proj). Do a rebuild all and see if the problem goes away. If it does you can rename the solution and project to something more meaningful.
C) Right click on the project and open it's properties. Go To Link | Manifest and turn off use of the manifest. Rebuild.
D) Create a new Win32 console project. Have Visual Studio create the initial CPP and .H files you need. Open your old source files and copy the code from those into the new files. Rebuild the new project.
I had the same problem and found the solution that DOES NOT require creating a new user profile...
Yes, it is caused by spaces in usernames. But why? Because mt.exe uses TEMP/TMP environment variables. On one of my machines, the username was with the old 8.3 format in TEMP (C:\users\gerson~1) and that worked. This gave me a hint as to how to adress the problem:
set your users' TEMP to some folder that has no spaces
set your users' TMP to some folder that has no spaces
Ensure you restart VS so that the settings changes take effect. Your build should work now ;)
I had this error together with msb3073. I solved the issue by modifying the project's vcxproj file, changing from:
<PostBuildEvent>
<Command>mt.exe -manifest DesignedForWindows7.manifest -i [...]
</Command>
</PostBuildEvent>
to
<AfterBuildEvent>
<Command>mt.exe -manifest DesignedForWindows7.manifest -i [...]
</Command>
</AfterBuildEvent>
where, in place of [...], there is some command line code that I just copied-pasted.
Be careful that there might be more than one such code block in the vcxproj file
UPDATE 02/07/21: Found a solution for Win10.0..... SDK
https://stackoverflow.com/a/49276285/16360714
I got c1010070: Failed to load and parse the manifest
because my Windows User Profile had a space in it e.g. C:\Users\ John Doe\ and I was trying to use UE4 with C++ and Visual Studio 2017, Win 8.1 SDK
FINAL SOLUTION AT END
Solution 0: CHange TMP and TEMP Windows environment variables to folders with no space. This could break other programs. I kept it changed though while trying other solutions.
Solution 1: Exclude C\User\John Doe ... folders from the project
Solution 2: Try to change your Windows Profile Folder Name (tutorials on YouTube)
Solution 3: Create a new Windows local account with no whitespace and use it for dev
Solution 1 Explanation
If you are using UE4, Makefile will be your Project Configuration default. So you won't have access to Linker or Manifest Tool Settings.
I was getting the following errors when building:
Severity Code Description Project File Line Suppression State
Error c1010070 Failed to load and parse the manifest. The system cannot find the file specified. VirtuPilotv3 C:\Users\John
Severity Code Description Project File Line Suppression State
Error LNK1327 failure during running mt.exe VirtuPilotv3 K:\VRDEVELOPMENT\Virtu-Pilot\Intermediate\ProjectFiles\LINK 1
1
Severity Code Description Project File Line Suppression State
Error MSB3073 The command "K:\VRDEVELOPMENT\UE_4.26\Engine\Build\BatchFiles\Build.bat VirtuPilotv3Editor Win64 Development -Project="K:\VRDEVELOPMENT\Virtu-Pilot\VirtuPilotv3.uproject" -WaitMutex -FromMsBuild" exited with code 6. VirtuPilotv3 C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.MakeFile.Targets 44
I noticed the Macro $(PATH) in Property Page>General>Executable Directories contained a C:\ Users folder path "C:\Users\John Doe.dotnet\tools" to be specific.
So I added the .dotnet folder to my exclude directories and BINGO! I could build and open the editor. [1 VISUAL STUDIO WARNING]
Discovered C:\Users\John Doe.dotnet\tools is found under Windows "path"Environment Path Variables Image variable
I'll probably make a copy of the .dotnet folder to something like C:\VisualStudioCustom and add that folder as Windows Path New .dotnet folder set as path. This Should Solve the problem for all projects. As the new folder will automatically get added to Visual Studios Macro $(PATH). [IT ACTUALLY WORKED, NO VS ERRORS]
I am getting following error while building my vc++ project (Using visual studio 2010)
RC : fatal error RC1107: invalid usage; use RC /? for
I know there is some issue while building resources but how to get the exact problem area?
Thanks
Solution:
Add a slash to the last include path will do the trick.
If your last include path already contain a slash at the end, delete it will also work.
Note: Some other include paths can cause this too; it doesn't have to be the very last include path. In particular, check the last include path that you add (in addition to the built-in ones) in your project/properties file.
I had a similar problem. I solved it removing the trailing backslash from the last path in Include Directories (from Project Properties | Configuration Properties | VC++ Directories).
I got this when upgrading from VS2008 to VS2010. None of the suggested solutions worked for me.
What worked for me was deleting all the files in the configuration build folder (e.g. Release) and rebuilding the solution.
I also solved this problem by removing VS include path "\" from last entry.
My solution for VS2010:
click menu "Project","Properties" to open Property pages.
click "Configuration properties", "general" to change Output Directory from "$(Configuration)\ \" to "$(Configuration)\" ,change interminably directory from "$(SolutionDir)$(Configuration)\ \" to "$(SolutionDir)$(Configuration)\".recompile and it's OK.
I experienced that both with VS2015 and VS2017 .
Pls look in 1, at the answer of AH214.
In some cases the Resource Compiler fails to understand the options of the RC command line created by Visual Studio .
To find the problematic option do:
In VS2015, as described by AH214, copy the command line options listed in Project -> properties -> Configuration Properties -> Resources -> Command Line .
Find some *.rc file on your machine.
Open Visual Studio command prompt.
Issue the command
RC [the options copied in (1)] [the path to the rc file in (2)] .
You should get the same RC1107 error.
Check in this property page the contents of ...Resources -> All
Options . Look for a suspicious option and fix or remove it.
Repeat (4) and (5) till you do not get the RC1107 error in (4).
Once you found the culprit, check if you can change it or even remove
it.
I had this issue with VS 2017. The problem was that I did not notice that I had the build configuration set to Release and there was a string in one of the controls that was too long and needed to be truncated by the resource editor when the resources were loaded. Putting the build configuration back to Debug and attempting to open the Resource file fixed it. I got a different message this time: string too long - truncated, and the resources could be viewed now.
the backslash trick didnt work for me. but i just added a new icon to the RC file and then it worked all fine for me.
I'm trying to compile a C++ type .DLL for a SierraChart custom study.
(Which is a financial trading application.) Here is the warning I get that I need to fix so it all points to the linker output value:
warning MSB8012:
TargetPath(C:\SierraChart\VCProject\Release\SCStudies.dll) does not match the Linker's
OutputFile property value (c:\sierrachart\data\SCStudies.dll).
This may cause your project to build incorrectly. To correct this, please
make sure that $(OutDir), $(TargetName) and $(TargetExt)
property values match the value specified in %(Link.OutputFile).
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets
Any idea what's wrong?
I believe this warning appears specifically when upgrading a C++ project to VS2010. Visual Studio 2010 C++ Project Upgrade Guide describes some of the caveats encountered during an upgrade. If you're uncomfortable changing project settings, then retaining the older version of Visual Studio, may work for you.
To change the %(Link.OutputFile), open the project properties. Navigate to Configuration Properties -> Linker -> General. You can set the Output File to $(OutDir)\SCStudies.dll, which should take care of your issue. You may need to repeat the change for each Configuration/Flavor you will be building (Debug/x86, Release/x86, Debug/Itanium, etc...).
Based on this answer.
I changed the following property:
Linker -> General -> Output File to
"$(OutDir)$(TargetName)$(TargetExt)"
This prevented the warning to appear and the output was generated successfully.
The original configuration was set like:
Properties -> Linker -> General : $(OutDir)\"<'name fileA>".exe
The program tries to run "<'name_project>".exe and as result error Linked.
You need to set the configuration as:
Properties -> Linker -> General : $(OutDir)\"<'project name>".exe
A different fix which others haven't mentioned is that by default the TargetExt is .exe and for my debug builds I changed it to be _d.exe, where instead you should be doing that in the TargetName path.
The directory specified in General->Output Directory and the directory specified in the path at Linker->Output File have to match.
If you want to change the defaults do things in these order:
You first configure the OutDir in General->Output Directory. E.g.
$(SolutionDir)$(Platform)\$(Configuration)\MyProgram\
Make sure Output File is consistent. E.g. this would work
$(OutDir)\$(TargetName)$(TargetExt)
The comment from Gerardo Hernandez helped me.
The directory specified in General->Output Directory and the directory specified in the path at Linker->Output File have to match.
In my case I was importing a large project from Visual Studio 6 and
C:\Project\myproject\OneOfMyDlls\.\Debug\OneOfMyDlls.dll
was not equal to
C:\Project\myproject\Debug\OneOfMyDlls.dll
but
C:\Project\myproject\OneOfMyDlls\..\Debug\OneOfMyDlls.dll
would have been, after path reduction.
The problem was that the Visual Studio 2017 import had changed the output directory from
..\Debug to .\Debug assuming that the unconventional parent directory use was a mistake. In a large project with 13 DLLs of our own, (never mind second and third party DLLs too), it makes sense to collect all the DLLs in one place and ..\Debug was correct.
So while others might have had to change Linker->Output File, in my case it was General->Output Directory which needed to change as it had been corrupted by the import from Visual Studio 6.
Something like ..\Debug had become something like .\Debug after import. (The real project specific names have been removed .)
Looks like it's not significant for the program:
Odd Visual Studio error when following the custom study video
If, like me, you return to Visual Studio after 20 years, you may not know where the project properties are. In VS 2012: top of the screen "FILE EDIT VIEW PROJECT BUILD..." : choose PROJECT. Properties is the last item in the menu. Indeed for me there was a mismatch in the target name, too.
I'm in the process of upgrading a Visual C++ 6 project to Visual Studio 2010, and I've been replacing the post-compile steps of copying files to a common location with having the output file put directly in the final location. However, for the *.tlb files that are being generated, there is an option (in project properties -> MIDL -> Output) to specify the filename. When I put the full path there, it looks reasonable in the command line (says /tlb "full\path\to\filename.tlb"). However, when it actually compiles, the file doesn't get put in the right place, and the command that was executed according to the log was /tlb ".\filename.tlb"). I'm hesitant to specify the path as the output directory, because then it will output the XXX_i.c and XXX.h files into that location as well, which isn't what I want.
Is there any way to get Visual Studio to respect the setting I actually put in the option, instead of doing what it wants?
I just had this problem as well and I finally found out why. Even though this question is a bit old, since it's still open I'll post my solution...
In addition to the MIDL settings under the project properties, there's the same settings under the IDL file itself. Just right-click the IDL file -> Properties -> MIDL -> Output.
This did it for me. Seems illogical, though.
I also ran into same situation so I specified the output file as a relative path and it generated the tlb file in the correct location instead of the default location