Several interesting posts or blogs have been published, explaining how to start a new module for DNN. Among them, Todd Davies, Vincenç Masanas, Michael Washington and Vladan Strigo have greatly helped the community. Gilles, my co-lead in the Store Project, has forged his very own method to setup a new project, trying to pick up the best from each of them. Please search these blogs and forums, and read our venerable predecessors also, since no single solution can meet all needs. This one is probably one of the best compromise, and it is perfect for large projects, as well as simple mono-project modules.
In the scope of this blog, we will only consider the WAP model. This should not be a problem anymore, since the compiled build model has been added to Visual Studio Express with SP1.
Expected benefits from this method
Our goal is to set up a Visual Studio development environment where we would just have to ‘generate the solution’ in order to obtain:
- – the latest changes immediately reflected in the test website ;
- – possibility to debug and trace step-by-step. (although the wap model will not permit to go as far as edit & continue);
- – a package almost ready to be shipped as a regular DNN module after every rebuild (packaging a module is out of the scope of this article, but I will give a few hints about that in step 15 below);
We don’t want to have the whole DotNetNuke solution rebuilt every time though, because this takes time. Keeping the solution light was another requirement.
We assume that you have a working DNN website up and running, and VS 2005 or VS 2008 pro installed. This should work with VS 2008 express with SP1 and using the WAP model, but we have not tested it yet – feedbacks are welcome.
Note that you do not need a source version of DotNetNuke installed, although it might be usefull to have immediate access to the source of many objects that you will use in your own code sooner or later. On the other hand, if you choose to install a source package of DNN, there will be no negative impact on build performances, thanks to the trick explained at step 11. As developers, installing the core with sources will therefore be our preferred choice.
So let’s go for a simple project
Let’s create a new module. In this blog I will demo with a simple module, which contains a unique project. If there is a positive feedback, we will explain in a future blog how this method can be adapted to multi-module projects like DNN Store.
Since our module will be made of a single Visual Studio project (which will also be the unique project of a ‘Visual Studio solution’), let’s give all these entities the same name: MyNewModule. When we adapt this method to the store module, we will need more elaborate naming conventions, because Store is, in fact, a set of several ‘dnn modules’ (cart, catalog, etc), each of them built with several Visual Studio Projects (where the ‘dnn modules’ do not line-up with the ‘VS project’). That said, apart the naming convention that is simplified here, the basic principles of Gilles’s method can be adapted to setup more complex solutions.
To make it simple here, we will create a Visual Studio solution “MyNewModule”, in the Windows folder “Website\DesktopModules\MyNewModule” of our DNN installation. This solution will contain a single project, named “MyNewModule” and generate a DNN module, also named “MyNewModule”.
- Open Visual Studio without any solution or project. Your solution explorer is completely empty.
- File/open/website (or Maj+Alt+O). This opens a window to select your DNN website in the ‘Local IIS server’ list. Select it.
- Rename the solution ‘MyNewModule’
- In the solution explorer, note the line below solution ‘MyNewModule’, starting with http://localhost/DotNetNuke_2 (or whatever name you gave you site in IIS). More on this later.
- Right-Click Solution ‘MyNewModule’ and add a new project (or File / Add / New project)
- Select DotNetNuke Compiled Module. Name it MyNewModule and make sure that the path ends with \Website\DestkopModules. Suppress the trailing \MyNewModule from the path, otherwise you will get a folder inside a folder like Russian puppets.
- Your solution should now contains 2 projects : a ‘web site’ named something like http://localhost/DotNetNuke_2 ; and your actual project named MyNewModule
- Click once over Solution ‘MyNewModule’ to enlight it, and save it.
Setting the properties for the ‘website project’
9. RightClick the website project (the line starting with http://localhost/etc
in you solution explorer), and select the properties page. The first two tabs there are ‘References’ and ‘
- Select References, Add a reference, Projects. You should find MyNewModule there. Add it. This will trigger a post-compilation action that will automatically copy our project dll into the general website \bin directory, after every build. This step is a key point in Gilles’s technique since it will save you countless copy and paste of the dll after every build. It tells Visual Studio that the website needs the ‘MyNewModule’ dll, so after every build it will copy it into the \bin directory. And this is exactly what we want, so we can test and debug our newly compiled module in our DotNetNuke website, live.
‘generate’ 'build' and unclick ‘ generate build the website with the solution’. You should also set the action before start to ‘Do not generate build’. All this means that we have only included the website in our solution in order to obtain some automation when we rebuild our modules, but we do not want to regenerate the website itself since this is not what we are developing for (note : the term 'generate' was an incorrect back-translation from the french for 'build'.
- Set the website as the start project. You may find it strange to start with the project that we do NOT want to
generate build ? The reason is that in a DotNetNuke website, it does not make sense to start a module without opening a portal. We always open the DNN website first, and from there it will execute our module. Somehow, running the website is a prerequisite to running our module.
Setting the properties for ‘MyNewModule’ project
- Open the properties page for MyNewModule project. The tabs there are Application, Compiler, References, Ressources, Parameters, Signature, Extensions My (VS 2008) and Web.
- Application: set the assembly name to MyCompany.Modules.MyNewModule
and the root namespace to MyNewModule (or leave the namespace empty) (Edit: in C# you may keep the namespace 'MyNewModule', but in VB.NET leave it empty). When developing a core module like Store, MyCompany would be DotNetNuke. So if you have Store installed, and look into you Website\bin directory, you will find files like DotNetNuke.Modules.Store.Cart.dll
- Compiler: generation events / post build. This point is optional and you can step over if your project is not for distribution. If you want to make it an installable module, it is here that you can get the copy and paste chore done for you. You will typically add here the copy commands that will flatten all the files hierarchy from your project to the dedicated package folder where they will be zipped together: ascx, images, dll, documentation, etc). If any file add been added or deleted since the previous build, you would still have to edit the manifest by hand. Have a look at the Store solution to check out how Gilles uses this technique to automate the packaging of a module that is made of many projects.
- References : add a reference , browse and add DotNetNuke.dll. Uncheck ‘local copy’. Unchecking the local copy is a time and disk space saver, that will avoid multiple and useless copies of DotNetNuke’s dlls into your projects folders.
- Web : Use the local web server and set the project URL to something like : http://localhost/DotNetNuke_2/DesktopModules/MyNewModule and replace the application root URL to : http://localhost/DotNetNuke_2 (or whatever). This will allow working in design mode as well as code view. If you skipped this step, your source files would be unable to resolve the tilde (~) and find their roots.
- Generate the solution.
Done. You can now install the generated module into your DNN website, test it, and the next time that you change your codebehind (and, of course, any ascx or resource files), the changes will be reflected into you local website with a single refresh.
You can also set breakpoints into your code, and press F5 to compile, run and debug the module from Visual Studio.
Gilles le Pigocher and myself hope that this method will be helpful, and we will be very pleased to read your comments, suggestions and improvements.