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.
Related
Summary
Does SourcePath property of a file that is added to a setup project support variables? If yes, How can I ask it to pick the file from the folder corresponding to the current build configuration?
Detail
I'm deploying my VSTO add-in using MSI installer, which requires me to include MyAddin.vsto and MyAddin.dll.manifest files to the application folder. I include them manually using Add File command. The problem however is that if I change build configuration from Debug to Release and build my installer, it will still pick those two files from the Debug folder (becuz their paths are hard-coded in the setup project), potentially bundling an old version of the files in the installer. Therefore I want to use some macro/variable that would evaluate to the current build configuration.
The setup project file (.vdproj) adds files like this:
"SourcePath" = "8:..\\MyAddin\\obj\\Release\\MyAddin.vsto"
The path is relative, but the build configuration is hard-coded. I'm looking forward to something like:
"SourcePath" = "8:..\\MyAddin\\obj\\[$BUILD_CONFIG]\\MyAddin.vsto"
I'm using VS2015 community and .NET Framework 4.5.
I have a number of projects which are joined into a solution. Every project has it's own directory structure, and csproj files are located on diferrent level of folder structure.
Every csproj has OutputPath property specified. OutputPath - is a relative path and it varies from project to project in such a way so all projects have the same output dir.
It is work OK if I build a separate project. But everything changes if I try to build solution file. In this case every project output folder differs (depends on a number of '..\' in that project's OutputPath).
I do know, that before some moment all was working fine. Nobody changed build.cmd neither any sln or csproj files. But now I have situation described above.
So my question is - what affects how relative path is evaluated? I mean how can I force relative OutputPath to be evaluated starting from folder where csproj file of that particular project is located. Not from folder where .sln file is.
Let's assume I have following directory structure:
dir1
a.sln
dir2
a.csproj
dir21
dir3
b.csproj
a.csproj has output path set to '../../_bin' which is just above dir1 if counted from a.csproj folder
b.csproj has output path set to '../../../_bin' which is same - just about dir1 if counted from b.csproj
a.sln contains both - a.csproj and b.csproj.
When I run msbuild I get a project build to 'dir1/../../_bin' and b project to 'dir1/../../../_bin' - both relative paths of projects files are counted from solution file location, not project files.
Well, I was able to find out what was causing this. That was custom .targets file, which was inferring SolutionDir property at the start of any msbuild.
I did find out that by using MSBuild Explorer. The tool proved to be very useful in my case - I was not aware of third party .target files on my system.
From Msbuild Import Element description
Relative paths in imported projects are interpreted relative to the
directory of the importing project. Therefore, if a project file is
imported into several project files in different locations, the
relative paths in the imported project file will be interpreted
differently for each imported project.
All MSBuild reserved properties that relate to the project file, for example, MSBuildProjectDirectory
and MSBuildProjectFile, that are referenced in an imported project are
assigned values based on the importing project file.
If you add more details or few samples to your question - it will be easier to understand exact problem.
Edit:
Okay, lets try to pinpoint that mystery. First of all - OutputPath could be affected by Environment variables.
2nd - during build sln file transformed into msbuild project file format and stored in temp file. You can get that temporary file if you execute in cmd "set msbuildemitsolution=1" and then trigger build via command line. There you can check that file and see how your individual projects called. But I suppose you will see multiple .csproj /> entries. And global msbuild properties inherited by that calls.
So I suspect if everything was fine before some point and no changes were made - you are missing OutputPath environment variable or some other variable that contributed to construction of OutputPath.
BTW - I think if you want to fix your issue with forcing relative dir - you also can use $(MSBuildProjectDirectory). This is one of msbuild reserved properties (from here), but this will require yo adjust your OutputPath in each csproj file. What i, personally, prefer to avoid, because it could affect some other targets and introduce subtle issues.
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.
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
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.