HTTPS clone URL
Subversion checkout URL
- Accessing files via ftp
- Accessing the kudu service
- Admin site
- Analyzing a git client trace
- Anatomy of a git request
- Azure runtime environment
- Azure Site Extensions
- Azure Web App sandbox
- Azure Web Sites Development Stacks
- Blog posts and screencasts
- Configurable settings
- Continuous deployment
- Cool user tweets
- Cool WebJobs tweets
- Custom Deployment Script
- Customizing deployments
- Deploy locally built private kudu to azure
- Deploying from github
- Deploying inplace and without repository
- Deploying Perl apps
- Deploying to a server
- Deployment branch
- Deployment credentials
- Deployment Environment
- Deployment hooks
- Deployment Logic Flow
- Deployment vs runtime issues
- Diagnostic Log Stream
- File structure on azure
- Getting started
- Git workflow
- Information about other Azure Web Apps features
- Investigating continuous deployment
- Investigating issues
- Investigating msdeploy ARM failures
- Known issues
- Kudu architecture
- Kudu console
- Kudu deployment configuration prototype
- Kudu deployment script .cmd
- Make sure all your files are committed
- Make sure site correctly deploys locally
- Managing settings and secrets
- Post Deployment Action Hooks
- Process list and minidump
- Process Threads list and minidump gcdump diagsession
- Project governance model
- Project Structure
- Reporting WebJobs issues
- Reporting your site name without posting it publicly
- REST API
- Running tests
- Troubleshooting Node errors
- Troubleshooting PHP errors
- Understanding site swaps
- Using a custom web.config for Node apps
- Using a git repo to report an issue
- Version history
- VSO vs Kudu deployments
- Web hooks
- Web Jobs
- WebJobs API
- Xdt transform samples
Clone this wiki locally
When deploying a git repository via Kudu, the rules for picking a specific project are as follows:
- If there's a .deployment file at the root of the repository go to step 4, otherwise go to the next step.
- Scan for solution files, if there's multiple solutions, fail, if there's 1 solution file go to next step, if none, go to step 6.
- Now that we have a solution, pick the first website or WAP in that solution and deploy it, if there's none, then fail.
- Find the target project file, if there's multiple projects, fail, if there's 1 project file, deploy it, otherwise go to next step.
- look for a website project in the specified folder (by finding a solution that has a website with the same path), if more than one, fail, otherwise deploy the website project.
- Find the target WAP, if there's none then Xcopy deploy all the repository files (excluding .git and .hg) to the web root.
Deployment configuration files let you override the default heuristics of deployment by allowing you to specify a project or folder to be deployed. It has to be at the root of the repository and it's in .ini format. Here are some examples:
You can specify the custom deployment script to build and deploy your application.
Here is an example:
[config] command = deploy.cmd
For other script engine, ..
[config] command = powershell -file deploy.ps1
You can specify the path to the project file, relative to the root of your repo. 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
If the folder you want to deploy is not the root of the repository, you can specify which folder to deploy. e.g.
[config] project = MyWebRoot
In case you have a solution/project file in your repository but you want it to be ignored and have your full repo deployed as a web site, you can use the following (e.g. Orchard use this):
[config] project = .
One downside of using a .deployment file is that it is committed to the repo, and sometimes you want to make that selection outside of the repo.
Let's say that you have one repo that contains two different ASP.NET projects (possibly in the same solution), which you want to deploy to different sites. You couldn't use a .deployment file here, as it can only point to one project.
Instead, you can use App Settings to set the same values that are supported in the .deployment file. The steps are:
- Go to the Configure tab for you site in the Azure portal
- Add an App Setting called
Project, and set its value to something like
- Then in your other web site you can set
Projectto point to a different .csproj file.