I have an existing build definition that builds multiple solutions and each of those has one or more webapps or wcf service projects. Those all get built and copied to _PublishedWebsites. But I have a new project that is a plain Windows Service (NT Service) that does not get separated out into an installable location.
What must I do to have this also copied out like the other ones?
The publish settings in the website application control that. If you want to create a build for your service to output similarly, you can customize the build workflow to create a folder to output all the files. For more information on customize binaries folders see the following links:
http://msdn.microsoft.com/en-us/library/ff977206.aspx
http://lajak.wordpress.com/2011/07/30/customize-binaries-folder-in-tfs-team-build-part-2/
If you mean you want to create a MSI project that will setup the Windows service you can use WIX. For more information see the following link:
http://wix.codeplex.com/
Related
I have created a VS build definition on Team Services. The build runs successfully when I queue it and it also outputs the dlls for all the projects in the solution except the service layer which I have created using Web Api2.
when I download the artifacts from the drop location, I have folders holding the dlls for the data layer, the business layer and other helper projects. What I don't have is the main service layer dll which I can deploy to my IIS.
Here is a screenshot of my publish settings.
What could I be missing ?
It seems that you are using the default settings for the build definition. With these settings, the contents for "Copy Files" task is "**\bin\$(BuildConfiguration)**" while web api project does not have buildconfiguration folder. So it cannot find the files for web api project. To copy these files, add one more "Copy Files" task and configure the settings as following:
If you want the deployment files for the project, you need to set you build definition as following:
Add arguments /p:DeployOnBuild=true;OutDir="$(build.artifactstagingdirectory)" for Visual Studio Build step.
Remove Copy Files step.
Set Path to Publish to $(build.artifactstagingdirectory)\\_PublishedWebsites for Publish Build Artifacts step.
Then you should get the deployment files in the drop folder.
Open the Configuration Manager in VisualStudio and ensure the WebAPI project is included for the configuration (Debug, Release, etc) that you are building.
We use Hedgehog Team Development for Sitecore to manage content items and also want to use it for content deployment.
I am trying to create a TDS build configuration that should deploy TDS items to a remote dev server. Dev server isn’t on my local so I don’t know what I should mention in “Sitecore Deploy Folder” field.
What I am trying to achieve is when any developer / TeamCity builds the TDS project in dev configuration the TDS items should be deployed to the dev site. I can’t create this configuration from the dev server as we don’t have visual studio on the dev server.
I even tried putting the path from the server (this path doesn’t exist on my local from where I am try to set the configuration) but that doesn’t work.
Any directions on this would be much appreciated.
Thanks.
On the Build tab of your TDS project, there are two fields.
Sitecore Web Url This is what TDS will use to connect to the server component to deploy your items.
Sitecore Deploy Folder This is used for two purposes, one to install the aforementioned server component ("connector") and to deploy the output of your web project.
For deployment to a remote server, the Sitecore Deploy Folder needs to be a UNC path to the web root on the server (e.g. \\devserver\share\path-to-webroot), and whatever identity is running the deploy needs write permissions on that share.
I believe TDS only uses this path for deploying the "connector", which consists of the _DEV folder with the web service endpoint and some libraries that are placed into Website\bin.
If you are choosing to use the Deploy feature of TDS for CI, ideally you would deploy the "connector" manually the first time and although there is no use in setting the Sitecore Deployment Folder anymore TDS would not deploy with it blank. Your best bet is to setup a share on a server and use the share path for that setting (i.e. \myserver\share).
As a side note, check out the TDS package installer that comes with the app under C:\Program Files (x86)\Hedgehog Development\Team Development for Sitecore (VS2013). It is possible to set the TDS projects to generate *.update packages for code and content and automate their deployment or deploy them manually - just another way of implementing the CI.
I am using TeamCity as build for Sitecore and TDS deployments. Have a few different configurations depending on packaging needs. (update packages vs. webdeploy, etc).
Our typical approach to this is to create the MSBuild XML file for the configuration directly, which allows me to control the CI builds and deployment distinct from local developer builds.
In this case, the active configuration during build is set to DEV-CM, or TEST-CM, depending on the environment, and I pass in MSBuild parameters for:
IsDesktopBuild=false
GeneratePackages=true (TDS project properties are set to generate separate code/file packages)
SitecoreWebUrl=ht tp://[host]
SitecoreDeployFolder=\[server][share]\website
In visual studio, the DEV-CM and TEST-CM configuration targets are created and configured for the TDS projects to enforce Deployment settings, multi-project packaging dependencies, etc.
This sends the configuration to TDS's portion of the build, generates the packages (which I have published out as TeamCity artifacts) and performs the TDS deploy to the target URL and target UNC.
I would encourage the route of separate build XML files and specifying that XML file as the target script in the TeamCity build step.
We have several web services that we have been deploying "manually" using msdeploy. We pick up the deployment packages from the TFS2010 build machine in the appropriate _PublishedWebsites\<<ProjectName>>_Package directory.
We now want to wrap the deployment packages up with a deployment tool that makes it easier for the person doing the installation to see the parameters.
What we'd like to do is to build the individual web service deployment packages, have the deployment packages land in the right place for the deployment tool build and then have the deployment tool build both build the tool and copy the previously-built deployment packages to the same Binaries drop folder on the build machine.
For some reason, this seems incredibly difficult to do.
Things we've tried
Setting Location where package will be created on the web services project's Package/Publish Web project settings using a variable (e.g. $(TargetDir)). Visual Studio interprets the entered variable and replaces it with the hard-coded path for the development machine... and that's what goes to the build machine. On the build machine the end result is... nothing; the deployment packages are still sent to _PublishedWebsites\<<ProjectName>>_Package.
Setting /p:PackageLocation on as one of the MSBuild Arguments settings on the TFS build definition "Process" / "Advances" section, in addition to /p:CreatePackageOnPublish=true /p:DeployOnBuild=true. All this did was generate the error:
MSB1008: Only one project can be specified. Switch: p:PackageLocation=$(BinariesRoot)\DeploymentFiles For switch syntax, type "MSBuild /help"
presumably because there is more than one deployment package being generated by the build.
Any advice appreciated! Are we going about this the wrong way? Should we be doing something like altering the build XAML to cater for this (like this page suggests for another issue)?
Couple possibilities for you to consider:
1 - Alter the TFS workflow like you've described to perform some copy task
2 - Create an MSBuild project that runs after your standard Packaging steps to copy the output from _PublishedWebsites to some location of your choice
3 - Override the following MSBuild parameter when building the package to change the package drop location:
<DefaultPackageOutputDir Condition="'$(DefaultPackageOutputDir)'==''">$(OutDir)[YourDesiredLocation]\$(DefaultMSDeployDestinationApplicationName)\Package</DefaultPackageOutputDir>
Note that you can see the set of packaging MSBuild parameters available to you at
c:\program files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets
I recently implemented suggestion #2 at a client, using the MSBuild overrides suggested in #3 in the custom MSBuild project file and it worked like a charm.
We are using msdeploy (from VS 2010) to build deployment package of our web project. The problem is that we'd like to include our custom file (for this scenario it is app_config.htm "template" file which will be used for maintenance mode) into that package.
Is it somehow possible to include such kind of custom file into the deployment package ??
In the project properties, section Package/Publish web -> Items to deploy we prefer the option Only files needed to run this application. We don't want to include all files only because of this one (app_offline.html.template) we want to have there.
EDIT solution found here: How do you include additional files using VS2010 web deployment packages?
You could have a look at KwateeSDCM. It's got a pretty good mechanism for overriding standard package (web applications) files with versions that can be customized according to the target server and/or version.
I have a visual studio solution that consists of several web applications, windows services and other class libraries. I am in the process of configuring it for continuous integration with TFS 2010.
The default build template puts every binary in the drop folder, and creates a _PublishedWebsites folder in which it publishes every web application. I do not want that because I need to separate the files that belong to one service from the files that belong to the another service.
I have followed the steps in TFS 2010 BUILD SERVER: Can not keep folder tree in the drop location to put each output in its own folder. That works well, but now my web applications are no longer published. The project is compiles and its binaries are placed in a sub-folder inside the drop folder, but it is missing all the other files, like Web.config, aspx, css, etc.
I could probably use two build templates, one for web applications, and the other one for windows services, but I'd rather have a single build template. How can I achieve this?
Why you don't use separate build process for each web application? Creating multiple build processes and multiple build definitions is very easy. You can copy or branch template process and then create a new build definition for each of them.