Well apparently not everyone needs to be a user with rights to Central Administration... seems obvious, but not always.
A co-worker was trying to get an InfoPath form working, and with the small amount of data she had from an error report she went to the web to try and find an answer. One suggestion she found was to go into central admin and make sure that Anonymous access was turned off. Apparently when you click on "Save" even if you did not make a change, this recycled the web application. Passing out new base web.config and setting host headers on web front ends. We have a redirection site in place that did not allow the normal site to restart after an IIS reset was issued. Meaning that a prod site just stopped working.
This brought myself and a couple of others into the loop of go fix it. Ten minutes later I was able to change the web.config and IIS settings back to what we had set. Now begs the question, well if we have added custom web-parts and configuration file changes to a web.config, how do we persist those in case we want to add another WFE? I knew about Solution Packages for our custom web parts, but what about things like changing the security level, or adding a smart part assembly or Directory Services assembly?
Apparently there is something exposed in the SharePoint object model called SPWebConfigModification. You can set properties of a web.config, like the normal .net object, with a few changes. Essentially, you can write an application to make changes to the default web.config that is stored in the database and handed out to web front end servers when they are added to a farm, or when someone makes changes that recycle settings in IIS etc. I will cover this in the next post.
Going back to my web part projects in VS 2005, I added my Manifest.xml files, and added a cab to drop these into.
MS has some info on adding custom pages into a feature set here, that might be of interest, not specific for a web part though.
I am loading my DLL into the GAC, but you can alternatively add yours to the bin folder using DeploymentTarget of "WebApplication".
<Solution SolutionId="{9A6DA390-1CF3-4140-A600-8F43EFD23507}" xmlns="http://schemas.microsoft.com/sharepoint/">
<CodeAccessSecurity>
<PolicyItem>
<PermissionSet class="NamedPermissionSet" version="1" Description="Generic Permission from System.Security">
<IPermission class="AspNetHostingPermission" version="1" Level="Minimal" />
<IPermission class="SecurityPermission" version="1" Flags="Execution" />
<IPermission class="Microsoft.SharePoint.Security.SharePointPermission, Microsoft.SharePoint.Security, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" version="1" ObjectModel="True" />
</PermissionSet>
<Assemblies>
<Assembly Name="WebPart"/>
</Assemblies>
</PolicyItem>
</CodeAccessSecurity>
<Assemblies>
<Assembly DeploymentTarget="GlobalAssemblyCache" Location="WebPart.dll">
<SafeControls>
<SafeControl Assembly="WebPart, Version=1.0.0.0, Culture=neutral, PublicKeyToken=a48cff86c6243db7" Namespace="Web_Part" TypeName="*" Safe="True"/>
</SafeControls>
</Assembly>
</Assemblies>
</Solution>
Now that is pretty simple. Now just add a project to your solution, a cab project. This allows you to load the cab with STSADM. All you will need is the DLL output and the content output (Manifest.xml), and STSADM will do the rest for you.
Then add the Project output. Build the project and then just copy the cab to the SharePoint server and rename it SolutionPackage.wsp or WebPart.wsp. (For developing you can right click on your package and install it from VS)
Run "stsadm.exe -o addsolution -filename SolutionPackage.wsp" (or WebPart.wsp)
This is fine for most developers, but a system administrator does not want to have to run this for deployment on production machines. Create a batch file or cmd file to let them run to install / remove the solution packages.
Now you have a web part in the GAC (or WebApplication) and a solution in the farm. Now we need to go to Central Admin and turn on the solution for web applications. (Inside operations -> Solution Management) Took me a minute to find it too!
An IIS reset is bound to happen when you do this and you have now been warned.
And we are off, now when one of our Administrators accidentally recycles our web application we do not lose our custom web parts.