When we need to add custom settings or sections to the web.config file of a web application in WSS3 and MOSS, there is a way to do this quite automatically.

If you need several settings that you would like to have added to the web application's web.config when creating/extending the web application, custom xml config files can be used for this.

You can create a file in the format webconfig.[name].xml, put it in the \\Program Files\Common Files\Microsoft Shared\web server extensions\12\CONFIG folder and the settings in the file will be merged with the web.config file on any new web application.
Of course if your web application is already created and you put the file in the \config folder no changes are applied. This is really only when creating/extending new web applications.

Even so, this is a very interesting feature as you can automate any custom settings you would like on all your web applications in WSS3.

In my case I needed a custom appSettings element and a new custom connection string. The XML to be used consists of elements placed into the <actions> elements. The syntax is straightforward:

webconfig.myname.xml contents:

<?xml version="1.0" encoding="utf-8" ?>

<actions>

<add path="configuration/appSettings">

<add key="MyFilePath" value="C:\temp\path\" />

</add>

<add path="configuration">

<connectionStrings />

</add>

<add path="configuration/connectionStrings">

<remove name="MySqlServerConnection" />

<add name="MySqlServerConnection" connectionString="server=[server];database=[db];Integrated Security=SSIP;" providerName="System.Data.SqlClient" />

</add>

</actions>

To deploy this file to the CONFIG you can manually copy the file.

Another approach is adding the file to a solution. A file to be deployed to the CONFIG folder can be inserted by using the <RootFile> element:

manifest.xml example:

<Solution xmlns="http://schemas.microsoft.com/sharepoint/" SolutionId="GUIDHERE">

<RootFiles>

   <RootFile Location="CONFIG\webconfig.myname.xml"/>

</RootFiles>

<!-- rest of solution manifest here
<FeatureManifests>... and other elements
-->

</Solution>

This is my approach to automating web.config settings. Just remember the config settings are only merged with the web.config file when you create a new web application, nothing is changed on existing web applications.
Contrary to the <SafeControls> elements you can use in a solution manifest, these are always merged to the web.config file when you deploy the solution.

MSDN reference for custom configuration settings: http://msdn2.microsoft.com/en-gb/library/ms439965.aspx

I have been having a strange error with the deployment of a solution to MOSS 2007. On my local machine the solution gets installed and deployed nicely however when I move it to staging server it returns an error:

Error: Cannot add the specified assembly to the global assembly cache: [myassemblyname.dll].   at Microsoft.SharePoint.Administration.SPSolutionPackage.UpdateGacFile(SolutionFile file, String sourcePath, Boolean install)
   at Microsoft.SharePoint.Administration.SPSolutionPackage.UpdateFiles(String vrPath, Boolean install)
   at Microsoft.SharePoint.Administration.SPSolutionPackage.EnableWebApplication(String vrPath, Boolean globalInstall, TextWriter logWriter, Boolean force)
   at Microsoft.SharePoint.Administration.SPSolutionLanguagePack.DeploySolutionPackage(SPWebApplication webApp, Boolean globalInstall, Boolean force, String& errMsg)
   at Microsoft.SharePoint.Administration.SPSolutionLanguagePack.DeployFilesInstallFeatures(SPWebApplication webApp, Boolean globalInstallWPPackDlls, Boolean installFeatures, Boolean force, Int32 tries)
   at Microsoft.SharePoint.Administration.SPSolutionLanguagePack.DeployLocalCore(Boolean globalInstallWPPackDlls, Collection`1 webApplications, Boolean useAdminService, Boolean force)
   at Microsoft.SharePoint.Administration.SPSolutionLanguagePack.DeployLocal(Boolean globalInstallWPPackDlls, Collection`1 webApplications, Boolean force)
   at Microsoft.SharePoint.ApplicationPages.SolutionPageBase.CreateDeploymentJob(Boolean deploy, String strSelectedWeb, Boolean globalInstall, DateTime dt, Boolean localDeployment)
   at Microsoft.SharePoint.ApplicationPages.DeploySolutionPage.BtnSubmit_Click(Object sender, EventArgs e)
   at System.Web.UI.WebControls.Button.OnClick(EventArgs e)
   at System.Web.UI.WebControls.Button.RaisePostBackEvent(String eventArgument)
   at System.Web.UI.WebControls.Button.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String eventArgument)
   at System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String eventArgument)
   at System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postData)
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

After having searched for answers and posted a question on the MSDN forum: still nothing. Seems I’m the only one having this error, at least for the time being :-(

My solution to this problem is adding the assemblies to the local bin of the application. I have read that this is the recommended approach.
However using this approach there is an important aspect to take into account: the CAS (code access security) permission set. When an assembly is deployed to the GAC it runs with Full trust. When deploying to the web application's bin directory the assembly runs with minimal trust. It is necessary to add CAS (Code Access Security) elements to the <solution> schema in order to set the right permissions.

My solutions are being deployed nicely now, it was a small challenge to find the correct security settings to implement however. I finally found some nice blog posts with a few samples and found the correct settings.

CAS itself is actually something in ASP.NET, not just SharePoint.

Some of my resources for CAS:

• Mikhail Dikov - Configuring Code Access Security in SharePoint Solutions
• Code Access Security policies within SharePoint v3
• CodeAccessSecurity Element (Solution) – MSDN

[Update 26-Aug-2007] While installing solutions with DLLs to the GAC I'm still having this problem from time to time on one single machine. My solution for the moment is rebooting the server and running the install solution script again. Luckily it's only the staging server presenting this issue so a reboot is not so much an issue.

[via Michael Dukov]

If you implement multilingual or localized customizations of WSS and MOSS this post is for you: Michael Dukov wrote a nice overview of how you can use resource files (resx), how to implement them in features, in ASPX pages and even supplies some source code to deploy global resources using a feature.

Link to the article: http://dikov.blogspot.com/2007/03/sharepoint-resources-types-use-and_2163.html

Part I: Creating site columns, publishing content types and page layout using a feature

Before going into detail on the creation of content types via features it is important to understand how Content type IDs work.
You should read the following MSDN page that explains about ContenTypes IDs and their inheritance based model: http://msdn2.microsoft.com/en-us/library/aa543822.aspx

Since this post shows how to create Publishing Content Types we need to find from which existing content type we want to base our own. I did some research on the features that are installed and activated when you use the Publishing site. In there we can see that the base content type from which we want to inherit is the “Page”. This Content Type has an ID of:

0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB0
64584E219954237AF39

So in order to create our own ID we can add two hexadecimal values, or, we can add “00” followed by a GUID. I prefer this approach as it is unique and identifies custom content types more easily.

So my content type ID can be:

0x010100C568DB52D9D0A14D9B2FDCC96666E9F20079481
30EC3DB064584E219954237AF3900ADB88465BE2C439798977662094183BC

The bold text is the Page content type ID to which I append “00” and a new GUID.

Content Type Schema

Second important piece of information is the Content Type schema. I could not find any information specific to publishing content types on MSDN or the MOSS SDK. So again the solution is to use the available information together with some nosing in the publishing features installed by MOSS in the 12 hive. ContentType schema on MSDN: http://msdn2.microsoft.com/en-us/library/aa544268.aspx

In the following sample I’m creating two content types: a product content type and a hardware product content type. You will see that the hardware product content type inherits from the product content type by appending 00 + a new GUID to the ID.

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">

      <!-- Product base content type -->

      <ContentType ID="0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007
948130EC3DB064584E219954237AF3900ADB88465BE2C43979
8977662094183BC" Name="$Resources:contenttype_productbase_name;" Description="$Resources:contenttype_productbase_description;" Group="$Resources:group_productcontenttypes;" Sealed="FALSE" Version="0">

            <FieldRefs>

                  <FieldRef ID="{F44BFBB0-4725-4167-B976-F85F84131AA3}" Name="ProductCategory" Required="FALSE" />

                  <FieldRef ID="{EB19D87C-5DEE-4a73-85E0-506293D422D9}" Name="ProductName" Required="TRUE" />

                  <FieldRef ID="{D73843E5-0D9F-4400-BC75-1A4C2BD27900}" Name="ProductIntro" Required="TRUE" />

                  <FieldRef ID="{894635F9-1DF8-46f1-BC47-46EFF09FEF3D}" Name="ProductDescription" Required="FALSE" />

                  <FieldRef ID="{D89C9409-2A97-4a7a-81F5-7D45E7CD8D6B}" Name="LaunchDate" Required="TRUE" />

                  <FieldRef ID="{6036ECDE-521A-4dbe-94B4-40E0E4EF7029}" Name="ProductImage" Required="FALSE" />

                  <FieldRef ID="{F31DF817-D220-4449-BD6F-2F1B7C0823ED}" Name="ProductPrice" Required="TRUE" />

            </FieldRefs>

            <DocumentTemplate TargetName="/_layouts/CreatePage.aspx" />

      </ContentType>

      <ContentType ID="0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3D
B064584E219954237AF3900ADB88465BE2C439798977662094183BC00B2DE
F3B02D274199BFF43C6D2F129D99" Name="$Resources:contenttype_hardwareproduct_name;" Group="$Resources:group_productcontenttypes;" Sealed="FALSE" Version="0">

            <FieldRefs>

                  <FieldRef ID="{6A08E31A-0620-45df-BAC1-54A4D0FBFDCE}" Name="ProductManual" />

            </FieldRefs>

            <DocumentTemplate TargetName="/_layouts/CreatePage.aspx" />

      </ContentType>

</Elements>

Now we need to add this to the feature and install it together with what was done in part I of this series.

The complete feature can be downloaded here.