We want to have our build server send the output of each build to
C:\Projects\{project name}\build\{build configuration}\.
To accomplish this, I set the Build Output path property for my projects to that in Visual Studio 2010, and build locally to make sure everything works. When I do so, visual studio changes the path to a relative one, for example ..\..\build\Debug.
Since the project directory is not the same on the build server (we use TeamCity, so the project url there is something like C:\BuildAgent\work\9358A92GF92), the output doesn't end up where we want it.
How do I make Visual Studio not change the build output paths to relative paths?
You cannot convince the IDE to make it absolute. Possible solutions:
Use a post-build event to xcopy the build output
It won't make the path relative if the output directory is on another drive. You could use the SUBST command to map a drive letter like z: to a folder on c: and fool the IDE that way
Run msbuild.exe directly on the build machine. Use the /p command line option to force the OutDir property to another value.
Solution 3 is probably best since you can make it specific to the build machine without tinkering with the project files and make the devs' lives difficult. The command should look similar to this:
msbuild /p:outdir=c:\mumble\ projectOrSolutionFileName
Beware that the output directory name must end with a trailing backslash
You can not convince IDE to use absolute path, but you can change the Project file:
<OutputPath>C:\Dir1\Dir2</OutputPath>
Your IDE will still show relative path but it will store the absolute path.
Works for me with Visual studio 2010 Sp1
Related
My Visual Studio 2013 Custom Build Tool step is failing because the directory in which the step is being executed is not the directory where the project file is (which was by default the case up until recently). I can patch it by adding a cd command to the start of the step to change to the project directory but I was wondering if anyone could tell me
how this directory path is set
how to change it.
The build always assumes the project directory as 'base' directory.
This gives msbuild a set location (Builds to bin\debug is a subfolder off 'Base', reference hint paths and a lot more besides).
I would just change the execute of your tool to be reference based (i.e ....\tool.exe or similar) or make use of the path environment variables ($(OutDir),$(TargetPath),$(ProjectPath),$(TargetDir) etc).
Another option that I make use of is to have a batch file called 'post.bat' that has the necessary steps to execute a custom tool. This is then placed in the project folder and added to the project as an artefact.
Without knowing exactly where your custom tool resides relative to the project (or solution) or what the 'working directory' requirements of the custom tool are I cannot suggest more.
I'm about to start doing some benchmarking/testing of our builds, and I'd like to drive the whole thing from a command line. I am aware of DevEnv but am not convinced it can do what I want.
If I could have a single file built within a single project, I'd be happy.
Can this be done?
The magical incantation is as follows. Note that this has only been tested with VS 2010 - I have heard this is the first version of Visual Studio with this capability:
The Incantation
<msbuild> <project> <settings> <file>
Where
msbuild is a path to MSBuild.exe. Usually this should be set up for you by the VS2010 bat file so the right one will end up in your PATH, but if not I found one at C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe
project is the path to the vcxproj file within which your source file resides.
settings include the following:
/p:Configuration="Debug" // or whatever your Configuration is
/p:Platform=x64 // or x86
/t:ClCompile // to specify specifically you're looking to compile the file
file is actually another setting:
/p:SelectedFiles="path_to_file"
Notes
For <project> I had to specify a project (vcxproj) file instead of a solution (sln) file. The sln I would have used has multiple projects within it, so there would have been extra work to go that route anyhow (if it can even be done).
For the /p:Platform=x64 setting, there are several environment variables that pivot on what platform you are targeting (x64 v. x86) so make sure you set those up properly via Visual Studio's vcvarsall.bat.
Regarding path_to_file in the SelectedFiles parameter, this path must be the path as specified in the project file. If the path does not match the path used in the project file to reference the source, it doesn't seem to work.
I have a few VS 2010 C# projects that are shared between several solutions. I would like these projects to build to the directory of the solutions they are open in. How do I do this?
I considered setting up different build configurations (Debug_Xsln, debug_Ysln, Release_Xsln...) but wasn't sure if there was a better way.
http://msdn.microsoft.com/en-us/library/42x5kfw4(v=VS.100).aspx
You can use a postbuild event with xcopy and the macro $(SolutionName) or $(SolutionDir) to copy the compiled files into the correct folder.
Go into properties for the project, build events tab, and in Post Build event command line enter something like this:
xcopy "$(ProjectDir)bin\$(ConfigurationName)\*.*" "$(SolutionDir)$(ProjectName)\bin\$(ConfigurationName)" /i /d /y
The benefit of this method is you can copy the build output of one project to multiple locations
OR
(as Ziplin discovered)
If you only have one location you want the build output to go, you can use the macros above to set the output path, like this:
$(SolutionDir)$(ProjectName)\bin\$(ConfigurationName)
just go to the project properties on the build tab and set your macroed location as the output path
Normally when a Developer compiles a certain mixed C++/C# solution locally on their machine at our company, they employ the use of a .vssettings configuration file. One of the things included in this config file is reference to various directory paths for Lib and Include files.
However, our buildAgent machines (using TeamCity) are set up to be sterile, and have the bare minimum installed on them required to build any given solution/project. This means the above exampled mixed C++/C# project wont have access to the IDE's configuration where things like include search paths were set. TC accounts for this by allowing you to set all sorts of variables for any given buildConfiguration (or even by buildAgent)....
But how do I get an Include search path to WORK in TC? I'm copying down from Source Control (Perforce) a copy local of what I want Included (1), and then trying to define an Environment Variable (2) -- and yet TC fails the build (3).
I'm sure I have something configured wrong, but for the life of me cant figure out what!
Any help would be most appreciated,
blong
(1) VSC Client Mapping - Perforce
//depot/OpenSource/Boost-1.33.0/boost/... //team-city-agent/OpenSource/boost/...
(2) buildConfig Environment Variable definition
env.Include = %system.teamcity.build.checkoutDir%\OpenSource
(3) TC build log snippet
[16:57:39]: [Project "xxx.sln" (Build target(s)):] e:\buildagent\work\ef1853a454da9d94\xxx\rowsbase.cpp(5, 0): error C1083: Cannot open include file: 'boost/dynamic_bitset.hpp': No such file or directory
First, you should try to compile the solution yourself with msbuild or vcbuild on the command line, because TeamCity will do something similar. If necessary, add msbuild folder to the Path system variable. Then open the command line and type:
msbuild.exe YourSolution.sln
or
msbuild.exe YourSolution.sln /p:Configuration=Release
depending whether you want to do so in debug or release mode. This should give the same C1083 errors.
Here's the fix:
Add the path of the directories you need to add an environment variable (in fact, system variable) that I suggest you call INCLUDE.
Open the file VCProjectEngine.dll.config.xml in folder .../Microsoft Visual Studio 9.0/VC/vcpackages/.
Add the INCLUDE system variable to the include line. To me it came to replacing:
Include="$(VCInstallDir)include;$(VCInstallDir)atlmfc\include;$(WindowsSdkDir)\include;$(FrameworkSDKDir)include"
with:
Include="$(VCInstallDir)include;$(VCInstallDir)atlmfc\include;$(WindowsSdkDir)\include;$(FrameworkSDKDir)include;$(INCLUDE)"
Test it works: Open a new command line (need to after you change environment variables for them to be taken into account) and try to build your solution as shown above. This has worked for me to build C++ solutions with files that #include .
Now let's have it work in TeamCity too. You can run a TC build at this point to see whether it does, but it didn't for me. Go to the "Properties and environment variables" of your TC build configuration, and add an environment variable named INCLUDE with value the same path(s) as in the INCLUDE system variable above.
Now this should work. Hope it helps.
Setting the Build Agent Service to run as a non "local System" account fixed my problem.
I ran into a problem were my C++ projects would build in Visual Studio on the build agent, but they failed when built through TC. The build agent is running windows and agent is running as a service (TeamCity Build Agent Service). The problem was that the service was being run as "Local System" instead of the user that configured Visual Studio. I change service so it would log on as the "build" user and everything worked fine.
On a successful build, I wish to copy the contents of the output directory to a different location under the same "base" folder. This parent folder is a relative part and can vary based on Source Control settings.
I have listed a few of the Macro values available to me ...
$(SolutionDir) = D:\GlobalDir\Version\AppName\Solution1\build
$(ProjectDir) = D:\GlobalDir\Version\AppName\Solution1\Version\ProjectA\
I want to copy the Output Dir contents to the following folder :
D:\GlobalDir\Version\AppName\Solution2\Project\Dependency
The base location "D:\GlobalDir\Version\AppName" needs to be fetched from one of the above macros. However, none of the macro values list only the parent location.
How do I extract only the base location for the post build copy command ?
Here is what you want to put in the project's Post-build event command line:
copy /Y "$(TargetDir)$(ProjectName).dll" "$(SolutionDir)lib\$(ProjectName).dll"
EDIT: Or if your target name is different than the Project Name.
copy /Y "$(TargetDir)$(TargetName).dll" "$(SolutionDir)lib\$(TargetName).dll"
If none of the TargetDir or other macros point to the right place, use the ".." directory to go backwards up the folder hierarchy.
ie. Use $(SolutionDir)\..\.. to get your base directory.
For list of all macros, see here:
http://msdn.microsoft.com/en-us/library/c02as0cs.aspx
You could try:
$(SolutionDir)..\..\
I think this is related, but I had a problem when building directly using msbuild command line (from a batch file) vs building from within VS.
Using something like the following:
<PostBuildEvent>
MOVE /Y "$(TargetDir)something.file1" "$(ProjectDir)something.file1"
start XCOPY /Y /R "$(SolutionDir)SomeConsoleApp\bin\$(ConfigurationName)\*" "$(ProjectDir)App_Data\Consoles\SomeConsoleApp\"
</PostBuildEvent>
(note: start XCOPY rather than XCOPY used to get around a permissions issue which prevented copying)
The macro $(SolutionDir) evaluated to ..\ when executing msbuild from a batchfile, which resulted in the XCOPY command failing. It otherwise worked fine when built from within Visual Studio. Confirmed using /verbosity:diagnostic to see the evaluated output.
Using the macro $(ProjectDir)..\ instead, which amounts to the same thing, worked fine and retained the full path in both build scenarios.
Would it not make sense to use msbuild directly? If you are doing this with every build, then you can add a msbuild task at the end? If you would just like to see if you can’t find another macro value that is not showed on the Visual Studio IDE, you could switch on the msbuild options to diagnostic and that will show you all of the variables that you could use, as well as their current value.
To switch this on in visual studio, go to Tools/Options then scroll down the tree view to the section called Projects and Solutions, expand that and click on Build and Run, at the right their is a drop down that specify the build output verbosity, setting that to diagnostic, will show you what other macro values you could use.
Because I don’t quite know to what level you would like to go, and how complex you want your build to be, this might give you some idea. I have recently been doing build scripts, that even execute SQL code as part of the build. If you would like some more help or even some sample build scripts, let me know, but if it is just a small process you want to run at the end of the build, the perhaps going the full msbuild script is a bit of over kill.
Hope it helps
Rihan
I solved my problem by reinstall VS and then download .Net Core (3.x and 2.x) sdk packages
Here is my post build script
Creates the custom path for my own. Including library and version.
Copies the .dll (target file)
Copies the *.md files.
script:
md c:\_References\$(ProjectName)\$(AssemblyVersion)
xcopy $(ProjectDir)$(OutDir)$(TargetFileName) c:\_References\$(ProjectName)\$(AssemblyVersion) /y
xcopy $(ProjectDir)*.md c:\_References\$(ProjectName)\$(AssemblyVersion) /y