I have a solution in visual studio 2013. It has two projects in it. One is an mvc web app and the other is the models and other core components that the mvc web app requires.
I have this solution checked into a Visual Studio Online git repository. All the projects are in the same repository.
I have the solution connected to an Azure website for continuous deployment.
The solution builds correctly. However, when it comes time to deploy, instead of deploying the mvc web app, it deploys the core component project.
Anybody come across this and have a solution?
It deploys the first project in the solution (the first one alphabetically).
So you either need to put your MVC project in its own solution and configure the Azure Continuous Deployment for that or make sure you MVC project is alphabetically first in the solution.
Not a great solution but that is just the way it works at the moment.
Related
I want to fully automate the deployment of a web application using VSTS. I have a sample azure application and I want to create a build definition on it that contains building the solution, running unit tests, and deploying it over azure on IIS as its build steps. I am new to VSTS, I am finding it hard to automate the deployment using VSTS. Seeking some help on how to create the above build definition. Any slightest guidance will be helpful.
Madhur,
You will find step by step up to date examples on the Visual Studio website:
Build and deploy your ASP.NET 4 code to an Azure web app
Deploy ASP.NET apps to Azure web apps
First create a build definition to test and package you web app.
Second get familiar with release definition to deploy it on Azure. Or if you just want to do it in one place you can have everything in your build definition, it's up to you.
Also when creating a build or release definition on VSTS, the templates offered are very useful, everything is done so you juste have to feel the gaps. I advise you to take a look at it.
Ive written up a walkthrough of this process at my blog site, its for an asp.net core app but the principal is the same for a normal .net framework one, in fact its even easier because you just choose the Visual Studio Build template when creating the build definition. My walkthrough also takes you through how to deploy the Azure resources you need to host the website - its good practise to use infrastructure as code for these, and maintain that code in the same way you treat source code, with CI and CD processes.
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
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).
We have built a small MVC4 application using Azure Cloud Services. It has been deployed through Visual Studio. Now we are going add a test environment where the application should be tested, before being deployed into production.
I would like to have our CI server to build, test and create a deployable package, This package could then be deployed to any environment, providing correct configurations.
But I have not found a convenient way to do this. It is easy to build a package for a specific environment, with configuration transformations for .config and .cscfg files.
Is having the CI server to build a separate package for each environment the way to go, or have I missed something?
There are ways described how the web.config could be modified when the WebRole is starting, but this feels a bit hacky, and not the way the guys at Microsoft intended when creating Cloud Services.
Using the CI server to deploy the specific configuration has been the easiest in my experience. I think using the Visual Studio "Build" section in Team Explorer is what your looking for. We use Team Foundation Service as our Continuous Integration and Continuous Delivery server. In Visual Studio we've created Production and Testing build configurations. In the Build tab we've created a Continuous Integration Build which will kick off unit tests on every checkin, and a Continuous Delivery Build That will deploy newly tested checked in code on a regular schedule. These Build Events can be set to use a specific (Production/Testing) build configuration.