May 2004 - Posts

TechEd Europe 2004 I'll be there
31 May 04 04:04 PM | madsn | 2 comment(s)

Then I finally got to go. And this time I actually have a valid ticket for the sessions! Thanks to Patrice for the logo:-)

I am also attending the BizTalk pre-conference session, which sounds cool.

Also, I have no idea where I am going to book a hotelroom. Any dutch people reading this with recommendations? Heard some talk about scandinavians hooking up in the same place? Anyways, I'm sure it's gonna be a lot of fun.

Update: I've messed up hotelbookings before so I'm taking no risk this time. Mercure aan de Amstel was chosen for it's reasonably priced rooms, gym, WiFi in the lobby and 5 minutes to RAI and the conference.

Teched 2004 Amsterdam

PageViewer WebPart and QueryString parameters
27 May 04 02:04 PM | madsn | 11 comment(s)

There has been dicussion (and people have noticed) about a Connected Page Viewer Webpart. There are several viable approaches to this scenario. One is to use cross-page connected webparts, but those require FrontPage interaction. There has been suggested that inheritance can be used from the PageViewerWebPart. Good luck: It's sealed.

The purpose of a Connected Page Viewer is usually to be able to instruct some page (element) to do something or feed it with params. FrontPage Dynamic Web Templates can be used if you are the developer of the page you want to view within Sharepoint. This gives you the Sharepoint look-and-feel and direct access to Querystrings. However it's less ideal for deployment because it requires FrontPage interaction.

I decided to create my own pageviewer webpart, because the thing is really just an IFrame. I wanted to be able to pass querystring parameters to it, as if it would be a normal page. I also wanted to be able to specify specifically what querystring parameters that should be passed to the QueryStringPageViewer so that sharepoint stuff wouldn't interfere. This actually works great. I can slap the QueryStringPageViewer webpart anywhere in sharepoint. Then I set the ContentLink property (either in ToolPane or dwp file) to http://server/site/page.aspx?param1&param2&param3. In this url pattern the param names are the querystring parameters that the QueryStringPageViewer should pass on to the page viewed in the webpart. Page.aspx is the webpartpage containing the QueryStringPageViewer.

So much for MS sealing their classes. Here's the code and the dwp file (thanks to manoli.net for the code formatter):

Filed under:
Setting WebPart Properties through the WSS Web Services API
26 May 04 03:50 PM | madsn | with no comments

 

UPDATE: This is wrong. Read this.

I think we just found a small void in the Windows Sharepoint Services API. We're creating functionality to generate sites on the fly and we'd like to do this using the WSS Web services to avoid the dependency to Microsoft.Sharepoint.dll. The problem is that the web services API have no way of accessing webparts on the site after creation if you haven't added the wps yourself.

There is a accessor method that takes the webpart GUID as in-param, but no way of getting the collection of all WebParts on the site. There is an Add method that returns the GUID of the webpart, but we don't want to manually construct the site from scratch each time; we're using a pre-defined STP template file.

So the resolution was to go back to coding against the Sharepoint object-model directly. Though break, doing it through web services would have been that much cooler.

Filed under:
Managing Outlook / Exchange content in Sharepoint
24 May 04 11:45 AM | madsn | 3 comment(s)

There are several available options for managing emails in Sharepoint Portal Server or Windows Sharepoint Services. I've researched a couple and found some pro's and con's:

Configuring Email enabled Document Libraries
This is the WSS supported way of doing things. Described by MS here. Basically you create a public folder in Exchange that users can send emails to. Then you enable email for document libraries in Sharepoint Administration. Then you set up a doc lib to poll an exchange folder on a given interval. When a new item is found with an attachment, the attachment is added to the document library along with meta data about sender, recipient, subject and date. The message body remains in exchange and is not available in the document library. This approach allows anyone to send an email with an attachment that will appear in the doc lib. A useful, but risky, approach to for instance allow XML documents to be sent in and start up cool stuff via document library event handlers.

Using third party web parts with exchange
CorasWorks recently acquired BizBox Software and their Outlook web parts. You can use their "My Workplace for Outlook" to get a full Outlook experience on your teamsite. Useful, but in many scenarios you simply want to store a set of emails related to whatever purpose your teamsite has.

Saving emails from outlook to a standard document library
By using the standard File -> Save As option in outlook and saving a message in the outlook *.msg format users save emails as they would with word documents. In order to make the message header and body searchable by sharepoint a third-party IFilter needs to be installed. When users click emails in the document library they open directly in outlook including attachments. There have been some blogging about problems with large attachments (over 3mb) not being stored properly, but I have done no further research at the moment. Setting an outlook template file as the document template for such a library and clicking New Document returns this popup:

'New Document' requires a Windows SharePoint Services-compatible application and Microsoft Internet Explorer 5.0 or greater. To add a document to this document library, click the 'Upload Document' button.

But I would presume that this can be hacked with some effort in Sharepoint to open Outlook. The last thing to note is that the properties of a msg file is not mapped like properties of a Word document. That is, you cannot create columns called "To", "From" and "Subject" and expect the values to be mapped automatically. You can, however, create a document library event handler for this, but that would require either knowledge of the msg format, or using the unmanaged outlook api's (pure guessing actually).

When using this approach we just got confronted with another, yet unresolved problem. The users need to be able to have the email doclibs as favorites in outlook. Sharepoint eventlists (calendars) appear under a mysterious "Sharepoint folders" in Outlook; the quest goes on to see if this is possible.

Also check out Jim's post (and frustration) related to this.

 

Filed under:
Navigating Sharepoint site structure from Office 2003
22 May 04 07:22 PM | madsn | 2 comment(s)

After using Sharepoint for our internal intranet for quite a while, one major problem has become apparent:

How to easily open and save items to the different document libraries located on WSS sites in the portal.

Customers are also pointing this out as a major disadvantage compared to the old-school file server. Users are accustomed to navigating directory structures and we need to find a similar solution when navigating the site structure.

Personally I've used the "My Network Places" pane in the Office save/open dialogs, but now I've got a billion links to "Shared Documents on portalserver" which is useless. Navigating to the portal root gets you no further than to document libraries located in a portal area (although you get a nice browsing experience through the areas). There should be some way of navigating the site tree from the portal root, via top-level websites and through the site directory right down to the document library you want.

If this can't be done users have to memorize and/or maintain an ever growing collection of links.

Filed under:
Sharepoint Configuration Analyzer
22 May 04 05:50 PM | madsn | with no comments

This small handy tool from MS gives you a detailed insight in your SPS server. I found stuff I never knew existed and now I have another source of information when working with sharepoint.

SharePoint Configuration Analyzer is a diagnostic tool that verifies settings on your server that are critical to running Microsoft Windows SharePoint Services or Microsoft Office SharePoint Portal Server 2003 and to hosting Web Parts on your server. SharePoint Configuration Analyzer also reports on Web Part usage on your server and retrieves a set of log files, configuration files, and Web Part packages used by Windows SharePoint Services, SharePoint Portal Server, and Internet Information Services (IIS). In a server farm configuration, running SharePoint Configuration Analyzer on each front-end server is a useful way to find and repair inconsistencies in server configurations and to ensure that all Web Part assemblies are deployed on all front-end servers.

Download here.

Filed under:
Get updated on the MSCMS2002SCSPST!
22 May 04 05:46 PM | madsn | 1 comment(s)

Phui! That's one mean abbreviation:-)

We're currently getting into a couple of projects with MS Content Management Server and Sharepoint Portal server. A couple of months ago Microsoft released the Microsoft Content Management Server 2002 Connector for SharePoint Technologies and I've compiled some links of stuff on how to use it:

Best Practices: Developing Solutions Using the Content Management Server 2002 Connector for SharePoint Technologies
Best Practices: Implementing a Sample Scenario Using the Content Management Server 2002 Connector for SharePoint Technologies
Integrating Microsoft SharePoint Portal Search into Microsoft Content Management Server 2002
MSDN Webcast: Configuring Search with the Microsoft Content Management Server Connector for SharePoint Technologies – Level 200 '
MSDN Webcast: Creating Custom Rendering Templates with the Microsoft Content Management Server Connector for SharePoint Technologies – Level 300
MSDN Webcast: Creating Custom Web Part Views for the Microsoft Content Management Server Connector for SharePoint Technologies – Level 300
MSDN Webcast: Integrating Microsoft SharePoint Products and Technologies with Microsoft Content Management Server 2002
Deployment Guide for Microsoft Content Management Server 2002 Connector for SharePoint Technologies

Filed under:
Creating WebPart distributables with NAnt
22 May 04 04:58 PM | madsn | 1 comment(s)

In my previous posting I described how to use NAnt to auto deploy webparts to Sharepoint. I just ran across the WPPackager tool from Microsoft which enables you to create MSI installers for the WebParts.

What is really cool about this tool is that the MSI sets Code Access Security policies for the webparts automatically. The tool is easily integrated with NAnt by simply using the exec task and supplying a wppackager xml setup file as a parameter:

<exec program="c:\buildserver\etc\tools\WPPackager\wppackager.exe" commandline="MyWebParts.xml" basedir="${dist.dir}" />

Setting custom WebPart Properties in the dwp file
20 May 04 11:38 AM | madsn | 11 comment(s)

I've been developing webparts that use regular ASP.NET Usercontrols as content for a while. Up until now we've simply hardcoded the url to the usercontrol location in the webpart class. Moving towards a more standardized product that must support differentiated deployment envrironments I wanted to place the url to the usercontrol in the webpart dwp file.

The docs availible online describes how to annotate the property to read from the dwp file, much like this:

[Browsable(true)]
[Category("User Control")]
[DefaultValue(_defaultUserControl)]
[WebPartStorage(Storage.Shared)]
[FriendlyName("User Control (.ascx)")]
[Description("Location of the SearchFormControl.ascx file")]
public string
UserControl
{
get{return this
._userControl;}
set{_userControl = value
;}
}

Then you see this in the dwp file template:

< ! - Specify initial values for any additional base class or custom properties here. -->

Well, simply adding an element with the same name as the property simply won't work. Some additional guidance from Redmond Sharepoint team-guy Scott pointed out the missing link:

You've got to annotate the webpartclass with a reasonable namespace like this:

[DefaultProperty("Text"), ToolboxData("<{0}:SearchForm runat=server></{0}:SearchForm>"),
XmlRoot(Namespace="
http://www.objectware.no/Lawyer/Sharepoint/Webparts/SearchForm"
)]
public class SearchForm : Microsoft.SharePoint.WebPartPages.WebPart {}

And then tag your property elements in the dwp file with the same xmlns:

<UserControl xmlns="http://www.objectware.no/Lawyer/Sharepoint/Webparts/SearchForm">URI</UserControl>

And your webpart has an initial propertyvalue after deployment. Thanks Scott!

Filed under:
Building and deploying Sharepoint cab files with NAnt
18 May 04 08:35 PM | madsn | 1 comment(s)

Automatically building and deploying cab files for sharepoint is a great efficiency booster. I have previously blogged about my simple, yet effective, autodeployer for sharepoint cabs. This time around I wanted to automate the construction of the cabfile itself and deploying it to the sharepoint testserver. The pseudo code for the build/deploy steps are something like this:

1. Build your webpart assembly with csc.
2. Create a temp folder and copy the dll, dwp files and manifest exe into it.
3. Create and copy a makecab.exe defs file (.ddf) into the temp directory.
4. Run \windows\system32\makecab.exe /F defs.ddf in the temp directory
5. Run stsadm -o addwppack -filename cabfile.cab -force from the tempdirectory (given that the script is running on the SPS test server)

The clue is to get the defs file right. Check out this article on MSDN (section Using MakeCAB.exe). Set the DiskDirectory1 value to . (period) and make sure to remove the extra line in the sample with the word "directory".

Next off is to use Kris Syverstads Sharepoint tasks to slap your webparts up on a testsite for visual testing.

More Posts Next page »

This Blog

<a name="MyWork">!My work!</a>

Funstuff

Goodies

MSCRM Blogs

Sharepoint

Useful reading

Weblogs

Syndication