SharePoint Custom Module Development and Deployment

Question

Good Day,

We're working on custom module (Information Management System) for SharePoint. The project file of this module is a Class Library which contains User Controls. The User Controls was based upon SmartPart and AJAX Extension Toolkit. The module has a separate database which has tables/views/stored procedure.

On development environment, we deploy the module in following steps:

• Restore the backup copy of the module database on the pre-production or test environment
• Install AJAX Extension Toolkit

• Modify web.config of web application for connection string, safecontrol entry of AJAX Extension, enablesessionstate set to true of pages, add AJAX Extension tag entry, and uncomment the following line:

  <add name="Session" type="System.Web.SessionState.SessionStateModule"/>

• Create a UserControls folder in web application root and copy all User Controls there. As SmartPart will (can only, I assume) locate User Controls

This is how we do. I sure this is not a good practice and there should be ways to do this in much better way.

One of my question is can we create a separate web.config file which will have all required tags and settings there so we won't need to change web application web.config? Just guessing!

As all WSPBuilder users are aware of this, that you cannot modify the manifest.xml file and no good integration with web application folder. I don't why SmartPart pick the web application root folder to locate User Controls. Is it possible that SmartPart can start picking User Controls from 12-Hive's TEMPLATE\CONTROLTEMPLATES folder?

We are looking for a more appropriate way of doing this. And for me, specific to this case, a good practice would be eliminate all the manual configuration/setup steps. The module user doesn't even need to do a single manual setup to make this thing up and running. I am sure there are many ways of doing this much better than this but what would be the best way to handle it.

Also, I would like to have suggestions on Custom Module development on SharePoint good (or best) practices.

We are using a set of tools like WSPBuilder, Visual Studio Extension for WSS, STSDEV, SPVisualDev, SharePoint Content Deployment Wizard, SharePoint Administration Tools, SharePoint Installer.

Thanks.

Have a Good Day!

Answer 1

There is a way to point SmartPart to point to the ControlTempltes folder but it requires recompilation of the SmartPart solution. To get SmartPart to look inside the 12\CustomTemplates\YourFolder\ you'll need to get the code for SmartPart from codeplex, alter the code inside the point to where you need and recompile it and repackage as a WSP. This is how I got around the issue. If you do that and maintain your own version of it, you'll save development time in the future. We've done this and will reuse our own version with other clients in the future. Hopefully the SmartPart's original code will get updated to accommodate this.

Tip for SmartPart controls: Make sure you turn of any validators in he your controls when you're in edit mode else you'll end up filling out the all the fields in order to publish the page. SharePoint does funny things in edit mode so make sure you test all your usercontrols with the SmartPart in edit mode.

Deploying to resources I think this may be a permissions issues, usually people deploy assemblies to 80\bin and I don't remember doing anything special to make that work. Since wsp's are deployed via SharePoint, if SharePoint doesn't have permissions to the 'resources' folder, then that might fail. Possible issues: a) Resource folder doesn't exist in inetpub or wherever you're root folder is. (Try creating the structure) b) Resource folder doesn't have the same permissions set as the bin folder. (Test to see if you can deploy an assembly to the bin) c) Resource folder is readonly and thats causing the problem. (Take off read only) d) SharePoint never allows for files other than assemblies to be displayed to the root folder via WSP (Unlikely and not sure about this)

My recommendation for troubleshooting such an issue would be to extract the contents of the wsp into a folder (Rename the .wsp extention to .cab and extract the .cab) . Fiddle with the files and structure > create a cab file from it (google this) > Rename extention back to .wsp > Deploy > Test > If it doesn't work, fiddle with the structure again and try again.