We are working to migrate to Azure Cloud Services (not Web Site) for our ASP.net Web Application. We are wanting to start using the Team Foundation Service with 'Continuous Integration' publishing like we currently use between AppHarbor and GitHub.
We are running into challenges when using TFS's 'Continuous Integration' feature. The builds are inconsistent when comparing Visual Studio to Azure Cloud Service to TFS to Azure Cloud Service. When we publish to Azure Cloud Service using the TFS's 'Continuous Integration', our static pages work fine but for the pages that have an *.cs extension are not able to find the controls we have placed on those pages. However, when we publish using Visual Studio 2010 to Azure Cloud Service, these pages operate correctly.
Can you offer any insight to why Team Foundation Service's Continuous Integration to Azure Cloud Service would result in pages with an *.cs extension not being able to find the controls we have placed on those pages while a build and deployment using the same exact code from Visual Studio 2010 to Azure Cloud Service works perfect?
Make sure all the referred assemblies that include the custom controls are "NOT" referred from GAC. Ideally put those in a folder (call it libs or references etc to easily identify). Then refer the assemblies from that location in your project, also don't forget to mark them Copy Local = True.
Anything that is not part of the framework should be included like this.
Related
I've got some Azure Function Apps that I've created using the Azure Functions template in Visual Studio (i.e. the Azure Functions and Web Jobs Tools Visual Studio extensions).
This works great and I can deploy my Function Apps to my personal Azure subscription, however, I don't want to use Visual Studio to create and deploy Function Apps to work subscriptions. Ideally we use ARM templates to create the Function App Services and use package/zip deployments of the code via the command line through CI/CD.
Where do people put the ARM templates? I was thinking of creating a separate project in Visual Studio using the Azure Resource Group template, but this means I'd have 2 projects for each Function App.
Usually you either have a centralized Infrastructure as Code (IaC) repo (or maybe several of these) and store IaC code in there or you store it along side the application code in the same repo just have a IaC folder somewhere. It really depends, with the centralized approach you can have code reuse\centralized management, so I tend to think its better
I created a WebJobs app targeting .NET Core following this article: http://matt-roberts.me/azure-webjobs-in-net-core-2-with-di-and-configuration/
I had to do this manually because currently Visual Studio does not provide a way to create a WebJobs app in .NET Core but I can create a console app targeting .NET Core in Visual Studio 2017.
Now, I want to publish my WebJobs console app to Azure but I'm NOT getting the option to Publish as Azure WebJob which Visual Studio typically gives -- see below:
Instead, I'm just getting "Publish" option and not sure if this will work as intended.
How do I publish my manually created WebJobs console app to Azure as a WebJob?
You can always publish WebJobs manually. There are several ways:
Directly copy the relevant files into d:\home\site\wwwroot\app_data\jobs\continuous\{job name} (e.g. using Kudu Console)
Zip up all the files and upload it as a continuous WebJob using the Azure Portal
Also, for the WebJobs engine to know how to run your Core app, you will need to include a run.cmd file that runs it (place that file in the same folder). e.g. it should contain something like dotnet YouWebJobAssembly.dll, or whatever command line you want to use to start it.
We have several Web Apps and WebJobs with different configurations for different environment, e.g. Test and Release.
Each WebJob is deployed to a Web App using "Publish as Azure WebJob" in Visual Studio.
We are using the Config Transform extension to transform the App.config that consist of different config sections, connection strings and app settings that needs to be transformed. This works fine for local Debug and for Release.
The problem is that when we use "Publish as Azure WebJob" there is no way to specify which configuration to use and Release is always built and published even if Test is selected inside Visual Studio.
We have also tried to deploy the WebJob together with the Web App but it almost always hangs, same as described in Stuck when publishing Web App to Azure with WebJob
We don't need to use config transform if that's not possible, e.g. we could configure directly in Azure. But I haven't found a way to configure config sections directly in Azure.
Yes this is a known VS tooling pain point that comes up often. The short answer is that web.config style transforms aren't supported for general application types like Console apps.
This has been discussed recently in the context of WebJobs in our public repo here. That issue also links to the VS User Voice issue for this. That item also links to the SlowCheetah VS extension which some users have said works for them. You might give that a try.
If that doesn't work for you, then you'll have to manually manage your settings via the app settings blade in the Azure portal.
I added a prebuild step to change the webjob-publishing-setting.json file and the app.config file depending on which Configuration is selected.
The webjob-publishing-settings.json only had the name. Then from Visual Studio 2019 I used "Publish as Azure WebJob" and that created a second webjob with the new name and new configuration.
Works great!
I am working with Virto Commerce server 2.4.561 and I'm having a great deal of difficulty successfully publishing to Azure from Visual Studio. Based on the documentation provided, it's not clear to me what the appropriate method is. Most guidance related to Azure assumes that I am using Git deployment. But in this case I am not. I am coding locally on my dev machine and I would like to be able to use web deployment to deploy directly to Azure from Visual Studio. However, the guidance found here seems to suggest that if you want to do your own deployment, you need to use deploy.cmd. I'm not exactly sure why that is. I can only guess that it has something to do with how the modules need to be packaged up.
I am able to run deploy.cmd and it appears to succeed, but I end up with an artifacts folder with 2,000+ files and folders in it and I am left to use old-school FTP to sync all those files up with the Azure website. Is this how it is meant to be done? I have tried to deploy directly from Visual Studio to Azure, and it appears to succeed, but the site does not behave correctly. Specifically, the custom modules I've built don't load correctly.
What is the right way to do this?
There is a way to publish your custom module directly from Visual Studio, but you still need a working Virto Commerce in Azure beforehand, and the easiest way to set it up is to use the Deploy to Azure button in GitHub.
In the Azure portal create a new virtual application /MyModule with
physical path site\wwwroot\admin\Modules\MyModule. It will be used
for publishing a custom module.
Download the source code from GitHub with the same version as you have published to Azure, add your custom module to the solution and build it.
In Visual Studio right-click on your module project and select Publish.
On the Profile screen select Microsoft Azure Web Apps as a publish target and select your Azure Web App.
On the Connection screen select Web Deploy as a publish method and add /Module to the site name. So your site name should look like this: myvc/MyModule.
On the Preview screen click the Start Preview button and make sure the file list contains only files related to your module and the action is Add for each of them.
When you click the Publish button, Visual Studio will upload all module files to the physical directory configured for the virtual application myvc/MyModule. For subsequent publishing it will upload only modified files.
Update: You should restart the Web App via the Azure portal after publishing in order to load the new version of your code into the application. Thanks to N1njaB0b for reminding.
Friends,
I am trying to setup Continuous Integration with Azure WebJobs. I have a Web and a WebJobs project in the solution. I have continuous integration and deployment already setup for the web app in Visual Studio Online (*.visualstudio.com).
I also connected the WebJobs and the Web app using the Visual Studio ASP.Net extensions - Right click the WebSite project in VS 2013 > Add > Existing Azure WebJob project. It created webjobs-list.json file in the website project.
I was expecting that when the Web app deployment happens to Azure Website after the Visual Studio Online build, it will deploy the WebJobs too. But it is not doing so.
How do we automate the WebJobs deployment after Visual Studio Online build in visualstudio.com?
The WTE team is aware of the TFS publishing issues. I've been personally working on developing a workaround with which I'm comfortable but haven't finalized it yet. My team is working on an improvement to the WebJobs publishing experience from VSO. This item is absolutely on our agenda to repair, and will be included in the next VS update. In the meantime I'm trying to come up with a workaround for the time being; once that workaround is prescriptive enough to post, I'll write a post summarizing the process on our team blog.
This looks like the way to do it with VSTS
https://blogs.msdn.microsoft.com/tfssetup/2016/05/18/deploying-and-schedule-azure-webjobs-from-vsts-to-azure-web-app-with-bonus-cron-scheduling/
Basically,
Use VS to link your web job to a web app.
Create a new Buildtask that uploads the WebJob.zip file.
Profit.