In Part 2 of my continuing series on Intranet Journal, I look at the basic installation of a corporate intranet and some basic customization options.

Thanks to Bob Mixon for his technical review.

I had an interesting email conversation today discussing SharePoint and it occurred to me that it is possible to try it out free of charge.

• Get the trial version of Virtual PC.
• Get the Windows 2003 Evaluation Kit.
• Add Windows SharePoint Services.

Jan. 12, 2006: Updated the links to point to the most recent versions.

The first article in my new series at IntranetJournal.com is now posted.

You can post feedback on IntranetJournal's Discussion Forum or post comments on my blog site.

I don't know who "James" is , but he has some great posts about the Microsoft Office System Developer Conference.

http://jamesasher.blogspot.com

I found a post of mine on a different website. They obviously are reading my RSS feed, but it doesn't look like it:

I DID NOT SUBMIT THIS!!!! And what pisses me off is that they have Google Ads on that page. 

If you know who runs this site -- have them stop. (Or they can pay me.)

I wrote in my previous post that you should use http to access web part resources. Well guess what -- there is more to it.

If your WSS site is running with anonymous access off, then the attempt to get the resource will fail with a 401 Unauthorized error. This happens because web requests made in code will perform an anonymous GET.

In my specific case, I was attempting to read an XSLT file from the resource directory by passing the URL to the file. To solve the security issue, the Load() method on the XslTransform object needs a security resolver. The code necessary for this (which I copied from the .Net SDK):

' Build the URI to the resource
Dim resourceURI As Uri = New Uri(ClassResourcePath)
Dim xslPath As String = Path.Combine(resourceURI.ToString(), "filename.xsl")

' Create a secure resolver with default credentials.
Dim resolver as XmlUrlResolver = new XmlUrlResolver()
Dim sResolver as XmlSecureResolver = new XmlSecureResolver(resolver, xslPath)
sResolver.Credentials = CredentialCache.DefaultCredentials

' Get the xsl file
Dim trn As XslTransform = New XslTransform
trn.Load(xslPath, sResolver)

If you have a resource required by a web part, WSS has a defined way to store and access this resource. Custom web parts can be deployed to the wwwroot/bin directory or to the global assembly cache (GAC). The deployment location also affects the location of the resources directory. For GAC deployments, the directory is mapped to /_wpresources/[assembly_name]. For bin directory deployments, the directory is mapped to /wpresources/[assembly_name].

The workaround to this is to use the ClassResourcePath property. The SDK advises use to "Use the path returned by the ClassResourcePath property to prefix resource URLs for the browser to fetch."

The gotcha comes in when you try to access this external resource directly from disk when the context is a sub-site. Since the file is in a directory, I have always grabbed the file like this:

Dim resourceURI As URI = New Uri(ClassResourcePath)
Dim partResourcePath as String = Context.Server.MapPath(resourceURI.AbsolutePath)
.
.
.
Dim resourcePath as string = Path.Combine(partResourcePath, "somefile.xsl")
Dim trn As XslTransform = New XslTransform
trn.Load(resourcePath)

What is happening, however, is that the sub-site address is included in the ClassResourcePath. This is mapped correctly when requesting the file via the URL, but not whem mapping the path to a physical directory.

When using ClassResourcePath, be sure to use http to access the resource.