DotNetNuke Module Development

出处：http://dnnjungle.vmasanas.net/Default.aspx?PageContentMode=1&tabid=27 DotNetNuke Module Development    Delevopment Setup|What are Private Assemblies (PA)|Installing DNN|Database|VS.NET|Web.config   Delevopment Setup If you plan to create modules for DotNetNuke using Visual Studio.NET there are a couple of things you should consider. There are multiple possibilities to setup a development solution for DotNetNuke (see DotNetNuke Project Development). Most of them use similar approaches and differ only slightly. The setup explained here is what I'm currently using, and is in accordance with the multiple tools I'll explain to you. So if you plan to use the templates provided here, you should be familiar with this setup to avoid any troubles using them. It will be a good reading too if you're starting with DotNetNuke and don't have a very clear understanding of it's internals and module development. What are Private Assemblies (PA) When you work with DotNetNuke you should try not to modify any part of it. What? Yes, if you want to be in sync with the current version of DNN you shouldn't modify the core. Otherwise, when a new version or service pack arrives you'll be in trouble because you'll have to repeat all your local modifications to the new version. Private Assemblies are the solution to extend DotNetNuke without modifying it. You create all your new modules as separate projects that can be plugged into the portal without having to change anything. You deploy your newly created modules as independent assemblies (dlls) and web controls. For a deep understanding of PA concepts read Private Assemblies on the msdn web site. Installing DNN First of all you need DotNetNuke latest sources. Go to DotNetNuke Downloads, get the last published package and save on your local machine. Here we have the first choice: do you want to put DNN under your wwwroot folder or on another one? There's no need to have DNN under wwwroot, you can install it wherever you want. I use to have a folder where I create all my local DNN installs, let's say c:\dnnweb (I use this folder as my wwwroot for all DNN related stuff). As an example I will use training for my virtual directory, so my local dnn installation would end up being accessible by http://localhost/training. Create a new folder: training Unzip downloaded package into this folder Read training\Documentation\Readme.txt for detailed instructions on file permissions. If you set the permissions on the parent folder (c:\dnnweb) before creating any file under it, all permissions will propagate to child folders and files and you'll never have to worry about it. Create a new web application on this folder, either through IIS Manager or going to folder properties "Web Sharing" tab. Give a name (training) to the new Virtual Directory, this will be the path to access you portal (in our case http://localhost/training). I recommend using the same name as in the folder name just to keep things in order. If you ever want to install another instance of DotNetNuke repeat these steps changing the names of the folder and the Virtual Directory. This is a good way of maintaining separate projects and separate development/deployment instances of DotNetNuke. If you're developing a number of modules for a specific purpose it's often better to isolate them from other unrelated modules you could have. Using this approach you can develop modules on different solutions/websites/portals. The default DotNetNuke Visual Studio.NET Solution file is setup to look at http://localhost/DotNetNuke so if your local instance of DNN is other than this one you should modify this two files: DotNetNuke.sln: replace http://localhost/DotNetNuke/DotNetNuke.vbproj with http://localhost/<YOURVIRTUALDIRECTORY>/DotNetNuke.vbproj DotNetNuke.vbproj.webinfo: do the same change here So lets edit these two files so they both have: http://localhost/training/DotNetNuke.vbproj Again if you are working with multiple copies of DotNetNuke all solutions will be named equal (DotNetNuke.sln). I suggest you to change this to the name of the Virtual Directory where it is installed. Otherwise, you'll see in the start page of VS.NET a couple of DotNetNuke projects. It's very easy to open a project instead of another and make some changes in the wrong place. The solution file for this project will be renamed to Training.sln. Database Setup Now it's time to create a new database for this site. Open SqlServer Enterprise Manager and create a new database. Again I recommend using the same name as the project folder or a related one. To follow our example this should be called training. Once it is created we have to decide which user we will use to connect to it from DotNetNuke. It's a good practice not to use the sa (System administrator) account. This is a highly privileged account that should only be used in your maintenance routines, never as a normal login account. Go to Secutity -> Logins, right click and select New Login. As always it's a good practice to use a user name related to the web application it should connect to.   I'll be using trainingLogin as an example. Select Sql Server Authentication and select the default database for this user. Next thing to configure is on the Database Access tab. Just give permission to the training database and make this user dbo_owner of this database (this means this user will be the owner of the database). Using this approach you'll create a database that will only be accessible by this user (except for other privileged accounts). So your new DotNetNuke site, once configured, will only have access to this database and you'll be sure that no other DotNetNuke instance on your computer will access this same database. VS.NET Now you can open the newly installed DotNetNuke solution in VS.NET by double clicking the solution file Training.sln. You can also load the solution from the file menu, Open Solution dialog (just make sure you open the solution file (.sln) and not the DotNetNuke project (.vbproj). When you first open this solution you should see that in contains for projects: DotNetNuke. This is the main DotNetNuke project Provider.AccessDataProvider. Data access provider for Microsoft Access database Provider.SqlDataProvider. Data access provider for Microsoft SQLServer YourCompanyName.Survey. This is the project for the Survey module. Since I don't use Access nor the Survey module, the first thing I do is remove these projects from the current solution. It only removes the projects from the solution, not from the disk. If you ever need them, you'll always be able to add again by choosing Add -> Existing Project from the solution node. And now, just to make sure all is working try to rebuild the solution. You should get something like this: ------ Rebuild All started: Project: DotNetNuke, Configuration: Debug .NET ------ Preparing resources... Updating references... Performing main compilation... C:\DNNWeb\Training\DesktopModules\XML\XmlModule.ascx.vb(111) : ... Building satellite assemblies... ------ Rebuild All started: Project: Provider.SqlDataProvider, Configuration: Debug .NET ------ Preparing resources... Updating references... Performing main compilation... C:\DNNWeb\Training\DesktopModules\XML\XmlModule.ascx.vb(111) : ... Building satellite assemblies... ---------------------- Done ---------------------- Rebuild All: 2 succeeded, 0 failed, 0 skipped Web.config Web.config is the configuration file for a web application. It's an XML file with some predefined elements and attributes. A Web.config files can have a number of diferent entries depending on your application needs. One of this needs is giving the correct parameters to connect to the database. This parameters are set in what is called the ConnectionString. The ConnectionString is a collection of parameters separated by semicolons that specify all needed information to connect to a given data source. For each data source you'll have diferent parameters an options. A good place to visit if you ever forgot how to setup a ConnectionString is ConnectionStrings.com. DotNetNuke stores the database ConnectionString in two diferent places. In <appSettings> element. This entry is maintained for backwart compatibility for modules previous to version 2.0 In <dotnetnuke> section. This section defines all installed data providers and sets its parameters. In both places find the connectionString attribute and set it accordingly to your database. For example: In <appSettings>: <add key="connectionString" value="Server=localhost;Database=training;uid=trainingLogin;pwd=<...>;" /> In <dotnetnuke> section: <add name = "SqlDataProvider" type = "DotNetNuke.Data.SqlDataProvider, DotNetNuke.SqlDataProvider" connectionString = "Server=localhost;Database=training;uid=trainingLogin;pwd=<...>;" providerPath = "~\Providers\DataProviders\SqlDataProvider\" objectQualifier = "" databaseOwner = "dbo" Attention: Don't forget to set the default provider to SqlDataProvider (by default it uses AccessDataProvider) After this changes are done and the Web.config file is saved you can open you Internet browser and point to: http://localhost/training When you first browse a DotNetNuke installations it creates all database tables and objects. After all this work is done, the default DotNetNuke portal should show on your browser.

转载于:https://www.cnblogs.com/henry_zjk/articles/73736.html