Developing 5.x.x Modules in VS 2008 in Team Environment.

Module development can be very challenging, but with a little effort, it can be very easily simplified. But, when we talk about team development, things change a bit. Here is the scenario:

Visual Studio 2008 (VS08)

DotNetNuke 5.1.1 Install (DNN) http://www.dotnetnuke.com/tabid/125/Default.aspx

3 Member Team

3 Sandboxed Development Portals (sbox1,2,3)

SQL Server 2008 (SS) http://www.microsoft.com/express/sql/default.aspx

Visual Source Safe 2005 (VSS) http://msdn.microsoft.com/en-us/vstudio/aa700907.aspx

Microsoft .NET SDK 2.0 (or higher) http://www.microsoft.com/downloads/details.aspx?FamilyID=fe6f2099-b7b4-4f47-a244-c96d69c35dec&displaylang=en

*This article is not going to go into the depths of configuration of IIS, Sql Server, Visual Studio, etc. Feel free to ask questions about the best practice for configuring either.

What we are trying to accomplish is the development of a module, within an existing sandbox, without dependencies on that sandbox. Basically I should be able to check out a module from VSS and develop in my own instance of VS, check the module back in, and let someone else do the same.

Development Tiers

Our development setup has three sandboxes, each with their own database and virtual directory, thus totally isolated. From those development sandboxes, we want to push modules into a test environment, and then into production. Periodically, we will refresh the development sandboxes with the latest production environment. Thus, retention of code in VSS and positioning in the sandboxes is crucial.

Networking

In order to ensure strong flexibility, we are doing our development across network shares. This further complciates things, because Visual Studio's access of the file system is based on the .NET trust center.

Steps

1. Make sure that you have all the components described in the above list, installed and updated. This is crucial.
2. Create the File Share - Assuming you are using IIS6+ on the development server (Server 2003/8), create a file share, and set the permissions with at least read/write level privelege for the users/group that will be developing against the server. This file share should be pointed at the root of the sandboxes. In our case, we have "c:\inetpub\wwwroot" shared. There are three directories in the next level up on the tree, one for each sandbox. So the UNC path looks like this "\\webdevservername\wwwroot" in the format of \\{servername}\{sharename}
3. Install the DNN Install Code into each of the sandboxed roots. Set IIS VDs to point to each sandbox root, and work your way through the installation process.
4. Set Trust Level priveleges - Visual Studio will not trust your fileshare by default. There are some pretty amazing things that you can do with GPO in a domain environment to automatically address this, but the sake of keeping this individualized, make sure that you can manage your own trust level.
   
   Open the Visual Studio Command Prompt - Start>Programs>Visual Studio 2008>Visual Studio Tools>Visual Studio Command Prompt
   Issue the following command with the information filled in correctly.
   
   caspol -m -ag 1.2 -url file://\\{servername}\{sharename}\* FullTrust
   
   If executed correctly, this should keep you from running aground on Trust Issues during the rest of the process.
   *This step will not work if you have not installed the .NET SDK
5. Create a new DNN module - Open Visual Studio and create a new project. Under Web choose DotNetNuke Compiled Module
6. Save the project. Make sure you save into your source control! When you save the project, save the project into the shared folder location: \\{sharename}\{siteroot}\DesktopModules.
   
   
   Edit references
7. By default, when you create a new module, it will be referencing a non-existent DotNetNuke installation. You will need to delete the current instance.
   a. In the Solution Explorer, click the button for Show all Files.
   b. Expand References and delete the DotNetNuke Reference.
   c. Right-click on References, and Add a Reference.
   d. Under the Browse section, navigate back to the root install location, and into the bin folder.
   e. Select DotNetNuke.dll
   f. Click OK
8. Right Click on the Project Name in the Solution Explorer, and select Unload Project
9. Right Click on the Project Name in the Solution Explorer, and select Edit {Project}.vbproj
10. Find section with the following:
    
    <Reference Include="DotNetNuke, Version=5.1.1.98, Culture=neutral, processorArchitecture=MSIL"/>
    
    and fix it so it contains a HINT. Mine looks like this:
    
    <HintPath>..\..\bin\DotNetNuke.dll <HintPath>
    
    
11. Right Click on the Project Name in the Solution Explorer, and select Reload Project
    
    Set Build Info
12. Right Click on the Project Name in the Solution Explorer, and select Properties
13. On Application tab, make sure that the Root Namespace input is empty.
14. On the Compile tab, make sure the Build output path: is set to "..\..\bin\"

That's it! You should be able to save the project now, and take it in and out of source control, while building within the portal...

When you build, the module should be able to put the DLL into the DNN Bin folder, which should give you the ability to make changes, rebuild, and view your module's changes in whichever sandbox you saved it into.

In order to traverse the mulitple sandboxes, you simply need check the source back in, and when you get the latest version, set the working directory to be the DesktopModules folder in whichever portal.