I have configured a cloud service to run multiple web applications in one web role. More information on this is in the documentation.
The documentation does not appear to be correct for local builds with the Azure 2.3 SDK. Apparently, since SDK 1.8, the physicalDirectory attribute is not relative to the Azure cloud service project folder, but its output folder. Also see this question. By changing the path to ../../../Project.Name the service can be built and deployed locally from VS2013 with SDK 2.3.
We also use continuous integration on Visual Studio Online. However, the project now fails to build with the message that the path to my second web project is invalid. The path it's trying to use is C:\Project.Name\. I don't think this is quite correct.
I have tested with ../Project.Name as the physicalDirectory attribute value on VSO, but that also fails.
Is it a matter of somehow correctly configuring this for Visual Studio Online, or is it simply not currently supported?
Related
I have a Visual Studio solution that contains two web applications (our main site and our WebAPI project). I am able to host them locally in IIS Express as a single site using the applicationhost.config, but I want to package them (in our Build) and then deploy them (in our Release) as a single site from Visual Studio Online (which hosts our code) to Azure.
My Visual Studio Team Services Build configuration packages each of the Visual Studio projects into its own Web Deploy package. The Web Deploy packaging is done during my Build phase, and the deployment to Azure is done during the Release phase - this is done so I am not recompiling source every time I do a deployment, which is unnecessary and would slow down the process.
The first web application identifies "HelloAzure" as the DeployIisAppPath in its pubxml file. The second one (the WebAPI project) identifies "HelloAzure/api" as the DeployIisAppPath in its pubxml file.
Currently, I am using two of the "Azure Web Site Deployment" steps (the one that uses Service Endpoints to perform a deployment). I name the same web app name for both steps. When the second project is deployed, it seems to overwrite the first one rather than adding a second application to the existing site. I believe I must not be following the intended practice for deploying several Web Deploy packaged applications into one web site from Visual Studio Team Services to Azure, but I can't find the recommended practice documented anywhere.
I do need to have both applications hosted within a single site. Deploying them as separate sites is not an option.
It appears that Kudu has some options that might support this scenario, but I am not deploying from source code, I am deploying from Web Deploy packages created by our Team Services build.
The MSDeployAllTheThings VSTS extension supports deployment to a virtual app in an Azure site.
https://marketplace.visualstudio.com/items?itemName=rschiefer.MSDeployAllTheThings
Microsoft also seems to have added official support for deploying to virtual apps from VSTS to Azure to the AzureRM VSTS extensions according to this thread: https://github.com/Microsoft/vsts-tasks/issues/624
Currently our developers deploy our Mobile Service (.Net backend) from Visual Studio 2013 using the Publish Wizard. Occasionally this means that a developer deploys something that either wasn't committed at all or wan't pushed to the origin source control repository. We are already using Visual Studio Online Build servers to do Continuous Integration from the origin server so it would make sense to use the files it builds to do the deployment to remove this risk.
Currently the only way I can see of doing this is to do a "download drop as zip" from the Visual Studio Online build portal and then do a FTP style deployment. This means I lose the web deploy features of only uploading the changes.
I noticed there is a different build template called GitContinousDeploymentTemplate which allows you to specify a Windows Azure Deployment Environment, but this seems to only be applicable for traditional Cloud Services or Web sites.
If anyone knows a good way of doing this any help would be much appreciated.
Cheers
F
From here
Found a solution.
In the build definition's MSBuild arguments, add the following:
/p:DeployOnBuild=true /p:PublishProfile="{publish name}"
/p:AllowUntrustedCertificate=true /p:VisualStudioVersion=12.0
/p:UserName={username} /p:Password={pw}
You can obtain the value from the publishing profile that can be downloaded from the
Mobile Service dashboard on Azure managament portal.
Under Deployment, add the path to pubxml file in source control under "Path to Deployment Settings". Note: add an extra backslash at
the end of the path to escape the last "\".
One problem with this solution is that deployment happens regardless
of your tests outcome, but that could possibly be remedied by
modifying the build template. We used the
GitContinuousDeploymentTemplate template in our case.
While using Github (or anything other than Visual Studio Team Services) I can use the following page to customize deployment: https://github.com/projectkudu/kudu/wiki/Customizing-deployments
I'd like to customize my deployment as I currently have both a web app and a web api project. I want the web app to be deployed, as default it deploys the web api project. Using project Kudu the settings (.deployment file or even better, the app settings on Azure itself) works great, but not when you deploy from Visual Studio Team Services.
I've spoken with David Ebbo from Project Kudu, and he explained that VS Team Services doesn't use Kudu at all, but probably MS Build. So my question is, how to specifically deploy the web app.
I managed to change the Build Definition and specify the web app .csproj as the Projects To Build. This works. However, I also want to deploy my web api.
Deploying the web api project with Kudu is easy as I can create a separate website, connect to the some repository (and solution) and specify the Project App setting so that it deploys the correct .csproj. How should we do this for MS Build? When I change the Build Definition, it will always deploy the project specified in there.
Just saw another answer on Stackoverflow that looks to solve this problem: Publish Multiple Projects to Different Locations on Azure Website
I have two ASP.NET MVC 4 projects created in VS2012. For each, I created an Azure deployment project and they are both deployed successfully to Azure. I got a new dev machine and started fresh with only VS2013 installed, hoping that, as advertised, I wouldn't have to go through the pain of migrations that would make the projects tied to this version. Well, that didn't turn out true, as Azure projects must be upgraded to v2.2 of the Azure .NET tools and API to be opened in VS2013.
On the first project, I installed the 2.2 tools and with a few other relatively minor adjustments, the project works fine. Now, on the second project, however, I can find no way to perform the upgrade. When I opened the project in VS2013, it gave me a migration report saying that the Azure project was incompatible and the only solution offered was to install the 2.2 tools, which of course, has already been installed. I then decided to remove the existing azure deployment project and create a new one as I did before on vs2012, by right-clicking on the web project and choosing "Add Azure deployment project", which wires everything up automatically. Well, that menu item does not appear in the context menu on the web project.
Now, I'm at a loss for how to resolve this, other than installing VS2012 and forego taking advantage of the advances in VS2013. Does anyone have any suggestions how i can get an Azure deployment project working with this project?
(BTW, this is a must, because I am using the azure api to get config items out of the azure config.)
I had the same issue. I solved it by installing the 2013 version of the Azure 2.2 SDK (found here). After doing this I was able to build and run the solution (without any conversion) in both VS2012 and VS2013.
UPDATE:
Try to add a new Azure Cloud Service project to your solution by right-clicking the solution > Add > New Project.
Under templates there should be a section named 'Cloud' with a project template named Windows Azure Cloud Service. When you select this template you should get a dialog where you can add Azure roles to your solution.
If you select ASP.NET web role, a new Web project will be created in your solution. If you don't select anything, you will get an empty Azure project to which you can add your existing MVC project (WebRole Project > Right click Roles > Web role project in solution).
Im new to Azure and wanted to create a Continuous Integration build using TFS. I created a build definition but building my Cloud App with simple website using a hosted buildserver in the build definition fails with error:
C:\a\src\myAzure\myAzure\myAzure.ccproj (70): The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Windows Azure Tools\2.0\Microsoft.WindowsAzure.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
I can however build locally, and manually Publish to Azure and it will deploy fine.
Im suspecting that the hosted buildserver of TFS does not support Azure 2.0?
Is there a way around this problem or will I have to forget the idea of using CI?
Seems to be so since the Build is a preview feature of the Team Foundation Service. There was the same thing with Azure SDK 1.8, but they updated the Build Servers in a couple of days. Hope that it will not take long this time.
UPDATE:
"No, TF Service hosted build machines do not have the new SDK 2.0 at this time. We expect all users to have Azure SDK 2.0 support post June 1st. In the meantime you will need to use an on-prem build controller with the bits you need and deploy to Azure from there."
(C) Trevor Hancock from Microsoft
http://social.msdn.microsoft.com/Forums/en-US/azuretfs/thread/2df796d5-1abb-4b89-a571-0b7a62b80d55
UPDATE 2:
I've managed to complete a successful build using TFS build servers with SDK 2.0 So I think this problem is resolved for now. In future I recommend not to do updates to new versions of Azure SDK until the TFS build servers are ready.