I'm using Win10 64bit OS, with Wix3.11RC Toolset installed. My VS2017 have created a Wix v3 installer Project. Our team is using TeamCity9.1 as the CI tool.
Now I want to make the Build Agent in TeamCity to support wixproj build without touch CI server settings(I don't have privilege ). I basically follow some tutorials to checked in all necessary Wix build files(the wix Bin folder, and the wix.targets ) which is put in a relative path to the source code, now I'm blocked with the path issue in editing .wixproj file, the official doc said:
http://wixtoolset.org/documentation/manual/v3/msbuild/daily_builds.html
<PropertyGroup>
<WixToolPath>$(SourceCodeControlRoot)\wix\[[Version]]\</WixToolPath>
<WixTargetsPath>$(WixToolPath)Wix.targets</WixTargetsPath>
<WixTasksPath>$(WixToolPath)wixtasks.dll</WixTasksPath>
</PropertyGroup>
And this is mine:
<PropertyGroup>
<WixToolPath>..\..\wix\3.11\</WixToolPath>
<WixTargetsPath>$(WixToolPath)targetsFile\v3.x\wix.targets</WixTargetsPath>
<WixTasksPath>$(WixToolPath)wixtasks.dll</WixTasksPath>
</PropertyGroup>
The reason I'm using the relative path for WixToolPath is the $(SourceCodeControlRoot) was resolved as D:\ here, but actually the source code will be checked out by CI server and put under a random folder like D:\ABC\f14c7929aa63f1fc. By my configuration, the local build even can't go through, the build error indicates the WixTasksPath had been resolved to a non-existed path: C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x\..\..\wix\3.11\wixtasks.dll
So how can I achieve? thanks!
One of the approaches you can try is to change the path in the file to the absolute path using TeamCity-provided references before invoking the tool. In TeamCity settings you can reference the checkout directory path as %system.teamcity.build.checkoutDir% or use ${teamcity.build.checkoutDir} within MSBuild step if run as MSBuild build step.
You can do the replacement in the first build step or just use TeamCity file content replacer to change the old value to new one.
just use
<WixTasksPath>wixtasks.dll</WixTasksPath>
this worked for me.
Related
I'm trying to build my solution and package up the web app into a web deploy (.zip) package to be deployed.
I've added the Visual Studio Build step with the following MSBuild Arguments:
/p:DeployOnBuild=True /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:PackageLocation="$(build.artifactstagingdirectory)\"
And I've set up the Copy and Publish Build Artifacts step to copy all .zip files to the drop folder.
The build completes successfully but nothing is copied to the drop folder because there are no .zip packages that get created.
So when I look on the TFS server, the only thing in the 'a' folder is an empty 'drop' folder. And in the 's' folder is the solution directory with a PrecompiledWeb folder in it. Not sure what that is but it doesn't look like the deployment package (and it's not a .zip).
Any ideas?
I have tried the same on VS2015 MVC web application using VSTS and TFS 2015.2.1 both. I had to do a slight change to the Build arguments in Visual Studio build. That is removing the trailing "\" in /p:PackageLocation="$(build.artifactstagingdirectory)\".
Here is the argument I passed to Visual studio build step
/p:DeployOnBuild=True /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:PackageLocation="$(build.artifactstagingdirectory)"
Then I used Copy and Published Build Artifacts (Deprecated in VSTS you should use Copy task and Publish task instead of this task) as shown below
This gives me output as below.
First suggest you manually remote in the build agent and build the project through MSBuild command line with arguments to see if the project builds properly.
This will narrow down the issue is related to the environment on your build agent or your build definition.
You should directly use /p:PackageLocation=$(build.stagingDirectory
Besides since you have multiple assemblies that are referenced in the web app. Please also double check dependencies that are building in the correct order or referenced correctly.
Make sure the ASP.NET development workload of Visual Studio is installed.
If DeployOnBuild is having no effect, you may need to install the ASP.NET Development "workload" with the VS setup tool.
There are specific .targets files that, if they don't exist, cause these parameters to be silently ignored. Installing this adds those .targets and the parameters become active, allowing the .zip to be created.
For me (VS 2017) the relevant target file (or one of them, anyway) that was missing but is needed is:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\Web\Microsoft.Web.Publishing.targets
If it is missing, you'll need to install as above, and if it is there, then you have a different problem. ;)
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 shared C# project that uses assemblies which rely on native dlls in the current directory. This project is used by developers and a build server which uses msbuild to build and deploy the project with clickonce. There are environmental variables on these machines that specify these native library paths. I tried to find a way to add the dll to the project and set copy local to true, but there doesn't seem to be a way to add a file link using an environment variable.
Is it even possible to use environment variables in the visual studio IDE? If not, what is the correct/normal way to handle this? The dlls need to be found and copied to the output when developers are building and debugging the project from source control, and they need to be added to the click once Application Files when the build server does an msbuild publish.
The msbuild project can use environment variables, so you could add a "post build"
task that uses the environment to and start devenv with "devenv /useenv".
For example:
<Target Name="AfterBuild">
<Copy SourceFiles="$(DatabaseSourcePath)\NORTHWND.MDF"
DestinationFolder="$(TargetAppDataPath)" />
</Target>
I am trying to automatically publish and deploy my .Net 4 web application automatically from a build script to be run by our continuous integration server. I am using the new _WPPCopyWebApplication target from VS2010 to perform the publish, however it appears to reset the current working directory of the msbuild project to c:\ this causes my prebuild steps to fail as they have relative paths to some external tools. The task I am running from our master.build file is as follows:
<Target Name="PublishWeb">
<MSBuild
Projects="$(ProjectPath)"
Targets="ResolveReferences;_WPPCopyWebApplication"
Properties="WebProjectOutputDir=$(DeployPath);OutDir=$(TempOutputFolder)$(WebOutputFolder)\;OutputPath=$(ProjectPath)\bin\Debug;" />
</Target>
This does not happen when using the legacy _CopyWebApplication. Does anyone have any idea how to resolve this problem?
Two possibilities come to mind:
Use the Exec task to call msbuild.exe, and supply a specific working directory.
Your pre-build steps are evaluated by MSBuild and can reference any MSBuild property, so make your paths relative to something specific, like $(MSBuildProjectDirectory), or $(MSBuildThisFileDirectory), instead of just relative to the current directory.
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.