I've installed a lot of DNN sites in the last couple of years, but this task just got even easier!
http://www.microsoft.com/web/channel/products/WebApplicationInstaller.aspx
The Web Application Installer Beta is designed to help get you up and running with the most widely used Web Applications freely available for your Windows Server. Web AI provides support for popular ASP.Net and PHP Web applications including Graffiti, DotNetNuke, WordPress, Drupal, OSCommerce and more. With just a few simple clicks, Web AI will check your machine for the necessary pre-requisites, download these applications from their source location in the community, walk you through basic configuration items and then install them on your computer.
The only down side is that it installed DNN 4.8.4 instead of DNN 4.9.
Here is the installation log:
[10/17/2008 9:09:55 AM] ----------------------------------------
[10/17/2008 9:09:55 AM] Start download the configuration file.
[10/17/2008 9:09:56 AM] Launch the app successfully.
[10/17/2008 9:10:00 AM] Download the configuration file completion.
[10/17/2008 9:10:00 AM] Start load the configuration file.
[10/17/2008 9:10:04 AM] The configuration file is valid.
[10/17/2008 9:10:04 AM] Load the configuration file completion.
[10/17/2008 9:10:26 AM] Change to the Select Application page.
[10/17/2008 9:10:48 AM] Change to the Prerequisites page.
[10/17/2008 9:10:49 AM] The prerequisite IIS has passed inspection.
[10/17/2008 9:10:49 AM] The prerequisite FastCgi has passed inspection.
[10/17/2008 9:10:49 AM] The prerequisite SQL Server or SQL Express has passed inspection.
[10/17/2008 9:10:49 AM] Change to the DotNetNuke Web Site page.
[10/17/2008 9:11:00 AM] Change to the DotNetNuke Configuration page.
[10/17/2008 9:11:45 AM] Change to the Application Prerequisites page.
[10/17/2008 9:11:45 AM] Testing SQL Connection on server localhost with uid sa
[10/17/2008 9:11:55 AM] Start download DotNetNuke
[10/17/2008 9:11:55 AM] Change to the Installation page.
[10/17/2008 9:12:10 AM] Download DotNetNuke successfully.
[10/17/2008 9:12:10 AM] Start extract DotNetNuke
[10/17/2008 9:12:23 AM] Extract DotNetNuke successfuly.
[10/17/2008 9:12:23 AM] Creating VDir with name DotNetNuker in site localhost, path=C:\inetpub\wwwroot\DotNetNukerMan.
[10/17/2008 9:12:23 AM] Began to add the default document "Default.aspx" for the web site localhost.
[10/17/2008 9:12:23 AM] Generating config file for DotNetNuke.
[10/17/2008 9:12:23 AM] Setting file system rights for file: C:\inetpub\wwwroot\DotNetNukerMan, user: IIS AppPool\DefaultAppPool
[10/17/2008 9:12:28 AM] Run the database script for DotNetNuke.
[10/17/2008 9:12:28 AM] Began to execute the SQL script. Database = DotNetNuker Server = localhost
[10/17/2008 9:12:33 AM] Change to the Summary page.
Pretty cool huh?
When creating a DNN module, you have the option to choose from the web site project (WSP), or a web application project (WAP). I prefer the web application project approach, and I'll explain it for developers who are new to module development, or unfamiliar with the WAP approach for developing modules.
There are two major reasons why I feel WAP is generally better than WSP for DNN module development.
1. Conciseness - the project contains only your module's code, nothing more. Separating your module from the DNN web site itself in Visual Studio really helps with performance and maintainability.
2. Compiled - I like having the code compiled into an assembly. This makes it easier for me to build a module package and distribute. I like to use a NAnt script for each module that creates the packages for me. The WAP project style lends itself to this approach.
If you'd like to give it a try - here are the steps involved.
- Create a new WAP project, or alternatively, use a C# DNN Module WAP Template
- Place the root of the project in the DesktopModules directory of your DNN development web site's file system (e.g. ..\DesktopModules\MyModule\)
- Set the project to build the assembly and place it in the "bin" directory of the DNN web site
- Set the project to launch your DNN web site (e.g. http://localhost/DotNetNuke) when you F5/run.
- In order for Visual Studio to know about your development web site, make sure to set your project to use your IIS server, and set the Override application root URL to the root of your web site. When you do this, Visual Studio knows that paths starting with "~" are really pointing to the DNN web site, and not just to your project. This makes it possible to include controls from within the DNN site, like the DNN Label or URL control.
After your module is set up, you can import it (by importing the .dnn manifest file) into your development site, and run any database scripts that the module may have. Your module is now fully integrated into your DNN site.
TIP: to debug the module, you may find it helpful to "attach to process" in Visual Studio while you already have the web site running in a browser. This saves you from having to launch the web site multiple times.
With the new skinning changes in DotNetNuke, it may be helpful to give an overview of available approaches to skin developers.
Each of these approaches attempts to answer the question "How do I embed and customize all that great functionality that DNN provides in my skin?" In other words, given that we have a pre-set base of options for functionality (core skin objects), and each of those options exposes certain customization points (skin object properties) that I'd like to set…how the heck do I get it done?
The answer may depend on which technologies you are familiar with (or willing to learn), but let's examine each of the different approaches and see if one clicks for you.
Note: For the sake of simplicity, I'm going to leave out the following buzz words: XTHML, CSS, table-based, and any other new age standards loving or old-school table defensiveness babble.
What's available pre-DNN 5
The "XML? I've heard of that!" approach
Technologies involved: HTML with DNN tokens, XML
Formula: HTML with DNN tokens + XML file with properties for each token = finished ASCX file
Background: Create an HTML file with tokens embedded, customize tokens with properties in an associated XML file. Package and upload to DotNetNuke. This method notably has two different file types that are used to pull together and generate a "real" skin file for use by DNN.
Benefits: It does not involve anything specific to ASP.NET or any other Microsoft technology for those that don't want to learn them.
Drawbacks: You have to maintain two files and use a DotNetNuke utility to parse the skin package every time you want to make a change. There is a fair amount of overhead associated with this approach.
Who's using it? This approach is very useful if you are a person who is comfortable with HTML and also comfortable with XML.
The Direct Approach
Technologies involved: HTML (without DNN tokens), ASP.NET Web User Controls
Formula: no math required!
Background: Create a user control in your application of choice and package it up with supporting files. Characterized by the ".ascx" file extension, lots of "<% %>" and runat="server" tags, this is, when it's all said and done, what DotNetNuke will use at run time.
Benefits: You can edit the file directly in your development environment without having to re-parse the skin package, which can lead to quite a bit of time saved if you are making frequent changes.
Drawbacks: You must be familiar with web user controls, the concept of embedding them in another user control, setting properties on those controls, and all the syntax and 'developer speak' that comes with 'em.
Who's using it? This is an approach used primarily by developers or those that are familiar with ASP.NET Web User Controls (ASCX files).
The Combo
Technologies involved: HTML with DNN tokens, ASP.NET Web User Controls
Formula: Generated "stub" ASCX file from HTML file with DNN tokens + revisions = finished ASCX file
Background: Create an HTML file with tokens, package up your module and then for each skin object, customize the generated user control with the properties you want to set.
Benefits: Quickly and easily generate the user control, and make changes to it directly within your development site and see them reflected immediately. Once you generate the HTML file, you leave it behind and only have to maintain one file (the .ascx).
Drawbacks: You must have a basic understanding of what ASP.NET elements NOT to remove from the user control when making changes to the file.
Who's using it? I speculate that people who are cranking out skins at high volume use this approach. They're probably the people that have been skinning for a long time.
The New Stuff
Now, there comes a new element to incorporate into our approach, if we so choose (I'm assuming that all of the other approaches are still valid, and that we're simply adding another one to the mix.)
The "Now with more friendliness" approach
Technologies involved: HTML with "uber-tokens"
Formula: HTML with skin objects and properties = finished ASCX file
Background: Create an HTML file with "object" tags that contain both a reference to the skin object to be used, and the parameters that allow you to customize that skin object.
Benefits: This approach allows you to avoid learning ASP.NET stuff and keeps you from having to create or maintain a separate XML file. This also uses the same syntax for including the new JavaScript widgets in your skin, which is a separate topic, but consistency is always good!
Drawbacks: I like HTML and all, but what is an "<object>"? I just got used to the skinning process, now you've changed it?
Who's using it? Nobody! It's not released!
Summary
So, we've learned there are multiple ways to skin a DotNetNuke site. In the end, it all comes down to what works for you. In the end, you'll probably either be creating a user control if you're a developer, or using the new skin object mechanism if you're not. But, if you like resisting change, you should be able to continue using the HTML/XML approach.