I have recently set up Automated builds using TFS Build 2012. I have different web servers where I want to publish my application. I have:
1) A build server.
2) DB Server
3) WebServer1 (Web Deploy Agent Installed)
4) WebServer2 (Web Deploy Agent Installed)
5) WebServer3 (Which is the same on which I have set up TFSBuild i.e. build Controller and Agents)
Now when ever I Publish my application manually using RightClick->Publish(Publish Method= Web Deploy) from VisualStudio it is successfully deployed to all the webservers.
Similarly when I QUE a build using TFS Build for WebServer3 (which has BuildController and agent on it) it works fine.
But when I try to do the same for WebServer1 or WebServer2 it just compiles the code and DONT publish anything on server. The worst thing is that it it NOT giving me any error as well. It says Build was deployed Successfully.
I have tried solution posted here but its not working :(
Any help would be highly appreciated. Thanks in advance.
EDIT:
My MSBuild arguments are as follows:
/p:VisualStudioVersion=11.0
/p:DeployOnBuild=True
/p:DeployTarget=MSDeployPublish
/p:MSDeployPublishMethod=WMSVC
/p:AllowUntrustedCertificate=True
/p:PublishProfile=Application
/p:MsDeployServiceUrl="https://WebServer3"
/t:Build;Publish
/p:SqlPublishProfilePath=DB.publish.xml
I have explicitly asked set /p:DeployOnBuild=True but even then its not publishing.
However like I explained earlier it deploy successfully for the sever on which I have installed the build controller and agents.
Is there any requirement that for every webserver you must install the build controller and agents. I dont think its a good idea.
Ultimately I figured out what was wrong.
The problem was that there was no Build Controller Agent Installed on WebServer1 and WebServer2 due to which the TFS build was unable to transfer my build to that server. But there MUST be some error for this.
I tried it after installing the build controller agent on webserver1 and webserver2 and it worked !
We worked a whole chapter in the Build Customization Guidance: "Deployment of Applications and Data Stores".
Create a Build Definition for each web server and set the correct value for
MSDeployServiceUrl
This is the address of the remote agent service installed in the Web Deploy. Using this URL the Web Deploy will be contacted to publish the application.
Related
I am currently working to move TFS from its' current server to a new environment. My team has already completed the steps as seen in this Microsoft Documentation on moving TFS to a new Server.
We have already installed and migrated/restored our SQL Database in the new server and ensured all the prerequisites for TFS were installed. The TFS Admin Console is currently installed and we are trying to configure it by using the existing Tfs_Configure database. That all works without a problem, however, when we go to look at our existing Project Collections, the build service is still "linked", having the TFS Address set to the old server and not the one we migrated to.
I have detached the collections in the old environment and reattached them in the new environment, however, they still seem to be trying to build in the old server. I am reading that we needed to detach them prior to migrating any data over. Did we do something incorrectly, or rather, did we try to detach the collections too late into the process?
You need to unregister the build service that uses the <<oldcomputername>>. Register a build service with the <<newcomputername>>. And do the same for the agent and the controller.
On each build server, open the administration console and stop the
build service.
In the properties for the build service, update the communications
properties.
According to the above screenshot, you could see the build service is configured under project collection level.
Moreover, for vNext build agent you need to remove and re-configure an agent.
To remove the agent:
.\config remove
After you've removed the agent, you can configure it again.
You have to update your build services to point to the new server. For XAML build, you'll have to reconfigure the build controller. For the modern build system, you'll need to reconfigure your build agent(s).
I have a build in Team Services (was Visual Studio Online), with one MSBuild step that is configured to build and deploy a DB project, using a publish profile. I can't seem to succeed in authenticating it. When I queued the Team Services build definition, I am able to build the DB Project and produce the .dacpac. However, come publish time and this error comes:
C:\a\1\s\Source\ShopDatabase\bin\Output\MyDatabase.publish.sql(0,0): Error Deploy72002: Unable to connect to master or target server 'mydb'. You must have a user with the same password in master or target server 'mydb'.
We're certain the user exists in the mydb and the master db in Azure.
Target: Azure SQL Database
DB project Target Platform: Microsoft Azure SQL Database
When I run the publish profile directly from Visual Studio, it works. But in Team Services build definition, it doesn't. I tried these as MSbuild arguments:
/t:Build;Publish /p:SqlPublishProfilePath="myproject.Dev.publish.xml" /p:Password="mypassword"
and this:
/t:Build;Publish /p:SqlPublishProfilePath="myproject.Dev.publish.xml" /p:TargetConnectionString="Data Source=myproject.database.windows.net;Persist Security Info=True;User ID=myuser;Password=mypassword;" /p:VisualStudioVersion=14.0 /p:Username="myuser" /p:Password="mypassword"
and this:
/t:Build;Publish /p:SqlPublishProfilePath="myproject.Dev.publish.xml" /p:TargetConnectionString="Data Source=myproject.database.windows.net;Persist Security Info=True;User ID=myuser;Password=mypassword;" /p:VisualStudioVersion=14.0 /p:TargetUserName="myuser" /p:TargetPassword="mypassword"
But won't work. Please help me T_T been searching the net for 6 hours already
This is a poor error message that likely disguises the real issue: you need to open up your firewall for deployment to Azure SQL DB. It's working from Visual Studio because you have your IP range enabled. The steps in this guide to building & deploying from VSO, specifically the post on deploying from VSO here, should help. it specifically covers how to open up the firewall as part of deployment.
An obvious answer (sometimes in hindsight!) but for future googlers the error You must have a user with the same password in master or target server
also happens if you are pointing your deploy to an instance that doesn't exist.
ie: Server was not found.
Fwiw, was generating a script from visual studio. Running as admin made it stop being a douche about this. What a waste of my life just now...
We recently had this issue and we resolved it by removing the #server-name from the end of the Server Admin Login value in the SQL DB Details section of the SQL Deploy VSTS Task. Some guides online say you need this but it appears something changed recently and it is no longer required.
A website with webjob not deploying to Azure.
I am having an issue getting a website with an associated webjob console application to deploy using continuous deployment via Visual Studio Online. I am using VS2013 with update 4 and latest Azure SDK.
The website, and the associated webjob, will publish to Azure using direct publish for Visual Studio and works perfectly, so I am confident the publish settings are fine.
The solution will build and work locally fine.
The solution, once checked in, will build and (seemingly) deploy fine in VSO (using CI) and Azure notes the build was successful and shows it as 'Active deployment'.
However, the website and associated webjob will not be updated.
When I have browsed the deployed files after the VSO build and deploy on Azure, all that is happening, is the binaries of the console app are being copied into the bin/ folder of the website.
None of the website files are being updated. It is almost as if it is deploying the wrong project!
If I remove the Webjob and just deploy the website, it will build and deploy fine through VSO - the website will update.
It is adding the webjob that causes some issue with the deployment via VSO.
I am confident all steps are correct to add the webjob to the WebApp, with the correct webjobs-list.json being added to the webapp and webjob-publish-settings.json to the Console app - as I said, publishing the website (with the webjob) direct to Azure works perfectly, and both the site and webjob get updated.
I have searched post after post and tried all manner of things, but none have worked.
Given the fact this published fine direct from VS, and also that the build is completing, it would suggest that something is wrong with the VSO Build Defintion.
My first guess would be to change it from building the solution to instead building the web project only, but this does not seem to work.
I have also tried every Output location setting (both for the solution build and the web project build) - the only one that works and the build completes is the solution (.sln) build with 'SingleFolder' set.
I have been battling this for a couple of days now an I'm a bit stumped!
This also happens if you have a static website being deployed using a Visual Studio solution via VSO with an automated build - unless the Visual Studio project / solution containing the website is changed then the actual site contents will not be redeployed.
I think your hunch that it's deploying the wrong project is correct. If you have multiple "deployable" projects in your solution (and the console app is considered deployable, as this is one way you can host/deploy a webjob), you need to tell Kudu which one to deploy.
You can control it adding a new setting under "app settings" on the "configure" tab for the webapp.
The setting you want is Project and it's a relative path from the solution root to the .csproj file of your web project.
Alternatively, you can specify the setting in a custom .deployment file.
Relevant Kudu documentation here
From the documentation:
You can specify the full path to the project file. Note that this is not a path to the solution file (.sln), but to the project file (.csproj/.vbproj). The reason for this is that Kudu only builds the minimal dependency tree for this project, and avoids building unrelated projects in the solution that are not needed by the web project.
Here is an example:
[config]
project = WebProject/WebProject.csproj
I have also tried every Output location setting (both for the solution build and the web project build) - the only one that works and the build completes is the solution (.sln) build with 'SingleFolder' set
That's the root case of problem.
You can't have SingleFolder as it sets the OutDir which mess up with web job packaging.
I had to introduce a wpp.targets files in each of my web app project to create the publish package to a particular path (using PackageLocation)
So, let each project have that and set the setting to AsConfigured (or Per Project) instead of SingleFolder.
See this
I'm using Visual Studio 2012 and the publishing feature. I have created a publishing profile that deploys my application to a development server, and it works great when executed from vs2012 on my machine. Here is my problem; on the development server I also have TeamCity installed and I would like to trigger the publishing after a build have completed. So I created a simple build step that looks like this:
Build file path: .\src\Solution.sln
Targets: Rebuild
Command line parameters: /p:DeployOnBuild=true;PublishProfile=Ci
When this step is executing I get the following error:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.targets(4377, 5): error ERROR_USER_NOT_ADMIN: Web deployment task failed.
(Connected to 'dev.domain.com' using the Web Deployment Agent Service, but could not authorize. Make sure you are an administrator on 'dev.domain.com'.
The Ci profile contains a username and password that works when I run the publishing from Visual Studio on my machine. I have also tried passing in username and password as parameters in the build step, but I get the same result. Do I need to run the TeamCity services under admin accounts to get this working? All suggestions are appreciated.
I have just blogged about this at http://sedodream.com/2013/01/06/CommandLineWebProjectPublishing.aspx.
You are pretty close, hopefully I can close the gap.
You are correct that username and password are specified in the VS publish dialog, but we do not save the password in the .pubxml file. It is currently being saved in the .pubxml.user file, and that file is not used at all for command line scenarios. Because of that you will need to pass in the property. So in your case it should be
msbuild .\src\solution.sln /p:DeployOnBuild=true /p:PublishProfile=ci /p:Password=<insert-password>
If your web server does not have trusted certs you may need to also pass in /p:AllowUntrustedCertificate=true.
One little addition which may not be directly related to your issue, but may be helpful for others which may see this later.
If you are building the .csproj/.vbproj file (and potentially in some scenarios where the .sln file is used) you should pass in the property /p:VisualStudioVersion=11.0. More info on this available at my blog http://sedodream.com/2012/08/19/VisualStudioProjectCompatabilityAndVisualStudioVersion.aspx
Environment: TeamCity 6.5.1 on Win2k3, BuildAgent(s) on Win2k3, Visual Studio 2k10, .NET v4, Nant 0.91
I'm completing the setup of TeamCity and am trying to lock down the BuildAgent account on the build machine(s) per our security guidelines. The build is crashing the first time "devenv.exe /build" is called via the Nant script:
Faulting application devenv.exe, version 10.0.30319.1, stamp 4ba1fab3,
faulting module msenv.dll, version 10.0.30319.1, stamp 4ba1fd94,
debug? 0, fault address 0x0000c36b.
I had no luck googling that message. However, if I change the BuildAgent Service from the Local Network Account to the Administrator account, things work. However, if I use another domain account, it fails. Also fails if I add that domain account to the local Administrators group.
Any ideas on what I'm missing? Is there a specific privilege you need to have in order for a "DevEnv /build" to work without crashing?
Yuck, I just went through this recently. First, use devenv.com, not devenv.exe. The devenv with the com extension can build a solution and send all output to the console, without using the gui. As the TeamCity agent is a service, it may not be allowed to interact with the gui at all.
Second, and I realize that this might not be possible for you (especially if you are building an MSI), but consider doing whatever you need to do to use the built in Visual Studio build runner that comes with TeamCity. It does utilize MSBuild to do its work. If you go this route and you still need devenv, then go find MSBuild Extensions Pack, which has already solved a lot of these issues with their own devenv build task.
Honestly, I ended up replacing Microsoft's installation projects with alternatives (InstallShield or WiX), and never looked back.