I get this warning message on VS2010 SP1 building a C++ project. Configuration properties are:
Output Directory under General: $(SolutionDir)$(Configuration)\
Output File under linker: $(OutDir)$(TargetName)$(TargetExt)
I tried changing these two properties but still get the MSB8004 warning.
Open the project settings and add a \ at the end of the Output Directory.
It should have a value like $(SolutionDir)$(Configuration)\
For more details refer to
https://connect.microsoft.com/VisualStudio/feedback/details/534031/erroneous-warning-msb8004
Restart visual Studio & rebuild
Related
When i am trying to Build my default JavaScript project(BlankApp Apache Cordova) in Visual Studio 2015 preview am getting following error.
The TypeScript Compiler was given no files for compilation, so it will skip compiling.
Steps Taken in visual studio 2015 preview:
File -> New -> Project -> Apache Cordova apps(under Javascript templates).
Run the default project with Android Emulator.
Getting the following error.
Warning 2 The TypeScript Compiler was given no files for compilation, so it will skip compiling. C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\TypeScript\Microsoft.TypeScript.targets 97 5 BlankCordovaApp4
This is a known issue in the CTP3 release. It sounds like you've created a JS-based project, and have not added any TypeScript files, and so of course there are no .ts (aka TypeScript) files passed to the compiler. Ideally the compiler wouldn't be run at all, but the warning is harmless, and everything else should otherwise be working.
You need to make sure that at least one of your TypeScript files is marked with the TypeScriptCompile build action.
If you click on the file and check the properties window in Visual Studio you will see the build action - it may be that they are all set to some other action.
Option 1:
Take Project offline, edit project, remove the following lines:
<Import
Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.Default.props"
Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.Default.props')"/>
and
<Import
Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets"
Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets')"
/>
Option 2:
Change "AddTypeScriptReferencePath": true to false in Webessentials-Settings.json
It seems that there is no type script file available to compile. add a blank type script file under script folder and then compile, it should work.
This warning was driving me nuts with ASP.NET 5 (asp.net core 1). If you double click the warning you open the Microsoft.TypeScript.targets file. Delete the line with CompileTypeScript and the warning goes away. I'm assuming this prevents TypeScript from compiling normally, which is fine by me as I don't want it anyway.
<PropertyGroup>
<CompileDependsOn>
CompileTypeScript; <--- delete this line
$(CompileDependsOn);
</CompileDependsOn>
I had the same issue.
Mine was due to missing system variable to nodejs. Check your visual studio output. If it is not recognizing “node” command, add system variable.
Computer->right click-> properties -> advanced system settings -> Environment Variable
Check “path” under user variables and system variables
Add the nodejs path to it. Ie: C:\Program Files (x86)\nodejs
I am using Visual Studio Express 2012. Where is the location of the log file? I have searched in the folder where my solution and projects are stored, but cannot find any .log file.
This is the configuration for logging:
Log file from Visual Studio is only supported for C++ projects. You just have to work with the output window for others.
See this similar thread: VS2010: minimal build log in output and detailed log in log file
And in case you happen to do this for a C++ project, the file is at:
... build log in the intermediate files directory
... The path and name of the build log is represented by the MSBuild macro
expression, $(IntDir)\$(MSBuildProjectName).log.
Use build output instead of logging to file. Instead of copy/paste, simply click somewhere in the output and press CTRL + S to save. Visual Studio will prompt you for a location (tested with Visual Studio 2017, but I'm assuming this works in earlier versions too).
The msdn documentation is pretty clear about this (And you ain't gonna like it!):
https://msdn.microsoft.com/en-us/library/jj651643.aspx
Where it says:
To create a build log file for a managed-code project On the menu bar,
choose Build, Build Solution.
In the Output window, highlight the
information from the build, and then copy it to the Clipboard.
Open a
text editor, such as Notepad, paste the information into the file, and
then save it.
While it's true that VS doesn't allow this directly, it is still possible to build with MSBuild "inside" VS2015 and get both the build window output and the log file, as follows: (Arguably this is a bit of a hack.)
In your VS Managed solution, add a new project (Let's call it 'Make').
a. The project type you want is Visual C++/NMake project.
Define the MSBuild commands you need on the command line (see below).
Change the solution configuration to build the NMake project instead of the normal managed projects.
This will create a project that has Build, Rebuild, and Clean command lines where you can execute MSBuild directly. For example:
Rebuild: MSBuild.exe /ds /v:diag /property:Configuration=Debug ..\BuildTest\BuildTest.csproj /t:Clean,Build
Build: MSBuild.exe /ds /v:diag /property:Configuration=Debug ..\BuildTest\BuildTest.csproj /t:Build
Clean: MSBuild.exe /ds /v:diag /property:Configuration=Debug ..\BuildTest\BuildTest.csproj /t:Clean
You can also specify multiple MSBuild.EXE command lines in order to build multiple projects. For the usual build-the-entire-solution outcome you can target only the final end assemblies and let the dependency graph generate the individual targets.
This will produce a .log file, where NAME is the name of the NMake project you used. In the example above, the log would be make.log.
A working example is available on GitHub:
https://github.com/bitblitz/VS_MsbuildExample
(Tested with VS2015)
Note that building individual projects directly will still build with the normal VS behavior, but you can build the full solution inside VS and get the build logs.
When I build a Visual Studio project, the executable is written to the output directory specified in the projects Property Page.
I have a project that has some extra files (e.g., .ini file) that are used by the program.
How can I configure the project to copy the file to the output directory so that when the program runs, it has a copy of the other file in its CWD?
I checked the Property Page of the file and there was nothing useful other than an option to exclude it from the build (which is disabled), and the custom-build-tool command is empty (plus it is a plain-text file that does not need any processing).
For copying a files to the output directory in Visual Studio 2003 you could use Post-Build event:
Right click on the project->Properties
Common Properties->Build Events
Set Post-Build Event Command Line to:
xcopy /y $(ProjectDir)my_file.ini $(ProjectDir)$(OutDir)
OK and build!
Please try select the file in Solution Explorer. Then you should be able to see its properties in Properties window (press F4 if it is not visible). You will find there two properties:
"Build Action" and
"Copy to Output Directory"
Set "Build Action" to "Content", and then - select an appropriate value for "Copy to Output Directory" setting.
File properties window with "Build Action" and "Copy to Output Directory" settings
If the way above doesn't work for you, please read this post "Copy to output directory issue with .inf file". And have a look at this one then "Visual Studio: default build action for non-default file-types"
While I was searching the file’s Property Page for a build-action field, I had a thought: set the custom build step to copy the file (manually). This turned out to be easier than I thought. I had figured it would require using cmd or other external executable (xcopy, robocopy, etc.), but that is not necessary.
I set the Custom Build Step as follows:
Command Line : copy $(InputFileName) $(OutDir)
Description : Copying foobar...
Outputs : $(InputFileName)
Setting the outputs field (correctly) was critical in order to prevent VS from always thinking the project is out of date and requiring to be rebuilt (I’m not certain if it needs to be prefixed with $(OutDir)\).
It is reflected in the Output window as such:
Copying foobar...
1 file(s) copied.
Compiling resources...
Linking...
For VS 2017 the command Dmitry Pavlov posted would be the following:
xcopy /y "$(ProjectDir)my_file.ini" "$(OutDir)"
Quotes are important in case there are spaces in the path to the project directory.
Expanding on Synetech's answer.
In VS2019 right click the file you want to copy in the Solution Explorer and select Properties. Then under General >> Item Type change to Copy File then hit Apply.
You now should have UI fields in the Properties Page for Destination etc.
In case this helps anyone, I needed to copy the output dll of the project i was building into another project.
xcopy /y "$(ProjectDir)$(OutDir)$(TargetName)$(TargetExt)"
"C:\Application\MyApplicationName\bin\x86\Debug"
/y = overwrite file if already exists
$(ProjectDir) = location on your machine where the project lives
$(OutDir) = is where your current build setup outputs the build
$(TargetName) = What the project being built is set to be called. Ex: XXX of XXX.dll
$(TargetExt) = the extension of the build Ex: .dll of XXX.dll
"C:/..../x86/Debug" is the location to copy to.
You need the extra $(OutDir). Otherwise, in the rebuild/clean step it will throw away your source.
CommandLine : copy "$(SolutionDir)last-script.js" "$(TargetDir)Debug"
Outputs : $(TargetDir)Debug\last-script.js
Improving Synetech
answer :
In VS 2013 C++ project Command Line : copy %(Identity) $(OutDir) Description : Copying foobar... Outputs : %(Identity)
It works , But it leads to circular dependency , i.e. it will be executed each time you demand increamental build, no meter it has been already copied.
To solve this , you can add that item at target folder, change path to $(OutDir), and use that in first added item as Output. Drawback - two items with similar name are in solution.
Also usefull xcopy with /d /y parameters in postbuild - copy only if target file date is older.
You could also after the unload the project (Right click on the project >> Unload Project) add the following inside an existent <ItemGroup> tag:
<Content Include="..\..\Config\db.config">
<Link>Config\db.config</Link>
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
<SubType>Designer</SubType>
</Content>
In this case it will grab the db.config file from 2 folders up and put it in the output folder(by default bin/Debug) after creating a Config folder with the db.config file inside
I am getting the following error when building my code.
C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(990,5):
warning MSB8012:
TargetPath(E:\Study\FWIF\demola\ext-libs\libcommoncpp2-1.6.0\w32\Debug\ccgnu2.dll)
does not match the Linker's OutputFile property value
g\CapeCommon14.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).
I hope that some one will know what to do.
Did you upgrade a project to Visual Studio 2010 from a previous version? If so, this is a well-known issue.
Visual Studio 2010 C++ Project Upgrade Guide
http://blogs.msdn.com/b/vcblog/archive/2010/03/02/visual-studio-2010-c-project-upgrade-guide.aspx
Warnings during upgrade
Here are some of the common warnings that you may run into during conversion:
1) Linker output directory
One of the warnings you may see when upgrading you applications is MSB8012: $(TargetPath) and Linker’s OutputFile property value does not match:
MSB8012: $(TargetExt) ('.dll') does not match the Linker's OutputFile property value 'C:\foo\Debug\MFCActiveX.ocx' ('.ocx') in project configuration 'Debug|Win32'. This may cause your project to build incorrectly. To correct this, please make sure that $(TargetExt) property value matches the value specified in %(Link.OutputFile).
MSB8012: $(TargetPath) ('C:\foo\Debug\MFCActiveX.dll') does not match the Linker's OutputFile property value 'C:\foo\Debug\MFCActiveX.ocx' ('C:\foo\Debug\MFCActiveX.ocx') in project configuration 'Debug|Win32'. This may cause your project to build incorrectly. To correct this, please make sure that $(TargetPath) property value matches the value specified in %(Link.OutputFile).
Link.OutputFile is the value defined at Linker -> General -> Output File on the property page. By default, its value is $(OutDir)$(TargetName)$(TargetExt), which is the same as the value of $(TargetPath). When we convert an application from a previous version, however, there is not an easy way for conversion to parse Link.OutputFile to figure out what exactly the values are for $(TargetName) and $(TargetExt), as different customers may have formatted them in different ways. To work around that, we decided to preserve the value of Linker.OutputFile during conversion. After conversion, $(TargetName) will default to $(ProjectName). $(TargetExt) will default to the default extension for the application type: .dll for Dynamic Library, .lib for Static Library and .exe for Application. Link.OutputFile value will be preserved. Warning MSB8012 will be issued in the conversion log if Link.OutputFile and $(TargetPath) are not the same. You will get the same warnings when building the application.
$(OutDir), $(TargetName) and $(TargetExt) are exposed on the "General" property page, as "Output Directory", "Target Name", "Target Extension", respectively. You can manually change the values of these properties so that you no longer get the warning.
If your project produces Import Library (Linker -> Advanced -> Import Library), you may need to change the Output folder of the Import Library as well after conversion if the Linker output directory is not the default output directory. Otherwise, the generated import lib maybe in a different directory than the linker output.
Debugging.Command is set to default $(TargetPath) after conversion. You may need to make changes so that the right executable will be launched upon F5 (Debugging) or Ctrl + F5 (Start without debugging).
See also here Stackoverflow MSB8012.
What worked for me when converting a VS2008 C++ project to VS2012: right click the project in solution explorer, select properties, in the pop-up: configuration properties, linker, general. Select Output file on the right, this gives a drop-down, select inherent from parent or project defaults. Click apply. This gives the default linker setting: $(OutDir)$(TargetName)$(TargetExt). Re-build the project and the warning should no longer appear.
The same problem occured to me for debug DLLs, that I wanted to have a trailing "D" in the basename. For example, foo.dll (Release) but fooD.dll (Debug). When you refine the output name in the Linker settings of the Debug-Configuration -- the ugly MSB8012 warning occurs.
The only solution that works with Visual-Studio 2010 seems to be a Postbuild-Event for the Debug-Configuration:
#echo off
echo Copying $(OutDir)$(TargetName)$(TargetExt) as $(TargetName)D$(TargetExt)
copy /Y $(OutDir)$(TargetName)$(TargetExt) $(OutDir)$(TargetName)D$(TargetExt)
I had the scenario where my executable name was different than the project name AND I wanted it to build the executable/dll to a different location than where the project was located.
1)Change the default project name to be different.
General->TargetName
< my executable name>
2) Output to a different location where I want the executable to build.
General->OutputDirectory
< my new location goes here >
3) Update the Linker settings.
Linker->General
new value: $(OutDir)$(TargetName)$(TargetExt)
This takes on the new settings from 1 and 2.
I obtained the same error after converting from old project to VS 2010.
To fix this I created empty project of the same type (e.g. .dll, .lib, .exe).
Then I copied its default values in Project Propeties to my project for Output Directory, Intermediate directory and Output File
Goto Project->Properties->Configuration Properties -> Linker->General section
Specify 'Output File' as $(OutDir)$(TargetName)$(TargetExt)
I managed to fix a similar issue by editing the vcxproj file manually.
The OutDir and TargetName settings were at the bottom of the project file.
...
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">
<OutDir>$(OUTPUT_DIRECTORY)\</OutDir>
<IntDir>$(ProjectDir)\$(Configuration)\$(ProjectName)\</IntDir>
<TargetName>$(ProjectName)</TargetName>
</PropertyGroup>
</Project>
Moving the block above the ClCompile block solved the issue.
I solved this by comparing the project to a very similar project that was working properly. All of the settings in the project properties matched but I found the following extra lines in the vcxproj file of the malfunctioning project:
<Lib>
<OutputFile>.\MCtlDrvX.lib</OutputFile>
</Lib>
I deleted them and the message went away and the output went to the directory specified in the project settings.
When executing build->clean solution in Visual Studio 2005 I want to also remove some debug text files that may exist in my build directory. The file name will always be the same, i.e. debug.txt. Is there a way to get Visual Studio to do this?
Go to Project->Properties and choose configuration properties.
THere's an entry "Extensions to delete on clean". Add *.txt to it and that just should do the trick. Or you can explicitly specify debug.txt