Is there a way to trigger the custom deployment targets through a TFS build? We are using TFS 2015 (with VS 2015, git repository) and I started with a Visual Studio build definition template, but the custom targets (UmbracoCms.targets) do not get triggered so the umbraco, umbraco_client, and other folders do not get collected in the deployment to the artifacts folder.
I have gotten the publish profiles from within Visual Studio to work correctly multiple times before.
Specifically, here is my configuration:
Solution: $(SolutionPath)
MSBuild Arguments: /p:OutDir=$(build.stagingDirectory) /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true
Platform: $(BuildPlatform)
Configuration: $(BuildConfiguration)
Clean: No
Restore NuGet: No
VS Version: 2015
Cross posted on our.umbraco.com
After more experimenting I found that the below MSBuild parameters published the site as expected (specifically the PublishProfile parameter). I still consider this non-ideal since part of my goal was to create a system where deploying to staging (or production) couldn't be done from Visual Studio without a lot of work and would normally have to go through TFS (for the audit trail). Using the built in publish profiles fundamentally requires the Visual Studio setup I was trying to avoid but I haven't found any alternatives.
/p:OutDir=$(build.stagingDirectory) /p:DeployOnBuild=true /p:PublishProfile=Intranet.pubxml
Related
I'm trying to set up my solution to build using TeamCity 2019. When I enter the URL of my project's Git repository, TeamCity auto-detects 4 build steps:
Visual Studio (sln) Targets: rebuild
.NET CLI (dotnet) restore
.NET CLI (dotnet) build
.NET CLI (dotnet) test
I'm confused about step 2/3. Why is .NET CLI restoring and building, when a re-build is already performed? Does this imply that something is unusual with my .sln file?
This solution is a group of Windows desktop C++ projects, if that matters.
The reason I'm so concerned with why these build steps are appearing is that the .NET CLI build step is failing with a mysterious error, discussed on both the TeamCity forum and StackOverflow:
https://teamcity-support.jetbrains.com/hc/en-us/community/posts/360007640660-error-MSB4019-The-imported-project-C-Microsoft-Cpp-Default-props-was-not-found-when-building-via-TeamCity
MSBuild in TeamCity of Visual Studio 2012 solution
I haven't been able to find any good answer for why those build-steps are failing. All of the answers on StackOverflow for that issue are pretty shot-in-the-dark "try this, try that" without a simple explanation of where I went wrong.
This is list of Build Runners.
In this case you can ignore step 2,3 and 4.
step 1 (first step : Visual Studio (sln) Targets: rebuild) is enough to rebuild your all projects of one .sln.
Teamcity finds all project-point 4 types and display the list with compatible runners, user have to decide which should be compatible with the given project.
Developers use the Visual Studio (VS) GUI to develop their solutions and get their projects all building using a solution file (.SLN). The build teams using vNext then have to automate those builds using MSBuild instead of devenv.exe (the Visual Studio executable file). This is a serious and chronic problem because not only is MSBuild incapable of building several project types, but the build order is defined in a completely different, and complex, way.
Some Microsoft advice (https://learn.microsoft.com/en-us/archive/blogs/msbuild/incorrect-solution-build-ordering-when-using-msbuild-exe) is to switch to explicit dependencies in each .*proj file and remove all dependency specifications in the .SLN file. This sounds like a person who has never worked in a relatively powerless build team trying to get development teams to:
do a lot of what they perceive as time-wasting extra work and to
change how they do things
What build teams need is a way to automate whatever VS allows dev teams to build. If VS is given a SLN to build, then a vNext build needs to be able to use that same SLN in the same way. Instead vNext currently only offers MSBuild as the build tool. MSBuild has many more options than devenv, so that would be great, IF it could be made to use the SLN to govern dependencies in the same way as VS, and would be upgraded to build all the same project types.
There have been prospective efforts, referenced by PatrickLu-MSFT at Build project using devenv.exe in TFS 15RC1 Build Server, to enhance a vNext build step to allow devenv to be used instead of MSBuild, but those efforts seem to have been dropped.
Maybe someone has developed a custom vNext build step to build using devenv?
Here is an existing extension you can reference, which provides a build task in your TFS/VSTS instance that will allow you to build your projects using DevEnv.com (Visual Studio):
https://marketplace.visualstudio.com/items?itemName=mmajcica.devenv-build
If you want to automatically use TFS/DevOps build whatever solution files our development teams get working using Visual Studio, you could set CI trigger in build pipeline, when the solution build successfully on local, you can check in/commit the changes, and trigger TFS/DevOps builds.
Got a Xamarin solution which includes a project for a web app backend.
Trying to set up a separate build definition for the web app backend so that it deploys to Azure app service. We have that API app folder inside the Xamarin solution folder.
When trying manual mapping to build the web app it fails as it tries to build the whole solution while it should only build that project as I used MSBuild task and pointed it to the csproj file in that folder.
How can we get that specific folder to build separately?
There are two ways to just build a project:
Build solution with /t:[projectname] MSBuild arguments (e.g. Visual Studio Build step; Solution: *****.sln**; MSBuild Arguments: /t:ConsoleApplication1; Platform: $(BuildPlatform); Configuration: $(BuildConfiguration)))
Specify the project file directly for Visual Studio Build or MSBuild step/task. (e.g. Visual Studio Build; Solution: [project file (csproj) path]; MSBuild Arguments: /p:OutputPath="bin\$(BuildConfiguration)\\" Platform: $(BuildPlatform); Configuration: $(BuildConfiguration))
We are in the process of upgrading our TFS 2013 server to TFS 2015. In that regard I have run into an issue when trying to perform an application build on a build agent with the new version, using our XAML template build script (which was created in TFS 2013).
Most of our solutions use the above-mentioned template when we build them. The solutions (sadly, still) use setup projects (.vdproj) to generate an MSI package for the application. To build the setup project, and produce an MSI, for a given application; we call the devenv.exe (in our case, it points to Visual Studio 2013) in our template build script:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\devenv.exe /Build "Release|Any CPU" "d:\<path_to_solution>\solution.sln" /Out c:\temp\out.log
However, on our new build agent no MSI is produced, and calling devenv.exe yields neither any output, nor any error messages. If I try to call devenv.com, however, it starts building, but still no MSI is being produced.
When things start to build using devenv.com It seems like it is completely disregarding the setup project (I have checked the build configurations, and the setup project is checked for build on the "Release|Any CPU" configuration).
I have looked at build logs, build process activity logs, and I have also tried to perform the steps manually on the build agent, but I haven't been able to find anything that could point me in the direction as to what might be causing the issue.
Does anyone have an idea what could be the reason for this? Could it be an issue with TFS Build 2015? The only difference between the old setup, and the new - as far as I can tell - is the following:
VS 2013 was installed on C: rather than D: on the new build agent, i.e. the path to devenv would be different, but that should not matter as long as the build script is looking in the right place, and finds it...
We use a different drop location than what we used for the old setup
Appreciate any help and suggestions I can get.
Problem solved, and everything is now building successfully. I did not do a good enough job of looking at the diff between the setup we had on the build agent we used for TFS Build 2013 vs. the one we set up for TFS Build 2015.
Firstly, to be able to build setup projects in VS 2013, one needs to install the Visual Studio 2013 Installer Projects extension on the build agent.
However, there are some bugs with this extension that often causes building setup projects to yield the following error message: "An error occurred while validating. HRESULT = '8000000A'". This error can be fixed by modifying the registry, as described in this SO post.
Building the setup projects using devenv.exe, however, still doesn't work. I have not been able to figure out why, yet.
Use the Vnext build in TFS 2015 to build .vdproj. You just need to add one additional build step i.e "command line" then call devenv.com to build.
Such that,
tool :
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.com
arguments :
HelloWorldTestInstaller\HelloWorldTestInstaller.vdproj /build release
This will help you.
I'm facing quite a problem while setting up automated TFS Builds. Basically I created new configuration called Tests, added transform config, defined different connection strings for the Database. Then defined TFS build, building whole solution with MSBuild arguments /p:DeployOnBuild=True /p:Configuration=Tests.
The problem is that in the drop location (Build_PublishedWebsites\Project) I get web.config, web.debug.config, web.release.config and web.tests.config, however I would expect just one transformed web.config.
I already checked PDC presentation Web Deployment Painkillers: Microsoft Visual Studio 2010 & MS Deploy but didn't help.
Thanks for any answer.
Web.config transforms are part of the new Web Publishing Pipeline (WPP) in Visual Studio 2010.
During the build process the "CopyWebApplication" target is executed to copy the website to the _Websites folder on the build output directory. Due to backwards compatibility reasons, MSBuild uses the "old" (VS2008) copy behavior by default and not the new WPP system.
To opt-in to using WPP, set the following MSBuild properties:
/p:UseWPP_CopyWebApplication=True
/p:PipelineDependsOnBuild=False