July 25, 2013

Enterprise Extension Development with DNN Part Two

A few weeks ago I set the stage for this series of posts with my Enterprise Extension Development with DotNetNuke Part One post.  This article, the next in the series, ended up getting delayed a bit.  As many of you know there has been a lot changing within the DotNetNuke world, as all of this unfolded my priorities were pulled from these posts to other areas of concern.  Now, I'm back on these posts and want to make sure to dive into this in detail.  In the first post of the series I covered the high-level details.  The reasoning behind this series, and the main goals that I hope to accomplish by putting this information out there.  This post is dedicated to the development environment, and development structure for our projects. 

Importance Of Project Structure

Why is it so important to start with project structure?  Why not start with development environment?  Or local DotNetNuke installation?  The answers to these questions are actually fairly straight forward if we take a step back and look at this process from a bit of a different angle.  You as the reader is looking at this post for information specifically on how to develop for DotNetNuke, how to use the platform effectively.  This is great for the person that wants to learn all there is to know about a solution.

However, in the end, when working with an Enterprise grade solution built with the DNN Platform it is important to look at what is necessary to get someone up to speed.  Enterprise projects might change hands between multiple developers, often times with differing experience levels with .NET and/or DotNetNuke.  To have a successful project of any scope the "time to develop" needs to be low.  In this post we will look at setting up a DotNetNuke project WITHOUT having a DotNetNuke installation on your machine.  This means that any developer, experienced with DotNetNuke or not, will be able to pull your code, build the project, and successfully deploy a change if necessary.  No custom configuration of their machine, no local installation of DotNetNuke, no third-party downloads necessary(Only necessary for new project templates).  Just simple development!  Once we get to this point with a single DotNetNuke module, we will start to talk about sharing and structure within the module(s) to support extensibility.


To make all of the items discussed in this project work you will need to first download and install Chris Hammond's DotNetNuke Module Development Templates.  For the current time, these templates will work as a good starting point for our development efforts.  In the end, you might customize the templates a bit to handle your specific environment, however, this will work to get going.

Secondly, all of the documentation/processes that are discussed in this post assume the usage of Visual Studio 2012 and the C# programming language.  None of the items here are different if using VB, I just don't have detailed examples.

Creating Your Project

The first step in the process here is to create your new project using the C# template.  At this point though we are going to start to diverge from the standard process.  As you select "File" -> "New Project" in Visual Studio and select the C# Module development template, we are not looking to create our project inside of a /DesktopModules/ folder of a DotNetNuke installation. 

When selecting the the save location, simply find the location that makes sense for your environment.  In my case we utilize TFS for source control.  We have multiple Team Projects for some of our larger clients and then a "small projects" Team Project for those little jobs.  This means that we could be creating a project on a disk location of D:\tfs\companya\projectb\R1\Source\ or any other arbitrary location.  This portion of the process TRULY doesn't matter.  Just find the location and create your project.

Try to build your project.  You will notice that it fails to compile and will complain about MANY missing references.  This is to be expected! 

NuGet to The Rescue!

A while back I blogged about the recent existence of NuGet packages for DotNetNuke.  In that post I eluded a bit to the purpose of these packages and how they can help resolve issues, but didn't give a lot of clarity.  NuGet is a Package Management platform, a system that allows developers to consume packages within their projects.  In this context a package is defined as a consumable assembly/project/etc.  For example there are packages for jQuery, jQueryUI, and many other frameworks. 

With these new DotNetNuke packages we have the ability to consume DotNetNuke in our projects, allowing us to compile/reference DotNetNuke without needing to setup a full development environment.

With your newly created project open the "Package Manager Console" which is available from the "Tools" menu.  This will open a command prompt window for working with NuGet packages.

From here, simply type the following, without the quotes.  "Install-Package DotNetNuke.Core -Version 7.0.0" and press enter.  This will download the Core package that has all of the base dll's necessary for working with DotNetNuke.  (NOTE: If you would like, you can update the -Version 7.0.0 portion to -Version 6.0.0 if you would like to target DNN 6.x and later rather than DNN 7.x and later.)

Once you see confirmation that the package was installed, compile your project.  You will notice that your project now compiles successfully. This right here is the first step to successful enterprise development.  Once this package has been installed, any user that gets a copy of the project, regardless of where they store the code files on their machine, they will be able to compile your code.  Compiling with this template in release mode will additionally create the proper DotNetNuke installer, so your project will be set to go! 

What's Next?

Now that we have a clean project, that can be compiled anywhere, we can start to move on to the next step of the process.  Determining exactly how we should be structuring our projects.  If you are working on a solution with a single extension, the steps up to this point should give you a bit of flexibility that already will reduce some of the burden of DotNetNuke development.

In the next posting, which will be posted in the next few days, we will dive into the specifics of larger projects, those with more than one extension, and sharing between them all.  Feel free to share your comments/feedback below.

This article was cross-posted on my DNN Software blog.

tags: DNN, DNN Development
comments powered by Disqus

Content provided in this blog is provided "AS-IS" and the information should be used at your own discretion.  The thoughts and opinions expressed are the personal thoughts of Mitchel Sellers and do not reflect the opinions of his employer.

Content Copyright

Content in this blog is copyright protected.  Re-publishing on other websites is allowed as long as proper credit and backlink to the article is provided.  Any other re-publishing or distribution of this content is prohibited without written permission from Mitchel Sellers.