Getting started
Pages 74
- Home
- Accessing files via ftp
- Accessing the kudu service
- Admin site
- Analyzing a git client trace
- Anatomy of a git request
- App Service Editor
- Azure runtime environment
- Azure Site Extensions
- Azure Web App sandbox
- Azure Web Sites Development Stacks
- Blog posts and screencasts
- Configurable settings
- Continuous deployment
- Contributing
- 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
- Deployment branch
- Deployment credentials
- Deployment Environment
- Deployment hooks
- Deployment Logic Flow
- Deployment vs runtime issues
- Diagnostic Log Stream
- File structure on azure
- Full stopping a Web App
- Functions API
- Getting started
- Git workflow
- Information about other Azure Web Apps features
- Investigating continuous deployment
- Investigating issues
- Investigating msdeploy ARM failures
- Isolating WebJobs and Deployment script issues
- 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
- Manually triggering a deployment
- MySQL in app (preview)
- 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
- Setting up a VSTS account so it can deploy to a Web App
- Test your ASP.NET Core repo locally
- 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
- VSTS vs Kudu deployments
- Web hooks
- WebJobs
- WebJobs API
- Xdt transform samples
- Show 59 more pages…
Clone this wiki locally
Prerequisites to run Kudu and functional tests
We have recently created a few custom scripts to automate the setup of Kudu development dependencies see the readme for KuduDevSetup.cmd for details. The new approach has been minimally tested so the older manual instruction below are still worth reading to understand what the new script does. The script requires that WebPI 4.5 be installed. Once you have WebPI install simply execute the script from the directory.
- To fully run functional tests, you will still need to manually execute first two steps from Additional prerequisites to run the functional tests
Manual Setup Instructions
- Visual Studio 2015. Note that you need to run it as admin. Install/Update to the latest version of NuGet Package Manager (Tools -> Extensions and Updates).
- IIS >= 7, configured to run ASP.NET 4.0. This can be installed using WebPI.
- Install Git (http://git-scm.com/downloads) to the default location (we expect it in
C:\Program Files (x86)\Git\bin). - Install Node. Node is used as part of the build process for sites.
Note: If you manually install IIS, here is what needs to be enabled:
Additional prerequisites to run the functional tests
- If you don't see the tests in Test Explorer pane, it may be because you have Xunit runner install as VSIX. For Xunit 2.0, the runner is installed as part of the project (not VSIX). To fix, open VS -> TOOLS -> Extensions and Updates ..., and uninstall Xunit runner VSIX.
- If still don't see the tests, try remove this folder
%TEMP%\VisualStudioTestExplorerExtensions. See this.
You are done here if you had run KuduDevSetup.cmd, otherwise continue.
- Install MVC 3. After installing, ensure KB2993937 is installed by running Windows Update or downloading it directly from here.
- Install ASP.NET WebPages 1.0.
- Install F#. This can be done during a Visual Studio install or from within Visual Studio, or you can install it directly from here.
- Open your %WINDIR%\System32\inetsrv\config\applicationHost.config and look for
<applicationPoolDefaults>. Under<processModel>, make sure you don't havesetProfileEnvironment="false". If you do, set it to true (or remove the attribute if you are running the latest Windows 8.1). - Unzip this file and copy the contents into your
\Program Files (x86)\MSBuild\Microsoft\VisualStudio. This brings in various files from older VS versions that you may not have installed. - Install the URL rewrite module for IIS.
- Install IISNode
- Pretend to have the 32 bit version of Node to fool the version detection logic:
- Copy your
\Program Files\nodejsfolder to \Program Files (x86)\nodejs. - Under
\Program Files (x86)\nodejs, you need to have a folder named0.8.2, and containing node.exe version 0.8.2. And then same deal for Node 0.10.5 (you can put the 0.8.2 exe in the 0.10.5 folder; it's the folder that matters). Yes, this is kind of painful, and we need to make it easier!
- Copy your
- Install Mercurial to the default location (we expect it in
C:\Program Files (x86)\Mercurial) - Install HttpPlatformHandler (x64 msi) for ASP.NET 5 support. If you're running Windows 32bit you'll need the x86 version.
Deploying your first application
-
First clone the repository.
git clone git://github.com/projectkudu/kudu.git Run build.cmd. During development, builds can be run from within Visual Studio, but this ensures you have a Release build and that the KuduSync.NET package dependency from the solution-level packages.config file is in place.
Open Kudu.sln as Administrator and build it.
Set Kudu.Web as the startup project and run!
After running Kudu.Web, you should be able to use the dashboard to manage your application. Below is a walk through on how to create and deploy your first application using git.
Step 1
Create an application.
Step 2
Give it a name.
Step 3
Copy the git url and push.
Step 4
You're live!




