Dotnetpanel Forums

This short guide describes the process of creating new packages for DotNetPanel Web Applications Installer.

The default installation of DotNetPanel doesn't include application packages in order to reduce the size of the installation. However, the most popular application packs such as DotNetNuke, CommunityServer, StarterKits are available as a separate downloads from DotNetPanel web site.

Applications packs should be uploaded manually by the administrator to "[portal_install_folder]\DesktopModules\DotNetPanel\WebApplications" folder.

The structure of WebApplications folder is the following:

\WebApplications
    \App1
         Application.xml
         Install.xml
         Uninstall.xml
         app_logo.gif
         sql_script1.sql
         sql_script2.sql
         sql_scriptN.sql
         app_files.zip
         custom_settings.ascx
    \App2
         Application.xml
         Install.xml
         Uninstall.xml
         app_logo.gif
         sql_script1.sql
         sql_script2.sql
         sql_scriptN.sql
         app_files.zip
         custom_settings.ascx
    ...
    \AppN

Each application is placed in a separate folder. The name of the application foler can be various just to differ one application from another.

The process of creating your own custom application packs includes the following steps:

1. Create application definiton file application.xml.
The basic structure of this file is:

<?xml version="1.0" encoding="utf-8" ?>
<application
  id="DotNetNuke"
  folder="DotNetNuke"
  codebase="DotNetNuke.zip"
  settingsControl="DotNetNuke.ascx"
  databaseServer="MsSQL">
 <name>DotNetNuke 3.1.1</name>
 <category>Content Management Systems</category>
 <shortDescription>&lt;b&gt;Fully supports multiple installations into the single database!&lt;/b&gt; DotNetNuke is a content management system ideal for creating and deploying projects such as commercial web sites, corporate intranets and extranets, and
online publishing portals.</shortDescription>
 <fullDescription>DotNetNuke is a content management system ideal for creating and deploying
projects such as commercial web sites, corporate intranets and extranets, and
online publishing portals.&lt;br/&gt;
DotNetNuke is designed to make it easy for users to manage all aspects of their projects.  Site wizards, help icons, and a well-researched user interface allow universal ease-of-operation.
</fullDescription>
 <logo>dotnetnukelogo.gif</logo>
 <version>3.1.1</version>
 <size>10</size> <!-- Mb -->
 <homeSite>http://www.dotnetnuke.com</homeSite>
 <supportSite>http://forums.asp.net/90/ShowForum.aspx</supportSite>
 <docSite>http://www.dotnetnuke.com/Default.aspx?tabid=787</docSite>
 <manufacturer>Shaun Walker and community</manufacturer>
 <license>BSD</license>
</application>

Elements/Attributes explanation:
Application "id" attribute should be unique across all applications.
"folder" attribute specifies the folder where application pack files reside.
"codebase" attribute is the name of the ZIP archive containing all application files that should be deployed to the target web site.
"settingsControl" attribute is the optional name of the pack-specific ASP.NET user control allowing to specify custom installation parameters.
"databaseServer" attribute is the name of SQL engine that will be used. Possible values are "MsSQL" and "MySQL".
All the rest of "application" elements are just for presentation purposes and are self-descriptive.

2. Pack all application files into the single ZIP archive. All archived files will be unpacked recusively to the destination folder, so, pay attention to the root folders inside of the archive. Any file in the archive can contain installer variables that can be expanded (substituted) during the installation.

It is suitable e.g. for folder pathes, connection strings in web.config. Variables should be specified in ${variable_name} form. The default installer variables are:

• installer.contentpath - the phisycal path to the application
• installer.website - the name of the target web site
• installer.virtualdir - the name of the target virtual directory
• installer.database.server - the name/IP of the SQL/MySQL server
• installer.database - the name of the database
• installer.database.user - database user
• installer.database.password - database user password

There are can be other custom parameters from pack-specific ASP.NET User Control.

3. Create installation scenario file Install.xml.
The basic structure of the file is:

<?xml version="1.0" encoding="utf-8" ?>
<scenario>
 <check>
  <sql>
   select * from ${installer.database}..sysobjects where name like '${ObjectQualifierNormalized}Portals%'
  </sql>
  <fileExists path="${installer.contentpath}\web.config"/>
 </check>
 <commands>
  <!-- process copied files -->
  <processFile path="${installer.contentpath}/web.config"></processFile>
  <runSql path="sql_script1.sql"/>
  <runSql path="sql_script2.sql" dependsOnProperty="dotnetnuke.installmembership"/>
 </commands>
</scenario>

"check/sql" elements provides an easy way to check the database if there is another application installed. If the result of at least one SQL statement returns some records the installation process will be terminated.
"check/fileExists" elements allow to verify if some files already exist in the destination folder and again, cancel the installation.
"commands/processFile" instructs installer to load the specified file and expand all installer variables (default and custom).
"commands/runSql" instructs installer to run specified SQL file against the target database. Optional attribute is "dependsOnProperty" allowing to execute the script only if the specified variable exists (not null) in variables set. All variables in SQL script will be automatically expanded before execution.

4. Create uninstallation scenario file UnInstall.xml. The file has the same structure as install.xml described above.

5. Create application logo image. It will be presented in DotNetPanel portal on applications list and application properties forms.

6. Create optional custom settings ASP.NET user control.
Some applications may require additional installation options such as "install this or that option", "object qualifier", etc. and they can be specified using your custom control that will be integrated at the bottom of the installation screen.

The basic control may look as the following:

<%@ Control Language="c#" AutoEventWireup="false" TargetSchema="http://schemas.microsoft.com/intellisense/ie5"%>
<%@ Implements interface="DotNetPark.DotNetPanel.Modules.IWebInstallerSettings" %>
<%@ Import namespace="DotNetPark.DotNetPanel.Modules" %>
<script language="C#" runat="server">
  void Page_Load()
  {
  }
  
  public void GetSettings(InstallationInfo inst)
  {
   inst["ObjectQualifier"] = txtQualifier.Text.Trim();
   inst["ObjectQualifierNormalized"] = (txtQualifier.Text.Trim() == "") ? "" : txtQualifier.Text.Trim() + "_";
  }
</script>
<table cellPadding="2" width="100%">
 <tr>
  <td class="SubHead" width="200" nowrap>
   Database objects qualifier:
  </td>
  <td width="100%">
   <asp:TextBox id="txtQualifier" runat="server" CssClass="NormalTextBox" Text="" MaxLength="5"
    Columns="5"></asp:TextBox>
  </td>
 </tr>
 <tr>
  <td></td>
  <td class="Normal">
   Several instances of DotNetNuke can work with the same database simultaneously.
   They are separated by mean of database object qualifiers which are just
   prefixes for database tables, stored procedures, etc.<br><br>
   So, if you install your first instance of DotNetNuke on the selected database,
   leave this field blank; otherwise, specify some value, for example 'DNN'.
  </td>
 </tr>
</table>

 

It should implement "DotNetPark.DotNetPanel.Modules.IWebInstallerSettings" interface and import required namespaces. "InstallationInfo" is just a hashtable that all custom properties should be placed into.

7. Deploy all application pack files to

"[portal_install_folder]\DesktopModules\DotNetPanel\WebApplications\MyAppFolder" folder. The overall folders structure is shown above.

Can the installer register components and com+ applications in component services? 

Hi,

No, at present time it can't register COM+ applications. Web App Installer was primarily designed to install ASP.NET applications. If you are implementing .NET serviced components using COM+ through System.EnterpriseServices you can apply appropriate assembly-level attributes and COM+ application will be registered automatically on the first run. But, yes I can image the situation where installing unmanaged COM+ libraries (C++, VB6) is needed and of course you suggestion will be considered.

and about access rights? I'm assuming the Network Service must have special rights to the assigned apps root directories. This is also going to get interesting cause my apps have custom url rewriters also.

Hi,

You install application into the existing web site. When you create/change web site it sets correct permissions on the site's root folder and of course NETWORK SERVICE account in that list.

Ok now the application runs in 1.1, has quite a few tables, and sprocs, both of which are created in sql scripts along with default data. The app provides a cart, categories,  skinning, backend management, bla, bla bla,... basically complete ecommerce with affiliate and such very similar to agilebil but for asp.net. Now what I'd love to do is create an installer as such as dnn, commerce server and such to drop in along with other apps. So how do we get them to communicate with each other? in other words if one is logged in to one application on a particular domain and switches to say the forums to the portal or domain (DNN) or even the wish list on his/hers cart,(in which case the custom app i've installed). I know this app can check cookies or even through a webservice to see if the particular user is logged in or even trigger a login.

things that make ya go hmm....

lol

geez I feel like such an idiot.... if I'd had only checked out the demo's a little closer I probably could have saved myself half the time at configuring this....lol. I'm just wondering if we build DNP onto an existing server with domains, ip's, services and such... all of which we manually insert here.. Can we get DNP to manage these domains ad portals running within a plan? I'm thinking completely just restore db's and apps on the portals so monitored by DNP, but I need the apps each domain is currently running (under asp.net 1.1) to communicate the portal users for which they are created for.....


any hints or suggestions?

pinklloyd wrote:

Ok now my application runs in 1.1, has about 86 sql tables, 380 sprocs, both of which are created in sql scripts along with default data. The app provides a cart, categories,  skinning, backend management, bla, bla bla,... basically complete ecommerce with affiliate and such very similar to agilebil but for asp.net. Now what I'd love to do is create an installer as such as dnn, commerce server and such to drop in along with other apps. So how do we get them to communicate with each other? in other words if one is logged in to one application on a particular domain and switches to say the forums to the portal or domain (DNN) or even the wish list on his/hers cart,(in which case the custom app i've installed). I know this app can check cookies or even through a webservice to see if the particular user is logged in or even trigger a login.

things that make ya go hmm....

lol

I guess you are talking about Single Sign-On (SSO) solution, right? If so, I must say SSO is typically not a simple task and hardly depends on applications to be integrated. E.g. on DotNetNuke forums I saw a single SSO solution for integration of CommunityServer and DotNetNuke. You may probably take a basic idea from there.

pinklloyd wrote:

geez I feel like such an idiot.... if I'd had only checked out the demo's a little closer I probably could have saved myself half the time at configuring this....lol. I'm just wondering if we build DNP onto an existing server with domains, ip's, services and such... all of which we manually insert here.. Can we get DNP to manage these domains ad portals running within a plan? I'm thinking completely just restore db's and apps on the portals so monitored by DNP, but I need the apps each domain is currently running (under asp.net 1.1) to communicate the portal users for which they are created for.....


any hints or suggestions?

Regarding the migration from plain hosting (without control panel) sometimes it's better to-recreate all hosted resources (sites, FTP accounts, dbs, etc.) to fit control panel structure.

You can freely integrate/communicate with Enterprise Server as this application based completely on web services and that is the place where actual user accounts are stored. DotNetNuke portal when communicating with ES just creates a "shadow" copies of those accounts with all apropriate details, roles, etc.

So applications that are added through the application addin do not maintain user roles or rights with applications unless we script the membership structures correct? in some form of sql script to add the users roles?, let me understand this correctly..cause I'm lost, Do DNN's users, which are only shadow copied from DNP users and say Community Servers forum users are maintained under two different applications. So the user my create two account and login twice to the same domain. Now I realize each separate app has it own role management routines and even skinning techniques but is there has got to be a way, or maybe I'm looking at this the wrong way.

pinklloyd:

So applications that are added through the application addin do not maintain user roles or rights with applications unless we script the membership structures correct? in some form of sql script to add the users roles?, let me understand this correctly..cause I'm lost, Do DNN's users, which are only shadow copied from DNP users and say Community Servers forum users are maintained under two different applications. So the user my create two account and login twice to the same domain. Now I realize each separate app has it own role management routines and even skinning techniques but is there has got to be a way, or maybe I'm looking at this the wrong way.

Actually, you are right as DNP web app installer just helps hosting customers to install a separate web application with its own users base.

I guess what I'm really interested in is a way of implementing within the installer, the functionality of inheriting the user roles of the portal the application is to be installed within. I can assign most roles of my application within the web.config itself I'm just wondering if tying the two together is even an option.

We are going to add custom actions in the next installer versions, so you'll b able to inject your custom business-specific logic into application installation process.

My applications.xml file contains all the folders in web applications folder in enterprise server, which has time tracker, nGallery and more but only community server 2, personal website and DNN are available from the applications installer from within the control panel?

Hi Matt,

On the Applications Installer page you are displaying only applications that meet with your hosting space quota requirements. Here means that if your space doesn't have PHP quotas - you won't display any PHP applications in the list.