建立单独的解决方案来开发DNN模块

在整个DotNetNuke(以下简称DNN)解决方案之下建立和调试DNN模块项目都比较容易并且还可以随时“转到定义”看看DNN框架中类的内容,惟一的缺点就是慢!打开和编译一次DNN就要花去几分钟的时间,调试一次更是需要七、八分钟,偶然的来上一两次,就要耗去十几分钟的时间。晕,时间就这样在等待中流逝了。
  为DNN模块建立单独的解决方案就可节省大量的时间了。建立单独的解决方案进行模块开发需要解决三个问题:
1、在什么地方建立解决方案有助于边开发边测试?
2、如何对原有dll进行引用,生成的dll又到那个目录中?
3、怎样进行调试?

我建立DNN模块开发环境的顺序如下:
一、建立模块项目
1、在DNN程序的DesktopModules目录下建立DNN模块项目,项目名称为模块名称。
2、重名命名项目名称为“公司名.模块名称”。如果您的项目名称为“公司名.模块名称”就可以省略这一步。不过我不喜欢模块所在文件夹的名字为“公司名.模块名称”。
3、引用“DNN程序的bin目录”中DotNetNuke.dll组件。
4、配置项目属性:
1)、修改程序集名称为“公司名.Modules.模块名称”
建立单独的解决方案来开发DNN模块

2)、导入一些默认命名空间,如果不做这一步就需在单个源代码文件中用Imports语句导入所使用命名空间(我喜欢单独导入)。
建立单独的解决方案来开发DNN模块

3)、设置项目输出路径为“DNN程序的bin目录”,这样可以将编译所得的dll文件直接复制到运行目录中,以免每次都要手动复制。
建立单独的解决方案来开发DNN模块

5、创建模块控件文件ascx,一般都有三个ascx文件:模块名称.ascx、Edit模块名称.ascx和Settings.ascx。在类库类型的项目中不能直接添加“用户控件”,我是从别的地方复制过来后在修改,希望知道更好的方法。
6、在模块目录下建立App_GlobalResources目录,用来放语言资源文件。
二、建立模块相关的SqlDataProvider项目(有些模块不需要访问数据库,那么这一步也可以省了)
1、在模块目录下的Providers\DataProviders目录下建立DNN模块SqlDataProvider项目,项目名称为“SqlDataProvider”。
2、重名命名项目名称为“公司名.模块名称.SqlDataProvider”。
3、引用“DNN程序的bin目录”中DotNetNuke.dll组件和Microsoft.ApplicationBlocks.Data.dll组件。
4、引用“DNN程序的bin目录”中对应模块组件“公司名.Modules.模块名称.dll”。注意:在这里不能直接引用模块项目而需要引用模块组件,主要是因为引用模块项目会引起生成时的一个错误。大家可以试试直接引用模块项目,看看会不会有问题。
5、配置项目属性:
1)、修改程序集名称为“公司名.Modules.模块名称.SqlDataProvider”
2)、导入一些默认命名空间。
3)、设置项目输出路径为“DNN程序的bin目录”。
仍然存在的问题:因为该项目是引用的模块组件,所当模块项目重新编译后需要重新再次引用。
三、在DNN中设置运行环境
1、利用host身份登录,在“主机管理-->模块定义”中“增加新定义”。
2、保存后在添加相关的控件,比如查看、编辑和设置控件。具体每个控件都用什么样的key和类型,可以参照其它模块中的设置。
四、调试程序
有一篇文章有详细介绍:http://esshs.cnblogs.com/leeichang/archive/2004/11/16/64418.html
默认情况下,ASP.NET 进程(对于 Windows 2000 和 Windows XP 上的 IIS 5.0 和 IIS 5.1 为 aspnet_wp.exe,对于 Windows Server 2003 上的 IIS 6 为 w3wp.exe)作为 ASPNET 进程运行。因此,要调试它,您必须具有运行 ASP.NET 的计算机的管理员特权。

  其实我们还可以利用dnnjungle的模板来建立DNN模块项目,我试用了一下,它默认生成的代码和DNN自带模块的代码风格不太一致,我需要改好多地方所以没有采用,大家有兴趣可以试试。欢迎交流试用心得!

你可能感兴趣的:(解决方案)