I have several build definitions setup in TFS 2012. They all use Web Deploy and Web Packages and deploy to my dev and test servers and work just fine.
I can't, however, figure out what the "deployed" tab in TFS Web Access > Builds is used for?
The 'deployed' tab seems to be related to Azure integration somehow.
I found this post on the TFS Deployer website. It's even possible to mark a build as 'deployed' via PowerShell, which seems quite interesting. It would be nice to have our deployed builds showing in that tab, and by integrating with TFS Deployer this seems possible.
Related
We are building a webapp for our clients using ASP.NETZero template built on dotnet core 3.1.x
I am trying to create release pipeline in Azure DevOps and facing issues while publishing the changes of build pipeline to IIS similar way I did for traditional MVC5 or MVC6 .NET Framework based webapps.
The self-hosted devops agent is running on a different machine than production server where the webapp is published and the agent service account has access of the shared path of the \\server\inetpub-sharedhostingdir only.
Traditoinally, Copy Files task could replace app DLLs and all other files but in .NETCore there is an error like below:
Then I found out that this is because of changes how .NET Core 3.1.x hosting works.
I also tried to use 'OutOfProcess' in the web.config in the webapp but still getting same error and then I found this SO post and DLL hotswap info given by #MindingData.
So, my current bat to overcome this issue is using remote powershell in CD; I can stop the webapp and publish the new artifact. But there is cost for this step, I have to stop the site and replace all the DLLs which may roughly takes 30 seconds.
The remote Azure DevOps agent does not have access to do so right now and yet we have to add firewall exceptions to do so.
I am wondering if there is any other efficient alternative to publish .NETCore 3.1.x webapp using AzureDevOps agent running on a remote server? (as access of production server is restricted and we cannot deploy the azure agent on production machine.)
Because of these issues currently I need to move all the DLLs in 'backup' directory manually to make the hosting directory empty and then if I run the pipeline of first image, the 'Copy Files To' runs successfully and publishes the app well.
Any suggestions for improving the CD in current environment?
You may try using 'app_offline.htm' file for graceful shutdown of your running application and after deployment you can easily remove that file using powershell command task.
This approach should work as you have access of the deployment directory of the remote server. Steps are mentioned on the SO post.
I have a number of services which run via IIS and that are worked on daily. On my local machine these are run via IIS. When I was using .NET Framework this was easy, I would point to the source folder and it just worked. Now with .NET Core I must manually "publish" every time I make a change. Is there some way to automatically publish when I build or when changes are made?
You can create an Azure Devops (VSTS) account and configure build and release triggers.
This will basically pull your repository every-time you push to certain branch and then follow the build and release process you configured to deploy your solution to your IIS.
Here is a link with some more details to help you : https://medium.com/#taithienbo/build-and-deploy-an-asp-net-core-app-running-on-iis-using-azure-pipelines-e675041f62d4
I would like to achieve, with Web API, the following WCF behaviour:
Using Visual Studio 2015 create a brand new WCF Service Application. Build. Right away the sample service is "online" and can be accessed with a browser, Fiddler, etc. I do not need to explicitly run the project in VS for the services to be available to any client.
I'm completely new to Web API, and have not seen any documentation on how to achieve this same seamless deployment.
Anyone?
Instead of running the project in Visual Studio (which spins up an IIS Express instance), make sure the IIS feature is turned on on your windows installation, and setup a new site, and point it at the directory of your build output.
For a step-by-step see: http://www.c-sharpcorner.com/UploadFile/2b481f/how-to-host-Asp-Net-web-api-on-iis-server/
I am trying to figure out a better approach for the production deployment of our asp.net MVC applications. At present we deploy the application using the "Publish" feature in visual studio. I have listed our current process below.
1-> Open the latest code in Visual studio.
2-> Right click on the web project and Publish it to a folder using the "release" configuration.
3-> Copy the contents of this folder to the production machine.
I am not sure if this is the right approach. Are there any better alternatives available? I cannot use deployment tools such as "Octopus deploy" as my organization doesn't want to spend money on them.
does anyone have any recommendation for a better process?
Thanks
Suneeth
Octopus deploy brings a lot of control and visibility to the deployment chain. It also handles the hub and spoke model with its Server and agents.
So, to do it manually, I would go for:
Powershell to Deploy
A Windows service, to handle the deployment payload
I do this mechanism, as a fall back strategy to Octopus Deploy.
Hope that helps.
I have been doing some work recently with publishing mvc applications on visual studio 2012. I have been using publish profiles to configure web deploy to different environments. I have also been using web transforms to transform my web.config as per each of my publish profiles.
For each of my target environment, I have web deploy and package publish profile. So dev has 2, qa has 2 etc. This is to give me the option to either web deploy or package up. Is there any way that I can just have the web deploy profile and after I web deploy, the package also gets created and placed on disk? So I only need the one publish profile per environment.
If 2 publish profiles are needed per environment, can I consolidate the transform in to one transform file instead of having a transform for each profile - as the transform is identical as the target environment is the same.