Using the Azure publish wizard gives you some options for changing your config settings, but not enough. You can tell it which build configuration to use (which will apply a transform to your web config) but you only have 2 choices. Release and debug. Also you can specify which cloud service configuration to use which will transform your service.config but again only 2 choices Cloud and Local.
My problem is that I have 3 different versions of my application running in Azure. They are Dev, Demo, and Production. Each has their own database, storage accounts, and other settings related to authentication. Just having a release and debug transformation doesn't cut it.
Really what I would like is to have a script or something so that I could publish my app to each of my Azure instances. It would change my web.config and service.config and target the right azure instances.
Any suggestions are appreciated.
There used to be CodePlex project http://wappowershell.codeplex.com/, which now became an official tool here: https://www.windowsazure.com/en-us/manage/downloads/.
It's a set of Windows PowerShell cmdlets for managing Azure deployment.
Also the following question is pretty similar: Publish Azure Project from Command Line
In researching this I updated my Azure Tools to the October release. Not sure if these options were available in old release or not but here's what I ended up with.
As it turns out can add your own services configurations and build configurations in addition to the default ones (cloud/local/debug/release).
Services configurations can be added by:
Right click your Web role from your cloud service project and select properties.
At the top of the properties window open the Service Configuration menu. Then select manage.
Select a configuration and click the create copy button.
Select the copy and rename it to whatever you want.
Click close and now you should be able to have settings specific to your new service configuration.
Build configurations can be added by (I followed this blog post):
Select Build -> Configuration Manager from the menu. The
Configuration Manager dialog
Select from the Active solution configuration dropdown list to bring up the New Solution Configuration dialog.
Enter the name and select the configuration you want to copy. Click Ok.
Make sure you select the correct Configuration (release or debug) for each of your projects for your new solution configuration.
Notice there is still no web.config transform. To add a new Web.config transformation right-click on the Web.config file and from the menu select Add Config Transforms. Notice that a new configuration file matching your new configuration is automatically added
After following these steps I was able to create a new target profile in the Azure publishing wizard and select these configurations. This lets you automate your web.config settings using transforms and have your own custom cloud service configuration per publishing profile.
Here is another excellent reference that goes into much more detail then I was able to for this question.
Related
My ASP.NET MVC project pushed to a Azure website with an extra DLL which is invalid. This is keeping the project from running correctly. If a new website is created it works perfectly. Cleaning the project locally and redeploying does not fix the problem. Is there a way to perform a "remote clean?"
This project is being deployed directly from Visual Studio with the publish menu item.
When you right click and click Publish Web on the left hand side there should be a settings tab. Click this. Then expand the option under File Publish Options and check the Box for Remove addtional files at destination. (This will wipe out whats already there)
Also can be detailed here: MSDN
Another trick to delete an entire Azure website deployment which can be done entirely in the Azure portal is:
1) Create a new empty deployment slot under the Azure website.
2) Swap it with the parent Azure website.
That will give you an empty Azure website. If you want you can delete the deployment slot afterwards.
You can also use console to delete any file. Kudu is a web tool that allow you to see inside of Azure web application.
Two ways to access Kudu
go here: https://yoursite.scm.azurewebsites.net/DebugConsole/?shell=powershell (replace with your real website name)
login to portal > app services > your site > Development tools > Advanced tools.
You can also delete files via Webmatrix (link in footer menu in Azure configuration portal)
Download the profile from Azure portal
Import publish profile in VS
Stop the web app in Azure portal
Stopping the web app ensures existing files including dlls and other resources will be deleted after publish succeeds.
This step might not be necessary, however, the existing web app could have some dlls that cannot be removed during publish directly, returning error messages like:
Web deployment task failed. (Unable to perform the operation ("Delete
File") for the specified directory ...
4. Publish with “Remove additional files at destination” checked
Start the web app again after publish succeeds.
for linux servers you dont get, CMD, then all you have to do its, Delete the deployment, then create deployment credentials for FTP and there you go with FTP client clean the wwwroot folder by your self.
I need some assistance with developing custom activities for TFS build. I have followed the steps in blog post Customize Team Build 2010 – Part 7: How is the custom assembly found?.
I have created a custom activity built into a DLL file and used in build template. I want to set it up in the TFS build now, but I have run into some issues. In the blog it suggests that the custom activities DLL file be referenced via the build controller. However, this is an issue for me. I work in a company where there are numerous projects and all use the same build controller. Therefore I don't have the permissions to make the change suggested in configuring the version control path to the custom activity.
Is there are another option open to me? Is there another way I can reference the custom activities? In the build template maybe?
You need to get that assembly onto the build server (build agent server assuming the activity is only used within the Run On Agent activity).
The most convenient option is to simply check it into the TFS folder that the build controller is pointing to for build assemblies, and the controller will automatically push it out to all build servers.
Alternatively, if you have direct access to the Build Agent Server(s) you can manually install the assembly onto the server into the GAC.
After much messing around I've got CI implemented onto our test server. A custom workflow template builds and deploys 2 web apps (different servers), a database and a windows service. This is brill and takes all the worry out of deploying a test app.
I want to move this over to staging and live (queued manually), but doing it like this the TFS service account would need permissions on IIS for the web apps, DBOwner on the database and local admin on the service box. This is a big no-no for our tech guys!
What we could do is just give these permissions before we run the build and remove afterwards, but this means maintaining a list of what permissions to change where - ruining the convenience of one-click deployment a bit.
Ideally we'd just get the build to run using the account of the tech services guy whos got admin network-wide, is there a way to do that?
Yes you can do that via the TFS Administrator Console.
If you haven't configured your build machine, then you can choose the user during the configuration phase. You should see a Configuration Wizard page that allows you to choose a user account like this:
If your build machine is already configured, go to your build machine, then run %PROGRAMFILES%\Microsoft Team Foundation Server 2010\Tools\TfsMgmt.exe, then go to "Build Configuration", click at "Properties" link of the Build Service to open the Properties dialog, then click "stop to make changes" on the dialog, and you can change the account from the built-in account to a user one:
Ok, so I'm a total newbie to TFS and automated builds. I see how to set up a CI build in TFS pretty easily, along with the drop folder for output files. However, my solution has two UI projects in it. One is our main website, the other is a mobile site.
When developers check in, basically what I want to happen is for a CI build to fire, and then publish the "mobile" project to one server and the "website" project to another.
On a very high level, what steps do I need to take to make this happen? I'm not looking for a detailed explanation, I can Google individual things as needed I just want to know the basic process and what tools are leveraged to make this happen.
The easiest way would be to have two different builds set up to fire on check in.
First, in your configuration manager create two new configurations. One for the Mobile site and another for the main website. The mobile site configuration shouldn't bother to build the website and vice versa.
Then create two builds. For each build, set the 1.Required > Items to Build > Configurations to Build settings to pick the appropriate config to build.
Update your deployment locations as necessary.
I'm just getting started with the team build functionality and I'm finding the sheer amount of things required to do something pretty simple a bit overwhelming. My setup at the moment is a solution with a web app, an assembly app and a test app. The web app has a PublishProfile set up which publishes via the filesystem.
I have a TFS build definition set up which currently builds the entire solution nightly and drops it onto a network share as a backup of old builds. All I want to do now is have the PublishProfile I've already setup publish the web app for me. I'm sure this is really simple but I've been playing with MSBuild commands for a full day now with no luck. Help!
Unfortunately sharing of the Publish Profile is not supported or implemented in MSBuild. The logic to publish from the profile is contained in VS itself. Fortunately the profile doesn't contain much information so there are ways to achieve what you are looking for. Our targets do not specifically support the exact same steps as followed by the publish dialog, but to achieve the same result from team build you have two choices, I will outline both here.
When you setup your Team Build definition in order to deploy you need to pass in some values for the MSBuild Arguments for the build process. See image below where I have highlighted this.
Option 1:
Pass in the following arguments:
/p:DeployOnBuild=true;DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder;PackageTempRootDir="\\sayedha-w500\BuildDrops\Publish";AutoParameterizationWebConfigConnectionStrings=false
Let me explain these parameters a bit, show you the result then explain the next option.
DeployOnBuild=true:This tells the project to execute the target(s) defined in the DeployTarget property.
DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder: This specifies the DeployTarget target.
PackageTempRootDir="\\sayedha-w500\BuildDrops\Publish": This specifies the location where the package files will be written. This is the location where the files are written before they are packaged.
AutoParameterizationWebConfigConnectionStrings=false: This tells the Web Publishing Pipeline (WPP) to not parameterize the connection strings in the web.config file. If you do not specify this then your connection string values will be replaced with placeholders like $(ReplacableToken_dummyConStr-Web.config Connection String_0)
After you do this you can kick off a build then inside of the PackageTempRootDir location you will find a PackageTmp folder and this contains the content that you are looking for.
Option 2:
So for the previous option you probably noticed that it creates a folder named PackageTmp and if you do not want that then you can use the following options instead.
/p:DeployOnBuild=true;DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder;_PackageTempDir="\\sayedha-w500\BuildDrops\Publish";AutoParameterizationWebConfigConnectionStrings=false
The difference here is that instead of PackageTempRootDir you would pass in _PackageTempDir. The reason why I don't suggest that to begin with is because MSBuild properties that start with _ signify that the property in essentially "internal" in the sense that in a future version it may mean something else or not exist at all. So use at your own risk.
Option 3
With all that said, you could just use the build to package your web. If you want to do this then use the following arguments.
/p:DeployOnBuild=true;DeployTarget=Package
When you do this in the drop folder for your build you will find the _PublishedWebsites folder as you normally would, then inside of that there will be a folder {ProjectName}_Package where {ProjectName} is the name of the project. This folder will contain the package, the .cmd file, the parameters file and a couple others. You can use these files to deploy your web.
I hope that wasn't information over load.
The ability to publish web sites, configure IIS and push schema changes for the DEV->QA->RELEASE cycle has required either custom configuration to imitate publish or custom code where IIS settings are involved.
As of Visual Studio 2013.2 Microsoft has added a third party product that manages deployment of web sites, configuration changes and database deployment with windows workflow and would be the recommended solution for automating deployment from TFS build.
More information can be found here:
http://www.visualstudio.com/en-us/explore/release-management-vs.aspx
You can use the Publish/Deploy in Visual Studio 2010.
See http://www.ewaldhofman.nl/post/2010/04/12/Auto-deployment-of-my-web-application-with-Team-Build-2010-to-add-Interactive-Testing.aspx for more information