So you want to build your own web part eh?

 

Your solution explorer should now be populated with a bunch of files and references like this:

Now really there are only a few files you need to concern yourself with.  The most important one being the <WebPartName>/<WebPartName>.cs file, in my case it is Test/Test.cs; I will refer to this file as the main file from now on.  I say it is the most important as that is the one that does everything from presentation to code-behind.  The others are the <WebPartName>.webpart file and possibly the AssemblyInfo.cs file, but we will focus on the first right now.

Open up the main file and you will see something like this:

Where you see “TODO: …” is where you are going to put your rendering code.  They even provide you with the always-friendly “Hello World” program if you just un-comment it.  The Guid is automatically populated when you make your project, so don’t mess with it.  The big thing here is that 100% of your styling and layout has to be taken care of back here.  There is no aspx page to your aspx.cs like a normal .net web page.  Once you have a handle on that, it can be treated just like any other asp.net website you have ever made.  There are some other great interactive tools and features you can include, but that is for another day.  Right now, just use the “Hello World” code, use my supplied code or fill it up with your own.

 

NOTE: Often times it is easier to get your programming logic done in a regular Visual Studio Project as there is no way to easily test in a SharePoint Web Part Project.

 

Now that you have your code finished, we can change a few other things.  Open the <WebPartName>.webpart file and you can see some properties you can change.  Customize the Title and Description if you like.

That will change the default settings for this web part.  That is all I would mess with for right now.  So in theory, you now have a 100% working web part.  Now is the easy part.  Just right click on your project and click ‘Deploy’.

 

Assuming everything worked, you know have published your web part to your portal.  If it didn’t work, go fix your bugs and come back :PGo to your Portal->Site Actions->Site Settings->Modify All Site Settings and click on Web Parts under Galleries and you should see your Web Part with a happy little ‘!NEW’ by it.

Now just go to a Web Part Page and put it in there somewhere then exit edit mode.  You should now see your web part in action:

 

Here is my example web part you can take a look at.  It shows a couple different methods of how you can make a web part interact with itself.  As I mentioned above, there is a lot you can do with web parts beyond this, and I will hopefully be able to post some more in the near future.

Source Code:

Making web parts for WSS 3.0 and MOSS 2007 just got a lot easier... that is, once you figure out how to install it

Long ago (in computer time) Microsoft offered Visual Studio Extensions for WSS 3.0 web parts and they were wonderful. Problem was for us fools who upgraded to the latest and greatest (Visual Studio 2008) were stuck with a new fancy IDE that did not support this tool that is oh-so-handy. So, in my stubbornness/laziness, I just decided to study up on web parts themselves and hold off on the SharePoint implementation of them until it became compatible, instead relying on the lazy mans way of Jan Tielens' ReturnOfSmartPart (great tool).

But now (actually 8 days ago... we had a big project ok?!) MS has released the new VS 2008 Compatible Extensions and SharePoint devs all over the world rejoice!

But wait!? It won't install on my Windows XP?

It says compatible with Windows XP? But what is this? It also says that a requirement is to have WSS 3.0 installed. Ok, I'll install WSS 3.0, but...

WSS 3.0 will not install on Windows XP. I am no genius here, but let's think about this. If I need WSS 3.0 to be installed in order to install the extensions and WSS 3.0 is not compatible with Windows XP, then by some mathematical property wouldn't it be safe to say that the extensions are not compatible with Windows XP?

Luckily some google searching brought me to Janne Mattila's blog and a way to trick my OS into thinking that WSS is installed. You just need to add/change a registry key:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0] "Sharepoint"="Installed"

Now everything should work fine.

A detailed tutorial on how to use some borrowed/modified scripts for making this task very simple

These scripts were stolen from SharepointBlogs.com and have been modified just a little to get some different functionality, I want them to take 95% of the credit... the rest is MINE!  (Thanks guys!)

 

These scripts were almost exactly what we needed, but we needed each content database to have custom names.  So I twisted the code around a bit and here is a detailed tutorial of what we did. 

**IMPORTANT - do this ONLY after you have made your initial web application.

 

Make the Databases

1. Make a new database named temp_db_builder
2. Make a table in temp_db_builder with this:

   CREATE TABLE create_dbs(
   id INT NOT NULL PRIMARY KEY IDENTITY, 
   db_name VARCHAR(MAX)
   );

3. Fill that table with the trailing end of your content db names- EX: WSS_Content_SomeSite : 'SomeSite' = trailing end
4. Edit make_dbs.sql (from the zip below):
   1. Change @ServiceIdentity and @AppPoolIdentity to the proper accounts
   2. Change the X in WHILE @Number <= X to the number of entries you added in the create_dbs table
   3. Change @DataFile and @LogFile to the proper destinations
   4. That is all that is needed, change the other properties if your situation requires
5. Run that file, or run the query text in SQL Server Management Studio
6. Databases are made

 

Produce the Batch file:

1. Edit the file make_db_batch_file.vbs (from the zip below):
   1. edit NUMBER_OF_DATABASES to the number of names you added in the create_dbs table above
   2. edit SQL_SERVER_NAME to your SQL Server
   3. for however many databases you specified in #1, add the names to dbArray(x) from 0 to NUMBER_OF_DATABASES - these HAVE TO match the names in the table create_dbs
   4. edit DBnameconv to what the prefix of the databases is
   5. edit SiteURL to your site url
2. Copy that file to your Sharepoint Admin Server to C:\Add_ContentDB_Script\
3. Go in to your command prompt and run cscript make_db_batch_file.vbs from the C:\Add_ContentDB_Script\
4. Batch File is made

 

Attach Content Databases to Sharepoint

1. On your Sharepoint admin server, run a command prompt as the Sharepoint admin account (runas /user:domain\username cmd)
2. Navigate to C:\Add_ContentDB_Script\ and run AddDBAContentDB.bat

 

And you should be all done.

This was the error I was receiving after a restore from MOSS 2007 Standard to MOSS 2007 Enterprise

It seems that MOSS is still a bit buggy as I often run across random errors that have no place happening.  I ran into this error when I was migrating a Site Collection from Standard to Enterprise.  All of the other collections went off without a hitch, but this one was giving me problems from the start.  First I want to explain what I think was causing this.  Site Collection B (SCB from here on out) was at a root level on the old farm; it had it's own url and was it's own stand-alone 'portal'.  Now when I migrated, I needed to move SCB under a root collection SCA.  I have done this before, but never run in to any problems, but this was different for some reason?

 

I did my restore with the stsadm command line tool and it cheerfully told me that the 'Operation completed successfully', so I tried to go to the site, but what do I see:

Error

File Not Found.

Damnit... but the site rendered, so I did some checking around.  Everything else on the site seemed to work, if I typed in any other url under that site root, I could get there.  I could get to site settings, to create site, anything, but the main page was bunked out.  I went back to the old version and saw that that page was pretty customized, not to mention not being default.aspx but some odd name that the admins came up with.  So, on a whim, i made a totally blank welcome page (default.aspx) and backed it up, restored, and boom... everything worked.  Not exactly sure why the other page wasn't working, but that is water under the bridge as far as I am concerned, re-making a single page isn't all that tough... sorry users!

 

Now I figure, as long as they can re-make a page, no big deal right?  So I click on Site Actions -> New Page and I get this beauty:

Error

Content type '0x01010007FF3E057FA8AB4AA42FCB67B453FFC100E214EEE741181F4E9F7ACC43278EE811' not found in web

Now after countless searched on the internet I turn up basically nothing, TechNet is dry, and no one seems to have had this error (not a first for me sadly).  I ask a desperation post on Experts-Exchange and run through the drills.  Checking my xml config files, looking at error logs, etc.  Then the guy helping me suggests I try something simple... run the SharePoint Products and Technologies Configuration Wizard on all the machines.  Surely it can't be that simple after I bashed my head into the wall for over 24 hours?!

 

It was; just run SharePoint Products and Technologies Configuration Wizard on all your machines and this will go away.  Would that have been so hard to include in the Error message?  Would it?

This 'production' service pack that microsoft released is harder to install than my linux wireless NIC

NOTE

This seems to only be a problem if you are already joined to a server farm, not if it is a fresh install

Ok, I love Microsoft, I might even call myself a fanboy, but this Service Pack 1 is a disaster if you are not working with fresh install.  This is the third time I have had to install it and each time it was a mess, so I am writing it down, step-by-step for anyone who has to go through this.  Keep in mind that this particular install was done on a completely naked 6 server farm with no data on it.  Here is the guide:

 

The first service pack must be the WSS 3.0 Service Pack and must be installed on each machine one-by-one, starting with the Central admin machines. 

 

First trying installing it normally (double clicking on it), THIS STEP IS NECESSARY to continue to the other methods. 

 

If that errors out, try this:

 

If that errors, try this from the same command prompt:

 

If that errors 

1. Check the Log file produced - if it complains about not having a web.config file:
2. Copy the web.config file from the server that hosts the Central admin in the directory: C:\program files\common files\microsoft shared\web server extensions\12\TEMPLATE\LAYOUTS
3. Paste that to identical directory on the error machine
4. Run stsadm -o upgrade -inplace -forceupgrade again

 

Once that is installed, install the MOSS 2007 SP1 by double clicking on it, that can be done all machines in the farm at the same time.

 

If that fails: 

1. Open a command prompt
2. Navigate to C:\program files\common files\microsoft shared\web server extensions\12\bin
3. Type psconfig -cmd upgrade -force
   • This will look now for the new failed update, even though the process is the same.
   • You HAVE to try to run it normally for this to work

 

Now you are ready to run the hotfix (wss-kb941422-fullfile-x86-glb.exe)

 

This will install by double-clicking the exe, and should not error out.

 

Now you need to run the Configuration Manager on each machine one-by-one.  And you should be done with the upgrade...

 

LINKS: 

SAMS came up with a great SharePoint backup automation tool with their SPSiteBackup.wsf windows script file - it is good, but needed a couple things... so I added them...

The SAMS backup utility is really pretty great.  It runs backups on all of your site collections on a given site as well as as logging the results and emailing the logs to users.  This is very useful, but it is lacking a few features that I felt it needed.

 

First of all, the backup utility put all of the backup files into one directory.  When you have a lot of sites, not to mention if you are backing up MySites, this can become a massive chunk of data.  If you are running this script on any recurring basis, it just turns into a non-decipherable mess of hundreds and hundreds of files, no organization whatosever.  I made a change here that will automatically make folders (named by date) and place the backups in the properly dated folder.

 

Second, there is no garbage collection.  If I ran the script every day, I would eventually choke out all of my storage and be stuck with 100s of GBs of backups.  I could just go in and delete them manually, but no one wants to do that (so 90s).  What if I forget, or go on vacation, or leave  - so, I made a garbage collection method run within the script as well.

 

All you need to do is place the script file directly on your C: drive, customize the batch file (explanation provided within the .bat file) and schedule it to run (or run it manually) and you are running maintenance-free automatic backups on your SharePoint server/farm.

 

 

 

 

Ok, if you feel ok on your own now, stop reading - if not, read on for a step-by-step tutorial on how to schedule the automated backups on your server...

 

Get the backup script files ready  

1. Copy the 2 files from the .zip file to the machine you want to run backups on directly to the C: drive
2. Open spBackup.bat in a text editor, you will see the following:

   cscript c:\spBackupScript.wsf
   /virt:"http://your_sp_site"
   /path:"path_for_backups"
   /smtpserver:"YOUR_SMTP_SERVER"
   /reportto:"send_reports_to@this_email.address"
   /holdfor:"number_of_days_before_backups_are_deleted(integer)"

3. Change the input variables to what you need them to be (self-explanatory) for that server instance.

 

Now that is set up, you need to schedule the job.

1. Click Start->Programs->Accessories->System Tools->Scheduled Tasks
2. Double-click Add Scheduled Task, choose Next
3. Click Browse... and browse to the .bat file you just edited (C:/spBackup.bat)
4. Name the task and choose how often to perform the task click Next
5. Choose the start time click Next
6. Enter your password click Next
7. Click Finish

 

It's just that easy, you are now making and cleaning up backups automatically.  Here it is one more time:

 

 

Automated_SP_Backup.zip (3.60 kb)

"Your backup is from a different version of Windows Sharepoint Services and cannot be restored to a server running the current version."

DAMN YOU SHAREPOINT! NO IT ISN'T!!!

That was the error I have been facing for a couple of days and it was driving me utterly crazy.

This was my situation: I was tasked with migrating the sharepoint data on an ancient server (PIII 512 RAM) running WSS 2.0 and SQL 2000 to a new server running MOSS 2007 and SQL 2005 - I have done plenty of backups and restores on SharePoint, and they are suprisingly easy.  This should be no problem...

Wrong. This turned into a classic battle of me vs. some software, and I refused to let it win! (plus, my boss would be pissed).

You can read the [Details of the battle] or just read on for the solution.

 

Turns out that even though WSS Backup/Restore was supposed to be compatible with SQL 2005, they didn't actually make it compatible until SP3.  So, despite not even being the same version anymore, it seemed to work just fine EVEN THOUGH THE ERROR CLEARLY STATED THAT MY VERSIONS WERE DIFFERENT!  I think they need to revise that error message before someone stabs their eyes out!

So it turns out that all you have to do is this:

 

1. Update both servers to WSS 2.0 SP3
2. Backup your initial server using stsadm
3. Restore to your new machine using stsadm
4. Upgrade your new system to MOSS 2007 

 

That's it... thats the whole answer to my week long battle with WSS.  Now I just have to upgrade to MOSS 2007.  You can get SP3 here: WSSSP3-KB923643-FullFile-ENU.zip (6.19 mb) - hopefully this saves someone a whole bunch of hours on a ridiculous problem, though no one even uses WSS 2.0 anymore...