We practice continuous deployment with TFS (2008) and are looking for a nice way to handle IIS settings changes. MSDeploy seems like it should be the way to handle this, but after much reading and searching, I haven't found a good answer.
The problem with MSDeploy, as I see it, is that you need to create a deployment package using an existing IIS website. I would like to be able to have the appropriate IIS configuration for the website in source control and have the build create the package.
The only way I can see to do this is to hand craft the archive.xml file. Is my thinking correct or is there a better way?
I ended up using powershell web administration module (with PSake for the build) to do this. I would still prefer to do this in a declarative manner.
I've been able to put a bunch of the website settings into my web.config so that they are in source control and easily deploy-able. Not all though. Some seem to get set higher up in the IIS hierarchy and then cannot be overridden by my web.config.
I've never found a way to do this with application pool settings.
For setting up new sites I wrote a small C# WinForms app that uses the programmatic interface to IIS to create the sites and app pools and change their settings. Probably similar to your PowerShell script.
Related
I've Googled, Binged, and here at StackOverflow, looked through the related questions and searched, but I'm not finding what I'm looking for. I've also searched documentation on DNN.
What I'm looking for is any guidance (tutorials, blogs, step-by-step instructions for setting up a repository) etc from people who are experienced in using DotNetNuke with SVN.
We use SVN for all our source control, and have no problem with standard applications, because we pretty much built the repository and directory structure to work with our processes. This means when we do web sites, in Visual Studio, we do file based web sites, rather than setting them up in the local IIS. It just makes things easier for us.
However, with DNN, it appears that even if you get the source code, it is expecting to be set up in the local IIS, which means additional headaches for us.
For example, we are moving all of our source code off our local C drives, and onto a shared drive on a server. This is to enable backups in addition to our normal source control. (This was a management decision). So that means that we need to change the virtual web app when we make the move.
Has anyone come up with a good way to work around this? Can DNN be set up so that the developer web server in Visual Studio can be used, so that we can treat it just like any normal web app? Am I missing something obvious?
Source Control
I recommend using separate projects for DotNetNuke projects (skins, modules, providers), and not checking the actual web site itself into source control environment (DNN Modules would use the WAP style project). Each developer could then have their own DotnetNuke site and database in their development environment. I also don't recommend making changes to DotNetNuke's core so that you have a clean upgrade path. I would recommend using a tool such as Red Gate's SQL Data Compare in order to generate database scripts for your data that you could keep in the source control environment as well.
Here is some more information about setting up a Web Application Project for a DotNetNuke module.
Testing/Staging/Production
Keeping these separate in DotNetNuke is generally very easy because you're already creating modules that plug into a DNN site. My recommendation is to create packaged and properly versioned modules so that you can cleanly install them on test, staging, and production.
You may want to investigate building module packages with MSBuild scripts. Alternatively, Here is some information on using NAnt to automate DNN module packaging.
I want to deploy my ASP.NET application. Its not a "web site" it's a web application.
I'm looking
1) The quickest possible thing to do so I can start of testing
2) A more automated approach.
Any ideas?
Your fastest manner for getting it ready for testing is from the "Build" menu to select "Publish".
This will pre-compile everything and you can have it deploy to a folder, then set it up in IIS, change the connection string and you are set to go.
To "Automate" that process, you are going to most likely want to look at creating an install package.
If you're using MSBuild grab MSBuild community tasks # http://msbuildtasks.tigris.org/
And take a look at the WebDirectoryCreate task. There are plenty of other task libraries, but this is what I personally use.
If you're looking at changing configuration settings a simple xcopy and a folder naming structure was the simplest solution for me.
The quickest possible way is the publish command and setting up the virtual directory in IIS manually. I personally got sick of that so I went and looked into NANT and MSBuild.
I am working on a web project as a Web Site, rather than a Web Application. How can I use a different config file depending on where it is hosted from, so the local version uses my local SQL install, but the published version uses the live database? e.g. connectionStrings.config ignored (not published), connectionStrings.live.config published as connectionStrings.config
I see a policy file option, would that be something able to do this?
There are several options regarding this. The simplest is to use a web deployment project. The ScottGu's post goes into more detail on this.
For larger projects you will need something like Nant or MSBuild and CruiseControl or TeamBuild.
I also posted something here a while back on supporting complex config deployments
Use a MSBuild or NAnt script for different builds.
You can use a Web Deployment project. Check out ScottGu's blog post.
Post Build Event which swaps the config over?
you can have a different post build event depending on your build configuration, each can copy a different config if needed.
According to an earlier question about Visual Studio configurations, there's no way to use Visual Studio's configuration manager to create different configurations for an ASP.net web site project.
For normal projects, we have #if directives that switch certain server or database variables depending on whether we're debugging or in production. This doesn't work for web sites.
For example, in a class (in App_Code) that defines a web site's back-end server connection, there might be a chunk of code like this which overrides production values in the web.config if you want to run a debug server on your local machine:
#if DEBUGLOCAL
ServerProperties.ServerIP = "localhost";
ServerProperties.DataContextIP = "localhost";
#endif
This doesn't work, since there's no "Debug Local" configuration for the website, thus no DEBUGLOCAL defined.
Have you found a good way to work around problems like this? Besides (I hope) refactoring everything so all those references live in a class library project?
ETA: Can web deployment projects help here?
Perhaps a Web Deployment project that does some swapping in the web.config may be of some help? Another thought would be to have a connection string in the web.config that pulls various values from a pre-specified database that can exist in each environment to allow for easy changes to the settings without needing to touch any files.
Another option may be to upgrade the web site to a web application.
That could be a lot of work to make the transition now, but the ability to have configurations may help tip the scales if you're deciding to go with a web site or web application.
I need a little help on this subject.
I have a Web application written in ASP.NET plus I have the .bak file of the SQL Express database, my question is: How can I install this in a simple click and go way in the client?
how can I write a script that will create a new database, restore the bak file into that database, set up IIS and ... well, that's it :)
I do this all manually, and I do this a lot, so I was just asking if there is a way to prevent do all this steps manually.
Thanks.
You could use WiX to create a .msi that you can use to install your application at your clients. WiX takes a bit to get used to, but once you get the hang of it, you'll meet your needs above, and be able to extend them as your application grows or increases in complexity from the installation point of view.
I read your question to mean you have several clients where you install your application, if that is not the case, and your app exists in one place, there are better solutions, and better people to give them to you!
While WIX is certainly very flexible if you aren't comfortable with the learning curve (and there is a bit of a learning curve IMO) then perhaps you should check out the Web Deployment Projects.
From the blog post:
Web Deployment projects can be used with either the "ASP.NET Web Site" or "ASP.NET Web Application Project" options built-into VS 2008, and provide a few additional build, packaging and deployment options for you to use.
Regarding the database, I'd suggest that you utilise the App_Data directory and just deploy the ".mdf" file. This would be easier than trying to create a new database and restoring a backup.