I'm planning to do an automated deployment of a website,but im kind of stuck at this moment. I have looked at MS-Deploy, it got all the functions for deploying Website. I have a created a Web application package (.ZIP file) and I tested this on my local machine it is deploying website i.e
Create Web application under default website
Publishing files in c:\inetpub\wwwroot directory
Set ACLs on directories,etc
But i want to achieve few more extra steps for example:
Check whether Web application exists in Default Website, if not
create a Web application
Check whether Application pool exists, if not create a App pool
(given name) with a specific credentials and Assign App-pool to Web
application
Before it deploys take a backup copy of existing Web application (IF
exists)
publish offline page (app_offline.htm)
publishing the files to application directory
Replace the AppSettings section(in web.config file) to with actual values
Encrypt Web.config connection string
If there is any error whilst installing web application, rollback the web application to its previous version
The question is whether can i achieve all these functions via MS-Deploy or do i need to write any script, please suggest me what scripting language should i use
Please let me know if you need more information.
Thanks in advance
I'm not an expert on this topic but have been doing a bit of research on automated deployment with MSDeploy lately, and think I can offer the following;
This is default behaviour if you use the iisApp provider.
I know you can do this with the appPoolConfig provider, but I'm unsure as to how you would run this and #1 together as part of the same package. Perhaps as part of a pre- or post-sync command?
This is standard in v3, as long as it's set up on the server. Not used it myself, but read this anyway.
Fiddly. Not supported in MSDeploy, but you can vote for it if you want. Also, check out this SO answer (and also worth checking out PackageWeb, but the same answers' author).
Not sure I follow. This is done as part of a successful deployment, surely?
Use web.config transforms and optionally the aforementioned PackageWeb for a neat way to do this. Also check out Web Publish Profiles.
Difficult. My understanding is that the encryption is based on the machine.config, so you'd either have to run a post-sync script which would run some sort of remote Powershell script on the remote server to encrypt the web.config using aspnet_regiis, or you'd have to encrypt the config as part of your build process and then muck about with custom keys and the RSA provider (some info here).
I hope that helps. As I said, I'm no expert, so happy to be corrected by those more knowledgeable. Maybe also worth mentioning that MSDeploy is a lot more powerful if you use it via the command-line rather than creating packages from VS, although there is a bit of a learning curve to go with it.
Related
We've got some legacy on-premise apps that we're evaluating moving off-site, and we are evaluating all our options. I understand that Azure Web Sites would be a lot easier to setup, but at this point it looks like may need some of the additional control that Cloud Services gives us.
However, everything I've read about Cloud Services so far demonstrates how you build an app and then deploy the build to the cloud. Similarly, you can connect to a Visual Studio Online repository, define builds in VSO, and after a commit, a build is performed and the build is deployed to the cloud.
However, in our case some of our pages are Classic ASP pages. In the event that one of these pages changes, I have not been able to figure out a workflow that allows us to deploy the updated files. Remember, classic ASP files do not have a "build" process; it's like a powershell script that is interpreted at runtime.
There is no Visual Studio solution or project involved with these apps. It's just a package of files we want to upload. For a "proof of concept" I decided to start with the simplest possible "app," a simple "hello.txt" file, and I have not been able to figure out a way to deploy this without "wrapping" it in a Visual Studio solution.
I was hoping that I could use, e.g., Publish-AzureServiceProject, however this appears to need a ServiceDefinition.csdef file, and again, I'm not sure how to do this without setting up solution in Visual Studio--a solution that wouldn't be used for anything.
I have a feeling I'm missing something and just need to find the appropriate publish settings file, or proper use of an Azure cmdlet. Is there a straightforward way to publish a package of files to an Azure Cloud Service?
Josh, you will need to package the files into a deployable package. This can be achieved using the cspack commandline tool and a hand-crafted definition file. Your ASP files would be treated as 'content' in this case.
The easiest way would be just to create stub Visual Studio Solution and include a 'Cloud Service' project to which you add all the ASP files. This way all your files will be redeployed in the event that your Web Roles require recycling by the Azure fabric.
While this might seem like a big overhead if you need to tweak just a single file, it is the correct way to manage PaaS deployments in Azure. If this process doesn't work for you then you should consider moving to an IaaS VM you fully manage yourself.
One thing that may be helpful is to realize that the web role in Cloud Services are just VM's using IIS. For that reason, you can connect to them just like any other server, via RDP, FTP, etc. Our team often bypasses the overhead of simple things, like deploying a new CSS file, an image, etc. by simply copying it in the old school way.
Again, not sure if this helps you, but old school techniques work just as well. :-)
I'm developing a WPF application that I deploy with ClickOnce to a network share on the intranet from which clients can install it.
I need to make sure that the user can't modify any of the application files (especially DLLs and the main executable) on their machine. That is, if any of the application files have changed, the application should refuse to run. I was under the impression that, when using ClickOnce, this was available out of the box and that the application would refuse to start if the file hashes didn't match the manifest.
However, I tried to manually replace the executable or a DLL with a slightly different version after installation and the application still ran fine (executing the modified code).
Does ClickOnce provide what I'm looking for?
How can I enable the functionality?
I'm using a level 2 StartSSL code-signing certificate to sign the application manifest if this matters.
P.S.: just to be sure: I'm talking about the installed application files, not the installation files.
You can sign AND strong name each one of DLLs to prevent tampering but then, doing so has its own pain points when it comes to upgrades and distribution in general. Note that even doing so, doesn't entirely prevent someone from injecting code into your running process. It's a sticky subject.
I recommend going thru this question which already discusses these points in detail. Does code-signing without strong-naming leave your app open to abuse?
I think it will be a fairly manual process.
Doesn't look like the VS2013 deployment tools handle code obfuscation but they do support signing and app permissions. Start with that, then you might have to get the generated manifest as a starting point to build your own with obfuscated assemblies.
MS docs break it into 3 steps: 1. obfuscate, 2. build manifest, 3. manually publish
Here is what MS docs say...
Securing ClickOnce Applications
Deploying Obfuscated Assemblies
You might want to obfuscate your application by using Dotfuscator to prevent others from reverse engineering the code. However, assembly obfuscation is not integrated into the Visual Studio IDE or the ClickOnce deployment process. Therefore, you will have to perform the obfuscation outside of the deployment process, perhaps using a post-build step. After you build the project, you would perform the following steps manually, outside of Visual Studio:
Perform the obfuscation by using Dotfuscator.
Use Mage.exe or MageUI.exe to generate the ClickOnce manifests and sign them. For more information, see Mage.exe (Manifest Generation and Editing Tool) and MageUI.exe (Manifest Generation and Editing Tool, Graphical Client).
Manually publish (copy) the files to your deployment source location (Web server, UNC share, or CD-ROM).
I have some questions around the best mechanism to deploy MVC web applications to different environments. Previously I used setup projects (.msi's) but as these have been discontinued in VS2012 I am looking to move to an alternative.
Let me explain my current setup. I currently have a CI setup using TFSBuild 2010 with Team Foundation Server for source control.
A number of developers work on their local machines and check in to the TFS Server. We regularly deploy to a single server dev environment and a load balanced qa environment with 2 servers. Our current process includes installing an msi which carries out some of the following custom actions:
brings current app offline with the app_offline.htm file
run in database scripts (from database project in the solution)
modifies web.config (different for each web server of qa)
labels the code
warmup each deployed file via http request
etc
This is the current process. Now I would like to make some changes. Firstly, I need alternative to msi's. From som research I believe that web deploy via IIS and using MsDeploy is the best alternative. I can use web config transforms for web config modifications. Is this correct and if so, could I get an outline of what I need to do?
Secondly I want to set up continuous delivery via TFSBuild, I have no idea how this may be achieved, would it be possible to get an outline of how it can be integrated in to my current setup? Rather than check in driven, I would like it to be user driven following check in. Also, would it be possible for this to also run in database scripts from a database project in the solution.
Finally, there is also a production environment, but I would like to manually deploy this - can my process also produce an artifact that I can manually install?
Vishal Joshi has some information on his blog that is reasonably good, http://vishaljoshi.blogspot.com/2010/11/team-build-web-deployment-web-deploy-vs.html. It does have the downside that your deployment password is include in the properties you pass to msbuild.
Syed Hashimi has also posted some information on this in another questions Team Build: Publish locally using MSDeploy.
How do you deploy your websites?
For example: I am developing a site with a php framework and have it under version controle with git with all my local configs. When I want to put it on a web server for testing or updating the live application i have to copy it onto the server, change the config files, delete my test stuff etc.
So how do you handle these tasks?
I thought about using ant and write a deployment script for this.
Does there already exists a common solution for this "problem"? Because I don't think im the only one who need something like this.
There are quite a bunch of stuff available, but you might like Phing (like ANT for java).
Questions related to PHP+Phing:
Do you use Phing?
How do you manage your build [using Phing] process?
Setting up a deployment / build / CI cycle for PHP projects
what can Phing do that Ant can't?
Also read this questions sounds very interesting How To Deploy Your PHP Applications Correctly?
There is a specific question (a possible duplicate of your questions) has been answered a while ago, take a look at it Deploy a project using Git push
It seems you are using php, you should be good to go with capistrano. It is very easy to use capistrano for deployment with rails but it can also be tricked a bit to use for php.
Basically what you do with capistrano is -
Tell it which is you application server
Tell you database server
Tell web server (in most cases web server, app server and db server are same)
Specify you git repository with branch you want to deploy from
Once configured, you can deploy with capistrano with single command. You can even rollback your deployments from some of backup releases created by capistrano.
Now form some the repetitive tasks like, copying configs files like database configs (which generally are ignored in git), you create some tasks, which just creates symlinks or copies the files at appropriate location. These tasks will be called with deploy_hookes e.g. after_symlink hook.
You can find more about capistrano here - https://github.com/capistrano/capistrano/wiki
It comes with very good documentation, after getting overview, you may search for your framework specific approach to do this.
I have a Azure project (Azure 1.3) in VS2010. There are 2 webroles, one web page project and one WCF project. In debug mode I want the web project to use a web.config for DEV enviroment, and when publishing the web.config for PROD must be used.
What is the best way to do this ?
Currently I am facing issues when using a Web.Debug.config with transform XSLT. It doesn't seem to work in Azure....
Solve your problem a different way. Think about the web.config always being static and never changing when working with Azure. What does change is your ServiceConfiguration.cscfg.
What we have done is created our own configuration provider that first checks the ServiceConfiguration.cscfg and then falls back to the web.config if the setting/connection string is't there. This allows us to run servers in IIS/WCF directly during development and then to have different settings when deployed to Azure. There are some circumstances where you have to use web.config (yes, I'm referring to WCF here) and in those cases you have to write code and create convention instead of storing everything in web.config. I have a blog post where I show an example of how I did this when dealing with WIF (Windows Identity Foundation) and Azure.
I agree with Mose, excellent question!
Visual Studio 2010 includes a solution for this type of problem, web.config transforms. If you look at your web role you'll notice it includes Web.Debug.config and Web.Release.config along with the traditional web.config. These files are used to transform the web.config during deployment.
The canonical example is "I need different database connection strings for development and release" but it also fits your situation.
There is an excellent blog post from the Visual Web Developer Team that explains how to use this feature (don't bother with the MSDN docs, I know how it works and still don't understand the docs). Check out http://blogs.msdn.com/b/webdevtools/archive/2009/05/04/web-deployment-web-config-transformation.aspx
I like this question !
For worker roles, I solved this problem by detecting the environment at runtime and launching my 'application' in a new AppDomain with a custom configuration :
bot.cloud.config
bot.dev.config
bot.win.config
This is incredibly efficient !
I'd like to do the same with web projects, because using the Azure specific configuration is a lot of trouble :
Both config are not in the same place, which is time-consuming when debugging
You have to learn a new way of writing something that sould be standard
Sometime you'll wonder if the app falled back on web.config because of a stupid syntax error
I'm still searching the right way to do that, like in this post
Another possible solution is to have two CloudService projects, each one with specific ServiceConfiguration.cscfg(dev/prod). Develop using the Dev, but deploy the Prod.
Currently I am facing issues when using a Web.Debug.config with
transform XSLT. It doesn't seem to work in Azure....
It depends on whether you want to make it work on your local machine or inside continuous integration.
For the local machine I tried to answer here: https://stackoverflow.com/a/9393533/182371
For the continuous integration it's even easier. When you build from the command line specifying the Configuration property value your configs WILL be transformed (no matter what it does when you build inside VS). So properly specifying build configurations for both cloud and web project will give you the correct output depending on build parameters.