I have various IIS hosted service hosts with simple svc files etc. What I want to do is to be able to create deployment packages from our test server using IIS Export Package in a way that parameters may be saved and picked up at Export time so that the Export is repeatable and automatable. I.e. the Export will always use the necessary Manifest extensions such as XmlFile etc.
The web sites exist in the solutions and are then picked up using a Web Deployment project in each solution so that config substitutions are done etc.
We are currently on VS 2008 SP1 so do not have direct access to VS 2010
The first issue I have with MsBuild (running in TeamCity) is how to build the IIS web site (with target=Package) when there is no project file? In this way maybe I can avoid the Web Deployment projects (I use them for various configurations but don't want to do it this way for deploying to Production but rather export from our fully tested staging into a package file to be imported onto a production server).
Secondly, I want to avoid having to configure the Export in IIS 7 each time I run it. I want it simply to pick up the correct set of extensions to use and create the necessary parameters for me. Is this done from a Manifest file? I can see how to use the parameters.xml but I am unclear whether I need to use a manifest.xml (created by hand) and how to link it in. The idea is that a tester/deployment person should be able to do the Export simply without having to enable all of the extensions that are required
Any help or guidance will be greatly appreciated.
Ok, in the meantime I got it figured out.
I ended up using the document at Package an Application for the Windows Web Application Gallery which gave me the means by which I could extend our automated build in TeamCity to create the "repeatable" export packages.
In short I will use the current Web Deployment Projects to create the deployment artefacts and then in MsBuild combine them with the pre-prepared manifest.xml and parameters.xml files into Build artefacts folder and zip them up into a package. From there the task will be to Import the package into IIS Deploy in the target environment.
The parameters.xml file will be used to set the HostName for wcf clients and services, connection strings, app settings etc.
This turned out to be the best solutuion bcause I can put it into our automated build.
Related
Via VSTS I am trying to automate the following process which is currently performed manually:
Within VS 2017 perform a publish to file system.
Set settings in web.config.
Repeat 1 & 2, for each environment, e.g. Test, UAT, Production, etc.
Copy those files to an FTP server.
Logon to secure infrastructure, download files from FTP, and copy into place on IIS target servers.
The secure infrastructure is locked down, and has limited internet access. The FTP is used as a way to move files into that infrastructure.
Within this question I specifically want to address elements; 1, 2, and 3.
The struggle I am having is that VSTS seems setup to deploy web apps into Azure Web Sites or publicly accessible IIS. Whilst IIS is my eventual target, initially I was hoping to achieve a file system deployment - similar to what VS 2017 provides.
I have tried using MSBuild to create a package, using; /p:WebPublishMethod=Package /p:PackageAsSingleFile=true.
Then MSDeploy to extract the package into a folder msdeploy.exe -verb:sync -source:package="Package.zip" -dest:contentPath="content".
However that results in the following error Source (sitemanifest) and destination (contentPath) are not compatible for the given operation.
It looks like I can use MSBuild and /p:DeployOnBuild=true /p:PublishProfile=VSTS to deploy to a folder at build time, but that seems a little awkward within the structure of VSTS. E.g. I have to repeatedly build the solution for each environment.
After I have the solution deployed into a folder, I intend to use VSTS to push to FTP.
Is there a better way to do this? For example; VSTS Azure deploy provides the ability to easily set connection sting parameters.
You can achieve what you want to do with the FTP Upload build/release task.
1 - You don't have to publish to the file system.
Just create a new build definition based on asp.net application template:
This will add the tasks you need to build and package and as a final step to publish the artifacts to a drop location.
After you published it to a drop location you can either continue on build by adding the ftp task or you could add the ftp task to a release pipeline. This is up to you.
The ftp upload task then needs to be added after the publish artifacts task, like:
For 2 and 3 it is best that you use a release pipeline, where you can add several environments and tasks to it. That you can add your ftp task and get it from artifact (your build) that you will add to the release. The web.config settings can also be changed using release tasks.
My company uses TFS 2010 to deploy our web apps from our local environment to our development environment. Here's the compiled output in my local directory for one of our vended web apps, ProGet, (http://inedo.com/proget/overview) in question that isn't deploying correctly. I expect all of what I see below to deploy to our development server:
Here's my .xaml build file:
Finally, here's my solution in Visual Studio:
When I queue the build, this is what's built out to our development server - notice it's missing a bunch of files/folders, but it does include "Resources" and "bin" and web.config:
This app is a vended application, ProGet, an already developed corporate Nuget repository that we purchased a source code license for. Does anyone have any ideas what I might be doing wrong?
EDIT
Here's a screenshot of my local IIS and the window to the right is a result of right clicking the website and choosing "Explore". Notice the *.cs files. Weird they don't compile down.
The Default Build Template (DefaultTemplate.xaml) should output the same files you get when you compile locally.
However, from your screenshots it looks like you are using a custom build template xxxx_DeploymentProcess.xaml that is obviously doing something different with how it outputs the build files. There is no way for us (stackoverflow community) to know what your custom build process is doing.
You could try switching back to the default template, and we'd be able to help you then. But, there's a good chance that you are using a custom build template for a reason, and you might not want to eliminate it before you know what it's doing.
I am working on an asp.net mvc web application. I have prepared a web deployment package from my staging environment as a zip file, then I publish this web deployment package inside IIS on production server and it worked well.
But currently I need to modify a Controller class to fix a bug on production. But I am not sure how I can publish this specific controller file to my production server .I test the fix on staging and i need to deploy on this controller class to my production server. can anyone advice?
Thanks
You need to deploy built *.dll assembly file rather than source class file. It should be within \bin folder.
Usually it's called as [your-project-name].dll.
Trying to publish a click once type app to a local directory and create a websetup with the published contents- so that i can give tat setup to install in two different servers. but as the publishing wizard takes a URL - separate setup is required for each server. Is there any way that i can create a single setup which i can use it in two servers..?
The URL for setup.exe is only for the purpose of bootstrapping. What I found is that the bootstrapper that gets created with your deployment manifest ('setup.exe') is designed for a web-published application.
If your clickonce publish will be installed on intranet servers, you can't use out of the box bootstrapper. You may write your own or build a seperate setup project for bootstrapping and calling the .application from the installed server when the pre requisites where installed.
If you don't rely on pre requisites and you can ask users to make sure they have the right CLR version, you don't need the setup.exe at all.
I'm starting to use MSDeploy quite aggressively within our Visual studio web projects projects as a mechanism for producing self contained build artefacts that have everything needed to setup and run themselves on a remote server. This works fine for simple web apps, however we have some web applications that need additional command line tools to be run on the remote servers before the application can be considered to be "deployed".
I have followed Sayed's advice to include additional files and folders within my package, but they appear as a subfolder within the deploy of my web application (and that's not good, as the files are only needed once at deploy time).
Ideally, I'd like the package.zip to contain the tools as a set of sibling folders to the IIS aplication, and have a mechanism to run an exe within those folders at deploy time. (I think this is via the deploy.manifest, but would like advice here too) but NOT actually leave the files on the remote machine.