Ponderances, Inanities, and other Nonsense
SharePoint 2007
ForceDeleteList (stsadmin)
Mar 10th
On this edition of “SharePoint 2007 The Hard Way…”
I had a custom action that I created in the Edit Control Block set up to add a list to a list. Well, we couldn’t leave well enough alone and all of our WSP files are being combined into one big WSP. It is a long story as to why that is, but suffice it to say it has to do with interdependencies of WSPs that becomes a problem. You can set dependencies in the feature file by adding an “ActivationDepency” to your feature.xml file to force the admin to install features in a certain order, but there isn’t something to enforce the order of removal: stuff just fails. Well, when you start having 20+ *.wsp files flying around, it gets kind of sketchy.
Anyway, long story short, I goofed and forgot to delete a list instance before I deactivated the site and site collection features and retracted/removed the solution from Central Admin. So, I tried SWAT but it didn’t have rights, so I decided to try and remove the list using my old “go-to,” STSAdmin. Now, I love STSAdmin, but I don’t like doing stuff from the command line (if that makes any sense.) And I have a print-out that I keep beside me that is basically a pipe to a text file of the screen dump you get from typing “stsadm /?”. On that list is “forcedeletelist.” But, if you type in “stsadm -help forcedeletelist,” it gives you “stsadm -o forcedeleteweb -url http://web.” Now in the original printout, I didn’t even see that was an option: forcedeleteweb.
Just so you know, if you type in “stsadm -o forcedeletelist -url http://web” it works fine, and doesn’t delete your web. That is, I haven’t tried it on the root of the site, but on “http://mysite/Lists/MyListName.” It did not delete the folder in the 12 hive or any of the sites within, but it deleted that pesky list from my site.
SharePoint without Designer
Feb 1st
This past week I just finished a class on MOSS 2007 development, and I don’t know if I am any closer to understanding it.
The reason is not that I am that obtuse, but that by design, SharePoint development is generally performed sitting on a server with SharePoint Designer. However, we can’t do that…all of our functionality has to be deployable in *.wsp files. There are many challenges to this limitation, most especially sequencing installation and configuration conflicts (interdependencies, etc.)
There doesn’t seem to be much out there about having to package it up yourself and developing in VS.NET, though this limitation has to be fairly common among DoD contractors.
All in all, it gets very frustrating.