The AspMenu class that ships with WSS 3.0 (and by extension MOSS 2007) is nearly identical in behavior to ASP.NET 2.0’s Menu class (as the name implies). AspMenu derives from Menu and adds tweaks to work around a few reasonably well known annoyances and provides improved highlighting support.

 

Unfortunately, this class was marked sealed and is therefore not eligible to be used as the base class for derived types. Effectively, this means that customers cannot inherit the additional functionality of the AspMenu class when trying to provide further customization of the menu.

 

We realized this problem too late in the release process and were unable to remove the sealed marker from the AspMenu class that ships with WSS. However, we are instead providing the source code for that class here (as an attachment to this blog entry) under the name MossMenu.

 

Note: MossMenu is provided as is and will only work on sites built with WSS 3.0 or MOSS 2007. MossMenu relies on some JavaScript which has been included along with the C# source. This is really just for completeness’ sake [aside: some trival about the use of the apostrophe for the possessive forms of nouns] as this script is automatically included on most pages through the core.js script include reference.

 

Issues with the ASP.NET 2.0 menu, which have been worked around:

1)     If the mouse pointer happens to be hovering over a menu item that exposes a fly-out as the page is loading, it is possible that an error dialog will appear stating: "Internet Explorer cannot open the Internet site, Operation aborted" and a blank page will be shown upon clicking OK. It seems that the problem arises from attempting to append to the DOM before it is properly initialized.

2)     If SSL termination is employed on a site with a menu, users will be greeted with “This page contains both secure and nonsecure items. Do you want to display the nonsecure items?” when hovering over a menu item which exposes fly-outs. (http://support.microsoft.com/?id=910444)

3)     In right-to-left locales, the fly-out indicator arrow still points from left-to-right.

 

Improvements to default highlighting behavior of ASP.NET 2.0 menu:

·         When hooking the menu up to a SiteMapProvider through a SiteMapDataSource, the menu automatically highlights the node that matches that returned by the provider’s CurrentNode property. However, if the particular node returned by CurrentNode is not shown by the menu nothing will be highlighted at all. The improved behavior determines if there is an ancestor of the current node which is displayed in the menu and highlights this node instead.

 

Hope this helps.

 

Chris Richard, Software Design Engineer, WCM Features

There are various posts around on setting up MOSS 2007 to use the PDF IFilter, and some stuff on Windows SharePoint Services 3.0 as well.  I’ve found a method which works for me, so I wanted to put this together in one place - not least of all so I can find it when out on site with a client. 

Out of the box neither WSS 3 nor MOSS 2007 will index content located in Acrobat PDF files, so you need to set up the IFilter.  I’ve also found that that PDF files loaded prior to the installation of the filter won’t be re-crawled automatically, so to be on the safe side you might want to kick off a full crawl.

Here is what I’ve found works for WSS 3.0:

Thanks
Waqas Sarwar

Special Thanks to Worker Thread

 

 

 

 

This Include the following Topics:

 

1. Work with document libraries

2. Work with calendars

3. Work with slide libraries

4. Work with workflows

5. Work with Excel Services

 

 

Hey Guys,

 

I come to know lot of people facing problem at morning time when first user access the Sharepoint / PWA / WSS sites, its take a long time to display the page.

Normally IIS discards its cache overnight, which means that each Sharepoint site must be rebuilt the first time it is accessed. This can be very slow. This script will seek out every site and site collection on a sharepoint server, and send them an HTTP request, so that the site remains in cache.

 

 

You must run this application on a machine that has WSS or MOSS installed.
If you want to wake up a single site, you do not need sites.conf and it can be safely deleted.
If you need to wake up mulitple sites, list them in sites.conf, each on their own line.

The app recognizes 3 option switches (the switches can appear in any order):
-verbose --Displays the raw HTML of each site as it is woken.
-site:XXX.XXX -- specifies the starting URL. If you do not set anything, the app looks for sites.conf, and uses the sites listed there. If sites.conf does not exist, the default URL http://localhost is used.
-discover -- Searches the local server for all web applications.
-log:Filename -- specifies a log file to record the results. If a file is not specified, the log will be displayed on the console.

Examples:
spwakeup.exe
If the file sites.conf does not exist, runs against http://localhost. Displays log results on console.

spwakeup.exe -verbose -log:c:\log.txt -site:http://portal.mycompany.com
Runs against http://portal.mycompany.com. Displays verbose results. Stores results in c:\log.txt.

 

 

 

Avoid that COLD, SLOW request that baffles users...

Ever thought things on ASP.NET were a bit slow the first time accessing them?  Many of you are aware that ASP.NET from a web admin perspective know that things have to recompile and things just aren't as fast the first time.  In fact some times things are incredibly slow the first time and are incredibly slow.  Ever had users say, for some odd reason some times when I hit my SharePoint site it takes 30 seconds to load, then after a refresh it goes sub second, even clearing their cache the page is fast.  That's because it's not a user issue, its simply compiling, caching, etc... on the server after an IISReset or app pool reset or worker process cycle.

If you're doing demos of an ASP.NET app such as WSS or SPS or Office SharePoint Server 2007, or you simply want your home page to load faster after an IISReset so it's not your users hitting the page for the first time, you may be *very* interested in this post. 

The scripts attached to this post are warm up scripts.  I did not write them.  I asked the guy (Bryan Hart) who built our awesome VPCs (virtual images) if he wrote them.  He did some work on them, but he doesn't claim to have originally authored them.  They are shared via the SharePoint beta 2 Resource DVD (handed out at TechEd 2006 and the World Wide Partner Conference as part of the SharePoint Server VPC image.  I think they're super cool so I'm attaching them for use on your environments.  None of the scripts are compiled so you can feel free to modify them, make them even greater and share them back out to the world. 

Let's say you know that you cycle your app pools at 1am, what if you executed this script to "warm up" the common pages following the cycle?  I'm sure you'll find other creative uses of this script outside of demos which is our most common usage of this script.  I do recommend you compare an iisreset and hit your home page, then try an iisreset and run this script then hit the page.  HUGE difference.  I personally think the warmupscript is more efficient than a browser request in terms of "warming" things up.

Here's the gist of the attached batch and command line executed vbscript...

In the words of the script itself... "This script will run stsadm to warmup the admin interfaces [and] hit each page in the portal to force their JIT."

warmupserver.zip contains the following 3 files:

Startup.bat - Calls the warmupserver.cmd script and passes in the servername parameter (modify this to fit the hostname of your server)

Warmupserver.cmd - checks for servername parameter then leverages the HttpRequest.vbs script to hit the relevant admin pages (change the pages and ports to the relevant ones)

HTTPRequest.vbs - This script executes an HTTP query using the XMLHTTP object

 

Added 8/21:

I recommend checking out some additional tips on this topic from Andrew Connell

I'd say these tips are beyond just for developers.  It's very efficient to cycle just an app pool, or isolate a worker process and kill the process rather than cycling IIS.

I also recommend having the path to the /bin directory in your path variables. (More insight in andrew's post.

One of the first things I do when installing a sharepoint server is creating a command short cut to the bin directory, even though I like to have it in my path.

1. Right click desktop, choose "shortcut"

2. Put in this path: "c:\winnt\system32\cmd.exe" click next

3. Enter "STSADM" or shortcut to bin or something like that and click "next" (Now you've got a command prompt looking icon on your desktop)

4. Choose the new icon on the desktop.  Right click choose properties, change "start in" path to the path to the bin directory: "c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\bin" (path may be slightly different based for x64)

Double click the shortcut...  You now are at the path where you can run stsadm commands, prescans, etc...

 

Dwonload the Attachement Click here: