Development Strategies - Assembly Positioning

Application frameworks like DotNetNuke can really stretch the conceptual basis for development within Visual Studio. Solutions, Projects, References, and other modeling components must be considered differently within the strategy.

GAC vs. DNN (Copy Local)

When developing in VS, if there is a bit of functionality that you would like to use, but do not have yet, you may go directly into the open-source commmunity to find the widget. However, this widget might have an installer, which puts the assemblies into the global cache (GAC). When you reference that code in your project and run your builds, you will likely not notice the references made to the GAC until you try to deploy your project onto a production server. When you do, your application may not be able to locate the resource. This leads to a very interesting discussion question and ensuing discussion -- When I build my projects, how do I make them fully portable with solutions referencing my local cache?

If you have run into this problem before, you might be thinking that the solution is very simple. Simply right-click on the reference in studio and set to "copy local." If configured correctly, when the VBE.exe command is run in studio (this happens when you Build, Rebuild) there will be a switch added to copy the codde out of the global cache into the local project to make it fully portable. Solved!

However, in the DNN world, all projects are developed within and then deployed into a framework which is a layer up from .NET. The signficance of this, from a development perspective, is more fully understood when we look at trying to have projects reference each other.

For example, if you wanted to add Functionality: F to the portal and have the Widget: W access it, the process would go like this:

1. Develop and deploy F into the portal.
2. Develop and deploy W, with a reference to F into the portal.

However, problem arises when W is being developed. Unless W and F are in a state of total solidarity, where it is known fully that no environmental factors that affect W will affect it apart from F, and vice versa, one cannot develop in the normative Visual Studio Strategy.

In the normal VS strategy, one would create a Solution, and add a new project F. Then W would be added and in W's reference, the F project would be referenced. Then upon deployment, both packages would have no problem communicating via their complied assemblies.

However, say you were working on a team of people who are working to establish a level of functionality beyond the scope of default portal modules, and you installed 5 different modules, all contributing to an overall strategy, but independent in their scope. You would either need to make everything one hugh solution, and limit yourself to working, one team member at a time, or you would need to make sure that if W references F, that the reference will transfer well.

So, all that mumbo jumbo stated, the basic reality comes down to solid practices of Assembly positioning:

DNN Site BIN

It is thus, crucially important that all functionality of modules contribute their code to the DNN root bin. I have a post that describes how to set up your modules to do this. This will make sure that at least the current portal you are working in is able to complete references appropriately.

Remote Debugging Team Environment ABSTRACT

Remote Debugging ends up being very useful in the Module Development Process, especially if you are not going to be doing the development against the IIS on your own machine.

In our environment, we have built a 3-tier development lifecycle strategy. Our DNN portal is being used as a strong application platform for a SOA-based integration. We are leveraging the DNN architecture as an application framework against Oracle Applications, in particular PeopleSoft Contributor Relations.

3-Tier Strategy

We develop against multiple instances of DNN, and then move our development projects into a test environment, before finally making the step into production. The test environment is refreshed by production very often, so that the upgrade path to test can very easily be duplicated into production. The sandboxes are refreshed on a as-needed basis.

Remote Debugging

Most, if not all of the debugging occurs in the sandboxed environments. Each developer on our team is assigned a sandbox and a database for that sandbox. All of the sandboxes for development are on the same 2008 server running under a different user for each one.

Microsoft packages a remote debugger with the professional version of Visual Studio 2008. You can copy this installation directory to the server and run it, exposes the processes of the server to the VS client. There are good tutorials on how to do this, and I won't get into details here.

Once the remote debugger is up, one simply opens the Tools > Attach to Process option in Visual Studio, and gives the correct servername. You will see w3wp.exe in the process list (if not, the site has not been used in a while, and your worker process has timed out. Just browse to the portal in your favorite interent browser and refresh the list in Visual Studio.) If you have set your Virtual Directories to run their applications (app pools) as different users, you will notice that the one that correlates to your application pool. Attach to that process and you will be set.

Once you have attached, you are into the debug. You should be able to open up any file location that will allow you to attach a valid breakpoint, and step into the process. You can also access other options such as exceptions, SQL and T-SQL debugging, Silverlight, and more.

Happy debugging..

Oh, and when you are done.. detach from the process.. people get frustrated when their code doesn't run..

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.