My team is starting to take on the challenge of automating our Build-Deploy-Test process, beginning with the build.
Right now we have Build Definitions configured in TFS that will publish our site to our servers using Web Deploy, and this is working; however, we aren't able to keep an archive of the packages that would be created with each build because when we turn on package creation with the MSBuild parameter /p:CreatePackageOnPublish=true, the build fails on silly NTFS file length constraints.
Exception Message: TF400889: The following path contains more than the allowed 259 characters: \\builds.tfs.company.com\builds\Project.Dev.Nightly\Project.Dev.Nightly_20130630.6\Debug\_PublishedWebsites\Project.Middleware.Service_Package\Archive\Content\C_C\Builds\1005\Project\Project.Dev.Nightly\Sources\Source\Multi\Middleware\Project.Middleware.Service.
Is there a way that we can break the Archive folder out somewhere else?
You can edit the path by using the _PackageTempDir argument for MSBuild.
Just add _PackageTempDir=D:\{desired dir structure} when you're passing in MSBuild arguments.
More full explanation of this property can be found here -
VS2010 Web Deploy: how to remove absolute paths and automate setAcl?
Related
I am getting the following error when I am queuing a build in TFS 2017.
"Microsoft.Web.Publishing.targets 3009,5): Error : Web deployment task failed. (Package file 'C:\agent_work\3\s\TestApp\TestApp\release' does not have a .zip file name extension.)"
I am not sure why I am getting this error. I have hosted agent on the TFS server. I created the build definition according to this video:
www.youtube.com/watch?v=HjD4A-yeFTE
Does somebody have any idea? Appreciate your help!
Test at my side and everything works correctly.
Please try below items to narrow down the issue:
Please check the drop folder, if the .zip file actually being in the
place that you expected.
Try to specify the output path, eg:
/p:PackageLocation="$(build.artifactstagingdirectory)\\" , then
specify the Copy Root path as $(build.artifactstagingdirectory)
in Copy and Publish Build Artifacts task.
Explicitly specifying .zip extension in MSBuild Argument in the
Build Definition.
p:PackageLocation="$(BuildConfiguration)\package.zip
Check the build log, check if MSbuild works correctly. Also you can try the Msbuild command line locally to check if the .zip package can be generated.
Deploy a new agent on your Develop machine, create a new build
definition, then build with the new agent.
If still can not resolve the issue, just share the build logs here for further troubleshoot.
I have a solution containing a web application and multiple database projects. While using the old XAML definition, I can compile and generate the database deployment files in TFS. With the new definition introduced in TFS 2015, I can only generate the web application deployment files.
Here are parts of the log -
2016-10-28T22:14:48.6892904Z Build started 10/28/2016 4:14:48 PM.
2016-10-28T22:14:48.8883071Z 1>Project "E:\TFS\agent\_work\1\s\Test.Client.sln" on node 1 (default targets).
2016-10-28T22:14:48.8893071Z 1>ValidateSolutionConfiguration:
2016-10-28T22:14:48.8903071Z Building solution configuration "release|any cpu".
2016-10-28T22:14:49.0633142Z ##[warning]E:\TFS\agent\_work\1\s\..\Databases\Test\Test.DB.Test.sqlproj.metaproj(0,0): Warning MSB4046: Error reading project file "..\Databases\Test\Test.DB.Test.sqlproj": Could not find a part of the path 'E:\TFS\agent\_work\1\Databases\Test\Test.DB.Test.sqlproj'.
2016-10-28T22:14:49.0643150Z 1>Project "E:\TFS\agent\_work\1\s\Test.Client.sln" (1) is building "E:\TFS\agent\_work\1\s\..\Databases\Test\Test.DB.Test.sqlproj.metaproj" (2) on node 1 (default targets).
2016-10-28T22:14:49.0693159Z 2>E:\TFS\agent\_work\1\s\..\Databases\Test\Test.DB.Test.sqlproj.metaproj : warning MSB4046: Error reading project file "..\Databases\Test\Test.DB.Test.sqlproj": Could not find a part of the path 'E:\TFS\agent\_work\1\Databases\Test\Test.DB.Test.sqlproj'.
2016-10-28T22:14:49.0823182Z 2>Done Building Project "E:\TFS\agent\_work\1\s\..\Databases\Test\Test.DB.Test.sqlproj.metaproj" (default targets).
I could not find much information on the new build definition. Anyone can help?
Thanks
We figured out what is wrong with this. Our database projects are in another folder. We need to map the server path with the local path in the Build's repository. After added this, the database project can be built.
First double check the difference of your two definitions XAML and vNext.
And check the file path E:\TFS\agent\_work\1\s\..\Databases\Test\Test.DB.Test.sqlproj on the build agent, if there are the corresponding file.
And try to build your database project directly instead of building the whole solution to see if there are some useful info for troubleshooting.
Update
Tips:
You can also build MSBuild project (.*proj) files.
If you are building a customized MSBuild project file, we recommend you use the MSBuild step instead of the Visual Studio Build step.
Source Link: Visual Studio Build
I seem to be getting a lot of pain with the processing of app.config and token files (we have this working with the older ".11" templates).
It looks like currently (using the ReleaseTfvcTemplate.12.xaml) this is running the tokenisation after the build.
While I can make the app.config / myapp.exe.config stuff work by deliberately copying the .token file into my output folder (so the recursive search finds it) this feels pretty horrid.
As a fix I'm tempted to move lines 182-230 to just before the RunMSBuild task on line 175 (creating a new sequence at that point)
Is this the correct approach or have I missed some documentation somewhere (or a later version of the template?)
Thanks guys... Anyway for future reference I did make the change.
However I had misunderstood the exact nature of the order things happen out of the box which is as follows:
Get the project out of source control
build with msbuild
Copy the .config.token file over the .config file. This is in the TFS template
As part of the deploy to a server then the token entries in the .config files are replaced. This is in the release manager template.
Tests are run in the msbuild binary output folders.
The problem is this doesn't really work if you're using an project type that uses app.config file as the msbuild process renames these output.exe.config during the msbuild stage so you need to create both an output.exe.config (marked as copy to output) and an output.exe.config.token so when the post deploy is the final output gets configured correctly. This also a problem if you want to tokenise some mstest dlls as these typically use an app.config as well. Basically this is a bit of a mess unless you are using web.config.
We worked our way around this by using the modification I suggested above (you need to create a sequence at line 175 and move lines 178-230 up into the sequence, this is GetBuildDirectory variable bits and the if statement) followed by adding an additional deployment stage which copies back onto the build server with the new tokenised files so the mstest can run against them.
So our new process looks like this:
Get the project out of source control
Copy the .config.token file over the .config file i.e app.config.token copied over app.config
build with msbuild (this means we end up with tokenised myapp.exe.config and mytests.dll.config)
As part of the deploy to a server then the token entries in the .config files are replaced. This is a release management step in the release template.
Deploy the tests back into a folder on build server (think this has to be a fixed folder until update 4 of release manager is deployed) the token entries in the .config files are replaced (so our integration tests can use the newly deployed servers). This is a release management step in the release template.
Tests are run in the fixed folder on the build server (rather than the msbuild output directory) so the test wildcard needs to be changed in the tfs build template.
Quick final note we don't use that build directory variable and it's left at blank I'm not convinced this would work if it was set to a value...
The replacement of variables in config files with Release Management happens at deployment time and not at compile time.
When RM deployes your app it inserts the correct variables.
It sounds like you're hitting one of two issues:
You need to include the .token file in your project and make sure it's set to Copy Always, so that it gets copied to the build output folder.
If you're building a web application, I've seen a bug in the release build process template that doesn't touch the contents of the _PublishedWebsites folder. I don't know if it's been fixed in Update 4 or not, but it was definitely still a problem in earlier versions.
I have a Visual Studio 2013 solution with the full Orchard source code. When I use "Publish..." on the "Orchard.Web" project in Visual Studio, it correctly publishes the site to the File System destination I've configured into the .PubXml file that I used.
However, if I build this site using Jenkins, the files do not get copied to the destination. I've created a separate PubXml file that is used by Jenkins.
In my Jenkins job, I have two Build steps of interest. The first uses the src\Orchard.sln file with a command line argument of /p:Configuration=Release. This runs correctly, and builds the entire solution.
The second Build step, immediately after, uses the Build File of src\Orchard.Web\Orchard.Web.csproj and these command line arguments:
/p:DeployOnBuild=true
/p:PublishProfile="D:\workspace\Site\trunk\src\Orchard.Web\Properties\PublishProfiles\Jenkins.pubxml"
/p:VisualStudioVersion=12.0
/p:Configuration=Release
/p:Platform=AnyCPU
/v:minimal
/nologo
/p:WarningLevel=1
With this, the build and deploy seems to work - but doesn't. Here are some lines from the build output:
Copying all files to temporary location below for package/publish:
obj\Release\Package\PackageTmp.
Auto ConnectionString Transformed obj\Release\Package\PackageTmp\Shapes\Scripts\Web.config into obj\Release\CSAutoParameterize\transformed\Shapes\Scripts\Web.config.
(... about 200 more "Auto ConnectionString..." lines...)
Finished: SUCCESS
No where does it actually copy the files to the destination defined in the PUBXML file.
In contrast, in Visual Studio, the output looks similar, but transforms only 4 config files and includes lots of "Publishing folder x" lines:
(...)
Transformed Modules\SH.GoogleAnalytics\web.config using ....
Copying all files to temporary location below for package/publish:
obj\Release\Package\PackageTmp.
Publishing folder /...
Publishing folder bin...
(etc.)
(I have installed the latest Windows Azure SDK for .NET on the Jenkins server.)
I have the same trouble,that work for me:
/t:Rebuild
/p:DeployOnBuild=true
/p:PublishProfile=Jenkins_Publish
/p:Configuration=Release
do not use /p:VisualStudioVersion=xxx
This is kind of old, but I actually just set up Orchard to be able to get built via command line and MSBuild. Here is what I did:
/p:VisualStudioVersion=12.0;PublishProfile="example-profile";DeployProjA=true;FrameworkPathOverride="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v4.5";Configuration=Release;PublishProfileRootFolder=c:\Workspace\src\Orchard.Web\Properties\PublishProfiles;Password=ExamplePass
Since you are using Orchard you want to make sure that only the Orchard.Web project gets published so do not use DeployOnBuild=true. This will attempt to deploy every web project in the solution, which is a lot for Orchard. Instead follow the guidelines here to see how to deploy only the web project: http://sedodream.com/2013/03/06/HowToPublishOneWebProjectFromASolution.aspx
I'm trying to deploy a web application using MSDeploy, on Team Build in TFS. There are several questions that address the properties that have to be passed in MSBuild in order to call MSDeploy, but I haven't found sufficient documentation for what properties are available. Does someone have a list of available properties?
Here are some questions that I've found, but I haven't been able to find a definitive list of the properties:
Breaking MsBuild package & deploy into separate MsBuild and MsDeploy commands
How can I get TFS2010 to run MSDEPLOY for me through MSBUILD?
Here's a list I've compiled for my own reference, along with some of the legal values that can be used. Note that these are passed into MSBuild using the /p:<PropertyName>=<Value> syntax.
DeployOnBuild
True
False
DeployTarget
MsDeployPublish
Package
Configuration
Name of a valid solution configuration
CreatePackageOnPublish
True
False
DeployIisAppPath
<Web Site Name>/<Folder>
MsDeployServiceUrl
Location of MSDeploy installation you want to use
MsDeployPublishMethod
WMSVC (Web Management Service)
RemoteAgent
AllowUntrustedCertificate (used with self-signed SSL certificates)
True
False
UserName
Password
SkipExtraFilesOnServer (leave existing non-conflicting files alone)
True
False
Unfortunately documentation for this is almost non-existent at this point. If the various blog posts and forum posts aren't comprehensive enough, you can always look at the .target file that MSDeploy uses which shows how the various properties are used if you are willing to spend the time to wade through copious amounts of XML.
On my machine it's located here:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets
I don't know if this is what you are looking for but you can invoke msdeploy with the /? argument and it will display a list of valid arguments
How about this one /p:IncrementalBuild=True
Some more here https://msdn.microsoft.com/en-us/ff622991.aspx (for sharepoint)
To create a package in build:
/p:IsPackaging=true
To set the publish directory in the same drop output location:
/p:PublishDir=
When your solution contains multiple app projects, set the following parameter to produce app specific publish directories.
/p:AppSpecificPublishOutputs=true
WebDeploy configuration of a SelfContained .NET Core2 application.
Note 2 mandatory properties:
Missing RuntimeIdentifier throws:
error NETSDK1031: It is not supported to build or publish a
self-contained application without specifying a RuntimeIdentifier.
Please either specify a RuntimeIdentifier or set SelfContained to
false.
Missing DeployIisAppPath can throw:
error : Property 'DeployIisAppPath' must be non-empty.
In case you are passing the parameters to dotnet publish, avoid circular dependency with /p:DeployOnBuild=false
error MSB4006: There is a circular dependency in the target dependency
graph involving target "Publish".
Complete WebDeploy configuration for command line:
/P:WebPublishMethod=MSDeploy
/P:DeployOnBuild=True
/P:DeployTarget=MsDeployPublish
/P:TargetFramework=netcoreapp2.0
/P:SelfContained=true
/P:MsDeployServiceUrl=https://my_subdomain.jobit.io:8172/MsDeploy.axd?site=subdomain_path
/P:AllowUntrustedCertificate=True
/P:MSDeployPublishMethod=WMSvc
/P:CreatePackageOnPublish=True
/P:UserName=OTB
/P:Password=Expert
/P:RuntimeIdentifier=win-x86
/P:DeployIisAppPath=subdomain_path