Today marks the day when the Orlando DotNetNuke User group officially has 200 members.

It was a year and half ago that I started this group with about 7 members who came and met on a Saturday morning to discuss issues relating to the best open source web portal, DotNetNuke. Will Strohl was there along with a co-worker. Will has been a great member and now great leader of the group.

More recently, Will was in charge of putting together the Day of DotNetNuke held last month at the Microsoft Office in Tampa, FL.

Many members are benefitting from this user group and I wish it continued grown and success.

So tonight after work and before the St. Louis .Net User Group meeting I ran to Borders to see if I could find my book on the shelf. Well guess what, I did!

I was pretty stoked to find it, but was shocked to only see the DNN4 book on the shelf, not any of the other DNN books. Well after digging around for a while I found them on another section, so I took the opportunity to organize a little :D Here’s the result.

I was recently asked how someone could manually delete a module once it is installed. The number of use cases where this would be useful is limited, but it is still a valid scenario that needs to be considered – especially during development.  Here is a walk through of the general steps required to delete a module manually.

1. Run the Uninstall script (if necessary)
2. Delete the module files from the DesktopModules and App_Code folder
3. Grab the DesktopModuleId
4. Delete the permissions associated with the module
5. Delete the module from the database
6. Refresh the site cache to update the UI with your changes

While I have not fully verified these steps to be the same in DNN version 5.x, they should generally be the same.  Here is some guidance to follow each of the defined steps above…

WARNING!  Performing these steps incorrectly could result in your DNN site being broken and/or no longer accessible.  In some cases, this might be permanent.  It is HIGHLY recommended that you perform a complete backup of your database and file system before performing these steps.  Doing so will give you a restore point, should something go wrong.

Run the Uninstall Script

Not all modules require a Data Access Layer (DAL), as some modules only perform utility functions and do not need to save and retrieve information from the database.  The majority of the module out there do have a DAL though, and in turn will have an uninstall script in their folder.  Look for a file named Uninstall.SqlDataProvider in the DesktopModules folder for the module you’re deleting.  Here is a reference path for you to use:

~/DesktopModules//Uninstall.SqlDataProvider

Assuming your module is named “WNSUtility”, the above path would look like this:

~/DesktopModules/WNSUtility/Uninstall.SqlDataProvider

Using the SQL Module in the Host Menu, execute this script.  Be sure to load the script, and then check the checkbox for Run as Script before you execute it.

Please Note:  If you are using a different Data Provider, the file extension for your uninstall script will be different.

Delete the Module Files

Deleting the files from a module is easy.  Find the module directory for your module.  Using the example from above, it would be:

~/DesktopModules/WNSUtility/

Delete all files from that directory, and the directory itself.  You might run into one or more errors do to files being loaded into memory.  Should this happen, you can release the file(s) from memory by recycling the Application Pool, or restarting IIS.

Grab the DesktopModuleId

This is a very important step, as the final two steps would be incredibly difficult without the DesktopModuleId.  There is not always an exact science to finding the DesktopModuleId, but we will need it for the following steps.  In most cases, I simply perform the following query on the database:

SELECT * FROM [dbo].[DesktopModules] 

WHERE [IsAdmin] = 0 

ORDER BY [FriendlyName] 

-- or 

SELECT * FROM {databaseOwner}{objectQualifier}DesktopModules 

WHERE [IsAdmin] = 0 

ORDER BY [FriendlyName] 

From the above script, locating the module in question is usually easy.  Simply find the module using its Friendly Name, and then record the DesktopModuleID associated with it.

Delete the Module Permissions

This step gets executed in three parts.  As long as there aren’t a lot of instances of the module in your site, these queries should execute quickly, and error free.

Using the DesktopModuleId from the previous step, execute the GetModuleDefinitions stored procedure, taking note of each ModuleDefID.  For each module definition returned, you will next need to execute the GetPermissionsByModuleDefID stored procedure, this time taking note of each PermissionID.  Finally, execute the DeletePermission stored procedure for each PermissionID that was returned.

Delete the Module from the Database

Now, we actually delete the module.  Doing so is very easy.  Like the previous step, we just need to execute a stored procedure using the DesktopModuleID we grabbed a little while ago.  Execute the DeleteDesktopModule stored procedure to delete the module.

Refresh the Site Cache

The final thing to do is to clear the cache on the site to remove the module from all of the user interface, such as the drop down lists.  You just need to clear the cache on the site.  I have blogged about clearing the DNN site cache before.

Yesterday afternoon Hal Hayes and I were invited to speak at the SharePoint Technology Conference hosted and organized by the SharePoint User Group DC (SUGDC).

The event was packed with sessions hosted by leaders and top professionals in the Microsoft SharePoint space. I was quite honored to be invited to speak, and if that wasn’t enough, I was speaking more on behalf of DotNetNuke rather than SharePoint.

I wasn’t really listening to podcasts until a few months ago.  I just really didn’t find anything that truly interested me to the point of putting down my personal 60+ GB of music and streaming my favorite radio stations.  Not to mention, I am a fan of the popular streaming service known as Pandora.  Anyway, I found the DotNetNuke Podcast about that time, and shortly after, DNN Voice was born.  Since I am so passionate about DotNetNuke®, I began listening.  Right now, I only know of those two DNN podcasts.

I have been listening to both podcasts for a while now.  Honestly, I like them both.  They have a different focus, and because of that focus, both are going to have a different fan base. 

DotNetNuke Podcast

Address:  http://www.dotnetnukepodcast.com
Host(s):  Lee Sykes and Richard Wooten (cannot find personal blog links)
Background:  Lee Sykes is the original person behind the DNN Creative Magazine website, which sells DNN tutorials and videos.  It has become one of the primary places to get DNN “how to” information on the Internet.  Richard Wooten is also part of DNN Creative, since February of 2008.  Both have been using DNN for a long time, and have a great deal of knowledge in using DNN.

It is fun to listen to the DotNetNuke Podcast.  Lee and Richard have a great chemistry, and it translates well into the podcast.  They basically speak about of the new things that they have heard about in the DNN ecosystem.  It almost feels like they each have a separate list of bullet points.  They talk about community news and information, but it usually not very much of their podcast.  Overall, they have some great information.

I love their summary on their website for each episode.  While it doesn’t look like their is a whole lot of organization to the information, it is well laid out for us to follow along on their site.  There is an RSS feed that is available to you to help you keep track of new episodes.  I have also seen Lee promote the shows on twitter.  Since I check twitter more often than I do my RSS reader, that’s how I usually get informed of the newest episodes.

In their About Us page, they ask for community input for the show.  That is really cool.  I haven’t noticed them mention any of their content coming from this feature though.

Some of their ecosystem “news” is sponsored.  While I understand why, and I don’t disagree with it (I am beginning something similar on my blog), I would much rather hear about ecosystem products and news that they find interesting or are passionate about for personal reasons.  In the end, it is still good information though, so it isn’t a deal breaker at all for me.

I am disappointed that community information doesn’t take a higher priority in the information they pass on to their listeners.  In my opinion, the community information is often more important than the ecosystem information.  Sure, they mention something about community here and there, but it is clearly not as much of a priority as I think it should be.

Something I really do not enjoy is the other tech news that get injected into the podcast, and this is a deal breaker.  The podcast is called “DotNetNuke Podcast”.  When I listen to it, I do not expect or want to hear about other technologies unless they have a relationship to the word “DotNetNuke”.

DNN Voice

Address:

Full Disclosure:  Even though I feel that I am pretty good at being objective, I do feel that it’s only fair to let you know that I have developed a personal relationship with Tom and Chris.  We speak regularly on twitter and the IM, and I have had them speak at our ODUG meetings.  Also, I did give some input to Chris about the podcast for the first few episodes.  So, while I believe that my review here is completely objective, you can use your own judgment and form your own opinion when I am done.

The DNN Voice podcast is very well-structured.  I has a pre-defined format that it follows the same path for nearly every episode.  For those of us that are techies (most of the audience), it gives us the routine that we typically enjoy.  I really like that the various sections have an audible queue to let us know when the next section is coming, and what it is.  Like the radio, it helps us to know when the next segment is coming.

Similar to Richard and Lee, Chris and Tom also have a great chemistry and it comes across well during the podcast.  Both podcasts do a great job of keeping each episode fun in the same way.  It sounds like we are eavesdropping on two friends having a good time talking about technology.

DNN Voice places a much higher emphasis on listener input by making it a prominent link on all pages on the site.  They also make this part of each episode, making it clear to the listener that their input is not only welcome, but they might hear it on the show.

In general, I do not think that we could have a podcast that isn’t sponsored in some way.  We must find a way to justify the time we spend on projects such as this.  DNN Voice’s sponsorship is less transparent than the previous podcast.  It is clear that the podcast has an affiliation with Engage.  Once again, this is not a deal breaker.

The main thing I really love about DNN Voice is that it appears to be a much better mix of community and ecosystem information.  This is very important to me.  In my opinion, the ecosystem is only successful and exists because of the community.

Like the DotNetNuke Podcast, DNN Voice makes its announcements for the podcast available through RSS and twitter.  However, DNN Voice takes this a step further by making the show available as a subscription through Zune and iTunes.  Also, while both podcasts offer up a comments mechanism on their site, DNN Voice takes this another step further by allowing their visitors to rate each individual podcast.

In Conclusion

Each podcast definitely has its own focus and specialty.  DotNetNuke Podcast seems to cater to the DNN’er who is mostly concerned about technology in general, and the DNN ecosystem.  DNN Voice appears to have its focus pointing directly at the DNN community member, and still includes more information, but stays within the DNN umbrella. 

I think it’s clear that I prefer DNN Voice over the DotNetNuke Podcast.  However, I cannot say that one is better than the other.  That depends on what you want in a podcast.  They each fill a void in the DNN podcast market.  However, all of the voids are not yet filled… Any new podcasters out there? :)

There may come a time when you will want to programmatically add a user to an existing role in DotNetNuke®.  It’s actually quite easy.  If you take a look at how the core code in DNN does it, just emulate that.  This method of using and reusing the existing DNN core code is what DNN development is supposed to be about, so make sure you don’t reinvent the wheel.

In the source code for DotNetNuke®, there is a controller class for nearly everything that you want to do with the various objects that you work with in DNN every day.  Since I am familiar with the DNN source, I knew where to go.  But many people are not familiar with the source code.  In those cases, you need to either do some searches in the Object Browser, or browse around until you find the code you’re looking for.  Thinking it through logically, you can usually browse right to the code you’re looking for since the core team has done a fantastic job of keeping the code files organized.

Keep all of that in mind, I immediately gravitated to the Security folder of the Components directory.  I did this because roles are part of the security framework in DNN, and all of the entities and objects are in the Components folder.  Inside this folder, I saw and opened the RolesController.vb file.  To make this clear, I opened the following file in the DNN source code:

~/Library/Components/Security/Roles/RoleController.vb

The controller classes are usually what we are looking for when we want to utilize the existing logic in DNN.  So, if I want to manage a role by putting someone into it, I naturally wanted to look for a Role Controller already – before I even opened the source code solution.

One of the methods of the RoleController class is AddUserRole(), and it has a few overloads.  We are only concerned about the root method right now.  This method accepts a few arguments, and when successfully called, it adds an existing user to an existing role.

RoleController.AddUserRole(integer PortalID, integer UserId, _ 

    integer RoleId, date EffectiveDate, date ExpiryDate)

Using this method may look self-explanatory, but I will explain it anyway.  When you intend to use this method, you should already have access to an existing UserInfo object, and a RoleInfo object.  Both are regularly available through standard module development.

• PortalID (integer) – This is the id number representing the portal where the user and role exist.  The SqlDataProvider will use this value to correctly match up the objects.
• UserId (integer) – This is the id number matching the user that you want to add to a role.  Most often, you would simply access this value from the PortalModuleBase class that your module inherits.
• RoleId (integer) – The id number of the role can be found from any number of ways.  We can only assume that you already have access to this right now.
• EffectiveDate (date) – This is the date that you want the role assignment to begin.  Usually, the current date is what you’re intending to pass to this argument.  This argument accepts a null value.
• ExpiryDate (date) – This should be the date that you want the role assignment to expire, and as a result, the user will be removed from it.  This argument accepts a null value.

In more recent versions of DNN, there is also another value which we do not pass to the method.

• CreatedByUserID (integer) – This is a value implemented for auditing purposes, to let us know who added the person to the role.

Let’s assume that we have a UserID of 123 and a RoleID of 10.  Going further, we will also assume that this is a first instance of a portal, equaling a PortalID of 0.  The most common role assignments do not pass an EffectiveDate or an ExpiryDate.  We will use this as an example as well.  Here is how we would call the method:

' we are assuming that you already have an intRoleId from your logic

RoleController.AddUserRole(Me.PortalID, Me.UserId, intRoleId)

' ... or ...

' Here we assume a role assignment for 30 days, beginning now

RoleController.AddUserRole(Me.PortalID, Me.UserId, intRoleId, DateTime.Now, DateTime.Now.AddDays(30))

That’s all there is to it! :) Easy, right?