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 the project structure? Why not start with the 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, oftentimes with differing experience levels with .NET and/or DotNetNuke. To have a successful project of any scope the "time to develop" needs to below. 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.
Prerequisites
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 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 set up 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 burdens 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.