There is alway something new to discover. Usually when you want to edit a page in SharePoint you just hit “Website actions” “edit page”. But certain pages don’t offer to edit themself, such as the edit-form for list-items. So what?
Just append “toolpaneview=2” to the address of the currently visible page; and magically you’ll see the WebPart-Editor-Pane, which allows to edit the current page. This way you can literally edit every page in SharePoint.
Dux Raymond Sy performed at the Best Practices Conference 2009 in Washington a cool rap about how nice SharePoint is.
This is the original session:
and these are the slides presented at the session (among others):
When developing web-applications using Visual Studio everything is quite easy. Especially since Microsoft introduced the development-web-server (aka Cassini) web-development is really smooth. Just create a new project and you’re ready to roll.
But there comes the point in time, where you want to deploy your web-app to a real server. So how can you accomplish this the best way? Well, using Visual Studio you can publish a web-application to a web-server using HTTP, FTP or a UNC path. But this is a manual step you would have to trigger.
Of course you could setup a copy-task, by using xcopy or something similar (like NAnt’s copy task). But this would mean, that you would have to specify all files that should be copied. Or you would have to use wildcards, by specifying all extensions which should be copied. But what happens when you add some unusual (or new) file to the project? This will most likely not being copied and you’ll have to remember to modify your copy-task.
For that purpose MSBuild has a special task called _CopyWebApplication, which is part of the Microsoft.WebApplication.targets. This task will copy all items of our web-application project, which are marked as “content”. So if your build-script is based on MSBuild you could leverage this task to copy all files for your web-application to a certain destination.
Since I prefer NAnt over MSBuild I was looking for a solution to accomplish the same with NAnt. So I found a post of Petter Wigle. He has a great approach of creating a NAnt file on the fly by analyzing the web-application’s project-file.
Basically he’s applying a XSLT script to create a fileset-definition of all files that need to be copied. This script can then be called during the build-process.
On January 29th 2010 the December Cumulative-Update for WSS and MOSS has been released.
The Changes for WSS can be found in
and the changes for MOSS
Seems like I need to create a new Slipstream-Setup.
I just stumpled across the offical Microsoft IIS Site, which I didn’t actually knew so far. This is a great resource for IIS, especially if your looking for security or performance related addons for IIS.
Just in case you’re in the need to install SharePoint and you want to incorporate the latest updates into your install – there is a better way than installing SharePoint and then start wssv3sp2-kb953338-x86-fullfile-en-us.exe and officeserver2007sp2-kb953334-x86-fullfile-en-us.exe.
Using a slipstreamed install you can install all updates during the initial installation, thus saving you a lot of time you would have spend to install the updates otherwise.
/extract switch to the Updates folder within the install-folder of the SharePoint CD (wssv3sp2-kb953338-x86-fullfile-en-us.exe /extract:[path to install-folder\Updates]). /extract switch to the Updates folder within the install-folder of the SharePoint CD (officeserver2007sp2-kb953334-x86-fullfile-en-us.exe /extract:[path to install-folder\Updates]). wsssetup.dll from the Updates folder, because this migth cause a conflict with svrsetup.dll. The same way applies to cumulative updates. Important is to keep the chronological order of the updates (oldest first!) as well as to first apply WSS updates before MOSS updates. So you should first integrate the December CU for WSS and then the December CU for MOSS.
This can even be applied to Language-Packs.
/extract switch. /extract switch.