August 2004 - Posts
A followup to this post:
The PortalRight enumeration defined in Microsoft.Sharepoint.Portal.Security is, for some reason, derived from UInt32 rather than Int32. You can see this in the Object Browser when in a VB.NET project.
This anomaly - nothing more than a raised eyebrow in a C# project - seems to be crippling in a VB.NET project.
Whenever I try to use this enum in code, the compiler claims that it can't cast from Integer to PortalRight - even I always use the enum:
Dim acc as AreaAccessControl = new AreaAccessControl(ctx, PortalRight.ViewArea, myArea.ID)
Gives a compiler error in VB.NET, but works fine in C# - even though the second parameter is defined as PortalRight.
Casting it to UInt32 simply gives a "Can't convert UInt32 to PortalRight".
The only way I could get it to compile (didn't check if it worked) is by doing Enum.Parse on PortalRight.ViewArea.ToString(), which is just SO wrong.
Anyone know why this is so?
And, to close of the day's rants - an instructive post.
Today: How to create a template of a Sharepoint Area that can be moved or taken to different servers.
Unfortunately, SPS Areas can't be bundled into STP templates like WSS sites or lists, and there's no built-in method of exporting an area into a convenient format so out Frontpage customizations and painstakingly defined layout can be copied to a different site.
What we CAN do, though, is simply edit the area in question using FrontPage 2003 and File->Save As to save the ASPX to our local drive. Any locally-referenced images will also be downloaded. This ASPX can now be copied to a different server and serve as a template, using these steps: (Warning: My Sharepoint installation is in Hebrew, so some of my translated links and steps might be a bit off).
1) Copy the ASPX and any dependent files into a Document Library on the new SPS server. The ASPX must reside inside Sharepoint, probably for security reasons. I got strange errors when trying to put the file in the /_layouts directory, so I'll stick to this method until proven wrong.
2) Create an area that will use our template, or modify an existing one (warning: The current content of the area will be unavailable once we attach the template).
3) Go to Change Settings (on the left) -> choose the Page tab -> Area Templates -> This area uses the following page as a template.
4) Specify the virtual path to our ASPX template - I put it in the main portal's Document Library, so the path was:
/Document%20Library/template.aspx
5) Press OK, and your area is now based off of that page. The original content is unavailable but not erased - if you change the Area Templates radio-button back to what it was, you'll get the old page back.
There. Enjoy.
Developin webparts with many UI elements can be a hassle - which is why I'm fond of the UserControl shortcut - I build my web UI as a WebUserControl, then simply have my webpart call Page.LoadControl to dynamically load that usercontrol.
A problem I've encountered with it today is that LoadControl, strangly enough, ignores HTML comment in the ASCX file.
Let's say I have the following code in the ASCX:
<!-- <asp:Repeater runat="server" id="Repeater1" /> -->
<asp:Repeater runat="server" id="Repeater1" />
This should instantiate only one Repeater object - and does, when the ASCX is hosted normally inside an ASPX page.
When I load it dynamically, though, I get an exception in LoadControl stating that "Parse Error: A control named Repeater1 is already defined" - meaning that for some reason it parses the first control too, even though it's commented out.
If I erase the commented section, it runs as planned.
Anyone know why it ignores my markup?
For some reason, Sharepoint's object model doesnt adher to Microsoft's recommended practices - namely, trying to keep your external interfaces CLS-compliant.
It seems the object model itself exposes several methods and properties that use the UInt32 data-type, even if the SDK claims otherwise.
Sharepoint 2003's installation process is one of the most delicate and uncooperative I've seen in while. Quite a surprise in this day and age - responsive, coherent installations is something we've grown to expect from Microsoft's server systems in recent versions - or maybe it's just me. :)
Sharepoint's installation can be baffled by any number of reasons - lack of harddisk space on drive C:, remains of previous installations, even something as simple as a wrong password entered for the applicative user to run the services. All of these errors share one thing between them - the installer won't pop up a messagebox to let you know what happened. It won't even give you an error warning and let you try again (to a different path perhaps, or to retype the username). It will simply continue on UNINSTALLING SPS (and WSS, if it was part of the process) and direct you to a folder full of log files out of which you're suppose to dig the actual reason for the failure and presumably try again - yes, a 10-minute process just to find out I forgot to put the domain name before the username for the service account.
Extremely annoying behavior, especially when this unexpected uninstallation doesn't always do a perfect job of removing all traces of what just happened from the registry.
So remember, boys and girls. When installing Sharepoint, be extra-careful to cross your T's and dot your I's and make sure to read every screen for potential pitfalls, because wizard or not, you won't always have a Back button to fix your mistakes. Tread carefully...
More Posts