I currently have a VSTS build that takes in a Visual Studio solution and builds it (C#) with the following build parameters:
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:UseMerge=true /p:PrecompileBeforePublish=true /p:SingleAssemblyName=AppCode"
I also have various Gulp tasks that take in my front-end files and manipulate them (lint, minify, bundle, etc.) as part of this build. The problem is that the zip that is created from the solution build step doesn't include these distribution files (or any file that's not included in the solution.)
In general it's a bad idea to check in distribution files, you need to generate them as part of the production build. Can anyone point me in the right direction of how to get these files to generate (the build is working for this step) -AND- get them included as part of the zip file generated as part of the solution build?
To include Gulp-Generated Files into web application package zip file, you can get the web application package files into another directory (such as $(build.binariesdirectory)) and after execute all the Gulp tasks, you can add the Gulp-Generated Files into $(build.binariesdirectory). Then zip files from $(build.binariesdirectory) and publish the artifacts.
Detail settings as below:
In VS Build task, change MSBuild arrguments as:
/p:OutDir="$(build.binariesdirectory)\\"
Add a task (PowerShell task or Copy Files task etc) to copy the Gulp-Generated Files to $(build.binariesdirectory).
Add an Archive Files task to zip files from $(build.binariesdirectory) to $(Build.ArtifactStagingDirectory) as below example:
Now the zip file not only contains the package files of the web application, but also contains the Gulp-Generated Files.
Related
In Visual Studio, when we publish to a folder, that folder contains exactly what we need to deploy.
In Azure Pipeline, the Build Solution task produces a a bunch of (to us) unnecessary files plus a zip file (nice!). The zip contains the files we need, but buried in an crazy deep folder path:
\Content\D_C\a\1\s\src\MyProject\obj\Release\Package\PackageTmp\our-files.dll
What we would prefer is:
\our-files.dll
It also modifies connectionStrings in the web.config to support the deploy script it ships with. We don't need that script and that modification is a pain (which we disabled by adding<AutoParameterizationWebConfigConnectionStrings>false</...> to the .csproj file - yuck!)` .
We tried fussing with the parameters in the Build Solution step:
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)\\"
Changing DeployOnBuild to false caused the $(build.artifactsstagingdirectory) to be empty (causing the next step to deploy nothing)
Changing WebPublishMethod to FileSystem made no difference (try finding documentation on the allowed values!)
Changing PackageAsSingleFile to false did what one would expect - no zip, but the contents were still buried in that deep folder structure.
Our downstream script could open the manifest file, xpath out the deep path baked into the zip (does the path always start with d_C?), unzip and grab the contents from there - but what a pain and how unnecessary.
Is there a way to publish just a nice clean build - a zip with contents that directly unpacks to the same files as a plain-jane Publish from Visual Studio does?
In the Visual Studio Build step change "MSBuild Arguments" to
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)\\" /p:UseWPP_CopyWebApplication=true /p:OutDir="$(build.artifactstagingdirectory)"
The key thing is /p:OutDir="$(build.artifactstagingdirectory)" resolves the directory issue and /p:UseWPP_CopyWebApplication=true removes web.config.release and web.config.debug
Then update Publish Build Artifacts step "Path to publish" to
$(build.artifactstagingdirectory)\_PublishedWebsites
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. ;)
I have a solution with 8 projects in it and only 1 of them is a web site/app. The rest all create assemblies that are referenced in the web app.
I want to build the solution and then package the web site project into a web deploy package.
So in TFS, I've added the Visual Studio Build step (no other steps in the definition after this), pointed it to the solution and added the following MSBuild arguments:
/p:DeployOnBuild=True /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)\"
Note that in TFS source control, there are 2 solution folders. For this build, I just want to build one of the solutions. So I've given it the full path to the solution I want (without any wildcards).
The build succeeds and when I look in that directory (\TfsData\Build_work\1), it has created 4 folders in there: 'a', 'b', 's' & 'TestResults'.
Folders 'a', 'b' & 'TestResults' are empty.
The 's' folder has a '$tf' folder with a bunch of stuff in there that I don't know what it's for.
The 's' folder also has BOTH solutions in there. I don't want the second solution build/placed there. Just the first one.
And I can't find any web deploy (zip) packages for the web app in the first solution. It's just the built folders.
S stands for Build.SourcesDirectory
The local path on the agent where your source code files are downloaded. For example: c:\agent\_work\1\s
A stands for Build.ArtifactStagingDirectory
The local path on the agent where any artifacts are copied to before being pushed to their destination. For example: c:\agent\_work\1\a
B stands for Build.BinariesDirectory
The local path on the agent you can use as an output folder for compiled binaries. For example: c:\agent\_work\1\b.
According to your description, you need to cloak folders you don't need in source mappings under Repository of your build definition.
Besides, you have to use Copy and Publish Build Artifacts to publish your build artifacts to drop folder(sever path) or a shared path.
I am trying to set up continuous integration on my server using Visual Studio online.
Created a new agent pool.
Installed and configured a new build agent that I added to that agent pool.
Then I trigger a new build of my code to be handled in my agent pool.
I manage to build it but how to set up the task "Copy and publish build artifacts".
My goal here is to just copy the final website files e.g. binaries, images, cshtml, but NOT all files such c# files. Well sort of like the "Right-click > publish" operation in visual studio.
What value do I need to enter in "Copy root" field? (please see image below)
The documentation is located at: https://msdn.microsoft.com/en-us/Library/vs/alm/Build/scripts/variables
It all boils down to what the output path for your binaries is. If you're not overriding it via an MSBuild argument, $(Build.SourcesDirectory) with a value of **\bin\* will probably get you what you're after.
For a web application, make sure you're building with appropriate MSbuild arguments (something along the lines of /p:OutDir=$(build.stagingDirectory) /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true should do the trick). This will get you a _PublishedWebsites folder in $(Build.StagingDirectory).
Then all you need to do is publish Copy Root of $(Build.StagingDirectory) and Contents of **\_PublishedWebsites\*
Keep in mind that Publish Build Artifacts means publish build artifacts to VSTS or a file share, not deploy build artifacts to a web server
I am using Visual Studio 2013 to develop a website. The website is on github, and I have a server for continuous integration set up with Teamcity.
I am trying to get the website to automatically deploy to AWS when I change it on github. I have Teamcity hooked up, but the AWS CLI is having some issues, so I need to compile the solution in Teamcity into a zip file so that I can deploy to AWS using a workaround.
I've tried editing the project files for an MSBuild fix...I managed to get a zip file output. However, I ran into problems with general compilation.
What I am wondering is, since I can publish a website package from Visual Studio, is it possible to compile as if I was publishing using the build commands from TeamCity (or the command line) so that the result is the compiled project and the website files needed to run the site in a zip file?
you can create a zipped artifact in TeamCity. Simply build the project then set the artifacts for the build like this:
outputFolder\*.dll=>myzipfile.zip
outputFolder\*.whatever=>myzipfile.zip
etc
obviously you'll need to change outputFolder to be where the files are actually output by the build and the patterns to macth the files you want