Last post Jan 11, 2006 02:35 PM by csalee
Jan 10, 2006 05:38 PM|csalee|LINK
Jan 10, 2006 10:10 PM|thecrispy1|LINK
This happens to be a subject I am pretty close to. There are two different scenarios, one being the core and all its projects which uses Sourcegear Vault. The other is what my company uses which is SVN. Looking at the info you gave and what you are really
asking, I will focus on the SVN. One thing that should be noted is we do everything we can to never actually alter the DNN Core project. This, however, is not always possible (for my company mind you). If this happens we keep a list of all changes from
the original base.
-Store Custom Modules within the DNN file structure vs Store Custom Modules away from DNN.
Before we even get to answer this, it is important to understand how we actually setup our dnn in source. We have two seperate repositories. The first one is DNN.Core which has the latest released version we are working with and all its source. We put
almost all files from DNN in here. There is no dll's, nothing in desktopmodules, no PortalId folders, and the only items we keep in the controls directory are items which are under source or needed by DotNetNuke Core itself. The other one we name DNN.DotNetNuke.
This is where we actually store the items in the controls dir (those items which are not in the other source), all desktopmodules contents and also all our custom desktopmodules. We also keep a special file web.config.default which has all our information
for quick setup of a site. There is also an added Database folder we use which houses and sql scripts that may be needed for in development things, db backups if necessary (sometimes you need one to replicate an error or to share same data if a dev team is
concurrently working on a bug fix or anything else this may be needed for).
When a developer gets the source the first time they grab the DNN.Core and the DNN.Dotnetnuke projects and put them in seperate folders (we mimic our source control in terms of filestructure and naming). The next task is for the developer to copy the files
from Core into the DotNetNuke one. There should be nothing getting overwritten here. The next step is to setup IIS, DB, and run nant for the first time. (We have a couple nant scripts we wrote to handle all this). This script will build all the necessary
dll's to get you going, and you can fire off a module.build file for each desktopmdoule you need as well (these are custom mods in this case). The dev calls the site for the first time in the browser and the db is setup (unless they are using db backup for
-Store the installed DNN that has been customized vs store the uninstalled DNN.
I am not sure what you are looking for here.
-How do people keep track of 3rd party modules that you modify the source code? This can get tricky when the module comes out with a new version, so you need to keep track of it that you modified it.
This again is like how we handle core. We really try not to make changes to custom modules unless we have to. If we do have to make changes, the module would be part of our DNN.DotNetNuke source. I recommend keeping a list of changes in this source as
well. In my experience if the module required changes it was usually drastic enough that I wouldn't consider it the same module and would use beyond compare along w/ my list to upgrade this.
Jan 11, 2006 08:50 AM|flanakin|LINK
Jan 11, 2006 02:35 PM|csalee|LINK