Page 1 of 3 in the wss20 category Next Page
Just noticed this item in my collection of RSS feeds that describes a tool included in the SPS 2003 Post-SP2 Hotfix Package:
Description of a new command-line operation that is available for the Spsadm.exe command line tool that you can use to clean up orphaned items in the configuration database in SharePoint Portal Server 2003
Does anyone at MSFT support know how to write better titles? Sheesh!
The article details using the repairorphans command argument for the spsadm.exe tool to remove orphaned items that can result from corruption of the content or config databases in SharePoint. I know of at least two scenarios in the past year that I could have used this tool!
Update: I fired up Fiddler and used its built-in TextWizard to play with the link subject string to see the effects of encoding/decoding on the bytestream -- basically, I confirmed that the mangling of the “è” is due to URL decoding of the un-encoded special character. So, Outlook is definitely doing a URL decode for the subject line.
Update 2: You may notice that my example link above to reproduce the problem I described doesn't mangle the subject line; seems that .Text went and converted the “è” to an HTML escape sequence (& # 232). Trust me, the problem persists!
So, I've been farmed out to one of our satellite teams who are busily working away at knocking off some pre-launch bugs in a SharePoint solution we developed for an enterprise client. The dev lead approached me today with a request to look into a very odd little bug that has had them stumped for a little while.
They have a ASP.NET (1.1) page that contains an anchor tag with a mailto: link that contains a subject heading that is bi-lingual (French and English):
Request Access/Demander d'accès
Problem: When the user clicks said link and triggers Outlook to launch a mail window (using Word as the editor), the “è” becomes mangled:
Request Access/Demander d'accès
Assuming you have Outlook or Outlook Express installed, you can try this out below:
Un-encoded bilingual link.
I spoke with a team member who had tried to tackle this by leveraging HttpUtility.UrlEncode to try and apply a wide assortment of character encodings to the link text (which was being supplied from a resource assembly) without any luck. They were unable to address the issue server-side and so were beginning to look at Outlook and elsewhere for solutions.
On a whim, I tried hand-encoding the “è” with the URL equivalent “%E8“, and 'lo! It worked! It seems that Outlook is mis-coding the character from the web page to the mail window -- my guess is that it's getting lost in translation between UTF-8 and Unicode somehow. Try this link:
Encoded bilingual link.
In the final analysis, this is a cheap-fix and we still need to determine why when UrlEncode is used, that the link doesn't work. Use this knowledge for good and not evil!
When I saw this web part I literally had a “whoa” moment. Graham Tyler has just released a web part into the wild that provides users with a UI to access a shared network NTFS folder to store and retrieve files. From his blog:
| "This means that if your users need to work with file types that do not work well when stored within SharePoint, you can now continue to store them in NTFS, but users can locate them in SharePoint alongside the rest of their files that are stored within SharePoint, via a consistent interface. (Note that NTFS does not natively support all the SharePoint features such as check-in, check-out, version history etc so these options are not available for files accessed via the Windows Folder web part.)" |
Now, this does raise some questions about file security, but it does offer the potential for something that document libraries cannot: Folder-level permissions. Like I said above, “whoa“.
Get it now from GotDotNet.
Just got an email from the folks at Colligo Networks in Vancouver inviting me to participate as a beta-tester for their new .NET client for offline synchronization of SharePoint content, Colligo for SharePoint. This is, from my recent experience, one of the Holy Grails for SharePoint developers and consultants (the others being seamless multilingualism and GUI development of web parts an easy to use recycle bin for document libraries) as it often ranks high in the “need to have” vs. “nice to have” category for clients.
In this regard, I'd be very interested in seeing how Colligo stacks up against similar offerings I've looked at, such as the former Groove Networks solution, Microsoft's SyncToy, Digi-Link's Revelation and others. None have really been satisfactory as they either counter-intuitive for the end-user or have some odd idiosyncracies which are less the fault of the developers and more of the problem domain.
Like other offerings, Colligo is using a local client app to facilitate the synch with the following feature-set:
- A rich offline client that emulates the functions of SharePoint team spaces. The client enables users to download, create, organize, view, edit and save content on their laptop much like they can on a SharePoint server. Colligo for SharePoint 1.0 is tightly coupled with Microsoft Office® 2003
- Enforcement of SharePoint authentication, permissions and security. Users can only access sites and create, view, edit and delete content that the site administrator has authorized.
- Two-way synchronization of SharePoint document libraries and lists, including links, announcements, contacts and tasks. One important note here: Colligo for SharePoint offers robust synchronization conflict resolution that eliminates the need for a user to “check out”, and hence tie up, content in a team space when they go offline. This enables teams to work on the same item offline and then synchronize later.
- Support for custom properties (metadata) and the ability to view, edit and synchronize changes to properties. Properties are used to manage such things as document approval processes.
- Support for custom SharePoint views – Colligo for SharePoint enables users to view list and document library items using custom views downloaded from the SharePoint server. The ability to organize content through custom views is a key feature used extensively by SharePoint site designers to simplify and personalize the presentation of information.
|
I'm particularly interested in the “two-way synch“ for doclibs with “robust synchronization conflict resolution“. This is something that I haven't seen in other products and I'll be keen to review if and when I get a chance. Not sure if I'll have time to do this now, but if the beta is still open in the New Year, I may kick the tires.
While working on a project here at imason, we had a requirement for maintaining localization string resources in the web.config for a WSS site. The first few tries at this had us a little stymied when we realized that we may have to resort to escape-sequencing each and every special character that would end up in the config, or having to write a custom section handler to parse the data. It was not a fun prospect.
Then, I had the notion that maybe, just maybe, the XML encoding type for the web.config could be used to influence the character sets it could contain.
In a word, yes!
So, here's a typical XML declaration for the run-of-the-mill web.config:
<?xml version="1.0" encoding="UTF-8" ?>
This will choke your site's web.config parser as soon as you try to load even a trivial asp.net page containing special characters.
Change it to:
<?xml version="1.0" encoding="ISO-8859-1" ?>
And all will be well! Well, as long as you don't stray from the 8859-1 character specification, that is.
By changing the “UTF-8” to “ISO-8859-1” your web.config can now handle a wide array of characters from accent agues to Icelandic thorns to n-tildes. Note that the 8859-1 character set specification provides character encodings for all so-called “Latin-1” languages: Afrikaans, Basque, Catalan, Danish, Dutch, English, Faroese, Finnish, French, Galician, German, Icelandic, Indonesian, Italian, Malay, Norwegian, Portuguese, Spanish, Swahili, and Swedish.
In addition to these languages, we also need to provide support for Russian, which requires the ISO-8859-5 specification character set. Thankfully, all of our WSS sites are language-specific, so there shouldn't be any complications arising from conflicting character sets.
|