In vcproj file i have
<Configuration
Name="Release|Win32"
OutputDirectory=".\Release"
...
>
What is .\Release it is some kind of macros? In what settings is it indicated? How setup him?
That looks like a very old version of VC++, but you did not specify which. The (not so) new MSBuild project files have the extension vcxproj and have a different format:
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">
<LinkIncremental>true</LinkIncremental>
<OutDir>.\Release</OutDir>
</PropertyGroup>
Nevertheless, you make these changes from the Project properties. By default, the output directory is $(SolutionDir)$(Configuration)\ in which case the <OutDir> setting is missing. You can, however, explicitly set a different output directory.
I know this refers to the MSBuild project format but these are handled similarly in older versions that were using VSBuild.
.\Release is output directory name. Whenever you build your project compiler will create folder Release in the current directory and output will copy to that directory.
Related
I have a project in VS13 and I need it to include few libraries which were compiled using CMake and VS. I have a pair of binaries for a debug and for a release modes. They both have the same names, lets say example.lib and example.dll both for debug and release versions.
Though I can specify separately which example.lib file it needs to include into a project changing a *.lib files in release and debug mode by simply renaming files to something like example_d.lib example_r.lib files, it still does searching for example.dll file in any case. And so every time I change from a release to a debug I need to swap example.dll from one to another and back again.
My question is how to specify catalog which contains certain both dll and lib file, or how to specify a certain dll filename to include it into a project?
Thanks.
The problem is that you rename the .lib file, but do not change the .dll name inside that .lib.
The proper solution is to change the Project Settings when building the DLL, to include $(Configuration) in the names.
You could try and edit the vcxproj file manually and add something as below:
<ItemGroup Condition="'$(Configuration)' == 'Debug'">
<Reference Include="MyLib">
<HintPath>..\..\Debug\MyLib.dll</HintPath>
</Reference>
</ItemGroup>
<ItemGroup Condition="'$(Configuration)' == 'Release'">
<Reference Include="MyLib">
<HintPath>..\..\Release\MyLib.dll</HintPath>
</Reference>
</ItemGroup>
This appears to be a bug in VS2012 but I'm wondering if anyone has a workaround or can explain what's wrong. I followed this page for creating a simple KMDF driver in vs2012 here. Before building, I set the output directory for the driver package project to "$(SolutionDir)Output\$(ConfigurationName)\", the main difference being the addition of "Output" to the path.
When I build targeting Win32 it works fine, everything goes where I expect it to. However, when I build targeting x64, the output goes to "$(SolutionDir)$(ConfigurationName)\" instead. No matter what I enter for the output directory, it always starts at the SolutionDir.
When I'm selecting the Output Directory, if I click on Macros, I can see that OutDir is where the output is actually going, it does not match what I have specified for "Output Directory" in the project properties. Is there something else that is overriding OutDir? I've tried setting OutDir in the .vcxproj file but it still behaves the same.
For anyone who is having this issue; I have found a fix for myself.
You'll need to manually edit the project file (.vcxproj file).
You'll find this line:
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" />
Move the property group that contains the OutDir definition right below that line, as in the following:
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" />
<PropertyGroup Label="Globals">
<OutDir>$(SolutionDir)outbin\$(Configuration)\$(Platform)\</OutDir>
<OutputPath>$(SolutionDir)outbin\$(Configuration)\$(Platform)</OutputPath>
</PropertyGroup>
On my setup, the Microsoft.Cpp.props is overwritting those paths, so I need that to be included first, then overwrite what is configured in there.
In most of my c++ projects, i want to use a different directory structure from visual studio default directory structure. i.e:
/project
/build # put visual studio soluation and project files
/src # only put the c++ header files and source files
/bin # put the target executable files
/debug
/release
/tmp
/debug
/release
Everytime i create a solutaion in vs2010 i will config these directories (e.g OutputDirectory), but now i'm really boring about this.
So is there a tool to generate vs2010 solution and project files automatically according my config file? And my only requirement is to set these directories.
You can achieve the structure with the following CMakeList. The following assumes the file is located at .../project/CMakeLists.txt:
cmake_minimum_required(VERSION 2.8) #every top-level project should start with this command; replace the version with the minimum you want to target
project(MyProjectName)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_SOURCE_DIR}/bin) # put .exe and .dll files here
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_SOURCE_DIR}/bin) # put .so files here (if you ever build on Linux)
set(CMAKE_MODULE_OUTPUT_DIRECTORY ${CMAKE_SOURCE_DIR}/bin) # put .dll and .so files for MODULE targets here
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_SOURCE_DIR}/lib) # put .lib files here
# Note that for multi-configuration generators (like VS), the configuration name will be appended to the above directories automatically
# Now that the directories are set up, we can start defining targets
add_executable(MyExe src/myExe.cpp)
add_library(MyLib SHARED src/myDLL.cpp)
target_link_libraries(MyExe MyLib)
When invoking CMake, set the output directory to .../project/build (e.g. in the CMake GUI). If running from the command line, do it like this:
> cd .../project/build
> cmake .. -G "Visual Studio 10"
Please note that some generators (Eclipse) don't like it when the output directory a subdirectory of the source directory. For such case, a slight directory re-structuring would be recommended.
You could write such a tool yourself in C# for instance, look at the classes in the Microsoft.Build.Construction namespace, they're made for creating projects programmatically.
However a simpler yet more versatile option is using the same property sheet in all your projects, and set all directory paths you need. This also has the huge advantage that it's reusable so should you ever decide to change your output directories, all projects referencing your property sheet are automatically affected.
For example:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<MyMainDir>$(ProjectPath)\..\</MyMainDir>
<OutDir>$(MyMainDir)\bin\$(ConfigurationName)</OutDir>
<IntDir>$(MyMainDir)\tmp\$(ConfigurationName)</IntDir>
</PropertyGroup>
</Project>
This will first figure out your 'main dir' i.e. the one named 'project' in your question and then set the output and intermediate directories based on that and the name of the current ConfigurationName, which by default is Debug or Release.
Now it's just a matter of importing this property sheet in your project: go to View->Other Windows->Property Manager, right-click the project(s), select Add Existing property Sheet. Or you could manually add an <Import Project=....> in the project file.
While you're at it, you might as well also add compiler/linker options to the property sheet so all your projects use the same options. This takes some time now, but will save you tons of time in the future as you don't have to change the same options in the project settings over and over and over again.
When I publish my project in VS2010 for ClickOnce a strange value for <deploymentProvider codebase="file://oldserver/.../....application" /> was present in my manifest file. The name oldserver name was wrong, it had to be replaced.
I didn't have a clue where the name oldserver came from?
In the project file I had
<InstallUrl>\\newserver\...\</InstallUrl>
but when opened, in the project properties in VS2010 oldserver was again displayed as publish folder location.
SOLUTION: In a hidden file called buildconfig.targets this was configured.
This file was referenced in the .proj file:
<Import Project="buildconfig.targets" />
In this file you need
<UpdateUrl>\\newserver\...\</UpdateUrl>
as well!
If you're publishing from Visual Studio, make sure you set the Install Url.
It's in the publish settings (in project settings for the project you are publishing) underneath the install url.
If you're publishing from MSBuild, then you need to set the UpdateUrl property (/p:UpdateUrl=youraddress for example).
When looking at your project in Visual Studio. select Build and then Configuration Manager. Check the information in your build configurations for Debug and Release and make sure they are correct. This is a total guess, but I could see something being set up in there.
I have a solution with several C++ projects. For some of the projects I need some custom file copy, e.g. to copy some configuration files to the output directory or to copy the output files of one project to a specific folder after build.
In some cases I don't want or cannot add these files to the projects directly through the Visual Studio IDE. I created simple .targets files which I can reuse and add to the projects which need the file copying.
Here is a simple example .targets file for copying configuration files:
<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<BuildDependsOn>
$(BuildDependsOn);
CopyCustom
</BuildDependsOn>
</PropertyGroup>
<ItemGroup>
<CustomFiles Include="$(ProjectDir)Config\**\*.xml" />
</ItemGroup>
<PropertyGroup>
<DestCustFolder>$(OutDir)Config\</DestCustFolder>
</PropertyGroup>
<Target Name="CopyCustom"
Inputs="#(CustomFiles )"
Outputs="#(CustomFiles ->'$(DestCustFolder)%(RecursiveDir)%(FileName)%(Extension)')">
<Message Text="Copy custom files..." />
<Copy SourceFiles="#(CustomFiles )" DestinationFiles="#(CustomFiles->'$(DestCustFolder)%(RecursiveDir)%(FileName)%(Extension)')" SkipUnchangedFiles="true" />
</Target>
</Project>
Through the "Build Customization" dialog in Visual Studio I add it to the project so it will be included like this at the end of the project file:
<ImportGroup Label="ExtensionTargets">
<Import Project="..\Targets\CopyCustom.targets" />/
</ImportGroup>
This should enable incremental build of my custom target. If I just edit one of my custom files (and none of the C++ files) and build it form the console with
msbuild foo1.vcxproj
it will actually detect the changes and does an incremental build for my custom target. If no changes are made the target is skipped.
If I do however build inside Visual Studio it will not detect changes to the custom files and only and gives me the message that the project is up to data:
========== Build: 0 succeeded, 0 failed, 5 up-to-date, 0 skipped ==========
I would have to additionally change one of the C++ files to make it check all targets again and to the incremental build.
I was expecting that Visual Studio just executes MSBuild which will then do the up-to-date check on the projects, so it should be the same result as running MSBuild from the console. I was trying to get more information by setting the verbosity level to diagnostic but I just get the same line. It seems to me that MSBuild is not even executed for the project but Visual Studio itself determines that the project is up-to-date.
So I was wondering how Visual Studio actually determines when it should execute MSBuild for a project.
I asked basically the same question before on the MSDN forum but couldn't get a clear answer.
See this suggestion on Microsoft Connect.
Basically you need to set DisableFastUpToDateCheck property to true to disable the fast-up-to-date check.
Just add to your vcxproj or your targets file:
<PropertyGroup>
<DisableFastUpToDateCheck>true</DisableFastUpToDateCheck>
</PropertyGroup>
I found an answer by looking into the book "Inside the Microsoft Build Engine, Second Edition".
Note: I also updated the same in my question in the MSDN forum but I will mainly duplicate the text here again for completeness.
On page 280 they actually saying that the IDE does a "fast up-to-date check" on the project-level. It only spawns a project build and does a more fine-grained check on the individual tasks if this rough project-level check fails.
When running MSBuild from the command line however there is always a fine-grained up-to-date check on the individual tools.
So the IDE only seems to do this fast check on the files which are added to the projects directly and set as one of the "Input File" types.
In my opinion this is not a good design. I would prefer that the IDE is only used to edit the MSBuild project files and then just invokes MSBuild to do the up-to-date check. This would make it much clearer.
I can understand that in a solution with a lot of projects it can make the up-to-date check much faster but there should be at least an option to disable the fast up-to-date check. I was checking the IDE if there is a way to disable this behavior but could not find anything.
The solution suggested here actually works and I am using it at the moment. But I added several custom targets for different kinds of custom files. If I add a new custom file I should never forget to set it to "Custom Build Tool" otherwise the incremental build for this file will not work.
I guess a solution would be to make a full build customization for my custom files and use specific file extensions for them so Visual Studio will automatically detect them when I add them to the project and sets the right Item Type.