I recently had to build a MOSS solution that included two features - one feature created custom permission sets when activated, and the second feature created custom groups and bound the custom permission sets (created by the first feature) to the custom groups in the second feature.
I wanted to expose the features to the Site Features console so that they could be easily activated/deactivated by the Site Administrator, but I didn't want them activated out of order.
One approach to this problem is using a feature dependency. By specifying the GUID of a dependent feature in a feature.xml file, you can prevent the feature from being activated if the dependent feature has not already been activated.
Additionally, a user-friendly message is displayed to the site administrator specifying the dependent feature that must be activated before MOSS will allow the current feature to be activated.
All in all, feature dependencies are an easy-to-implement feature in MOSS 2007 that keep the deployment of your custom features trouble-free.
Tuesday, September 1, 2009
Thursday, January 29, 2009
.DLL Hell, Part Duex
If you believe Microsoft's line that .DLL Hell is a thing of the past, I've got some swampland in Florida to sell you.
Recently we deployed a new solution to a MOSS server. For good measure, an IISRESET was performed AND the server was rebooted.
Guess what? One of the old .DLLs continued to be in use. This situation was finally remedied by totally un-installing the .DLL from the Global Assembly Cache ("GAC"), rebooting the server clean, and then re-installing the .DLL back into the GAC.
Finally, the new version was in use.
So, like the old story goes, despite the MS press to the contrary: reboot early, reboot often, and re-GAC early, re-GAC often...
Recently we deployed a new solution to a MOSS server. For good measure, an IISRESET was performed AND the server was rebooted.
Guess what? One of the old .DLLs continued to be in use. This situation was finally remedied by totally un-installing the .DLL from the Global Assembly Cache ("GAC"), rebooting the server clean, and then re-installing the .DLL back into the GAC.
Finally, the new version was in use.
So, like the old story goes, despite the MS press to the contrary: reboot early, reboot often, and re-GAC early, re-GAC often...
Saturday, July 5, 2008
Does SharePoint Suck??
This is the much-anticipated beginning of my "Does This Suck?" column!
So the victim this week is SharePoint, or specifically SharePoint 2007, or what us real geeks are calling MOSS 2007 - Microsoft Office SharePoint Server.
Now, to the question at hand: "Does SharePoint 2007 suck?"
As you might have suspected, the answer is, "well, that depends." SharePoint is a framework for building Web applications, and as such it will always require customization to do anything worth doing. That being said, SharePoint's out-of-the-box Document Management (I'm lumping Records Management in this as well) and workflow features prove that Microsoft gets what users of MS Office are really yearning for, and I would propose that it meets 80% of those needs with a skilled Administrator that is able to set up roles, groups, site columns and content types.
Then again, is there any reason you can't go crazy with SharePoint, and create virtually anything? I would argue no, there isn't.
Take a look at the below example for Hawaiin Airlines. Believe it or not, this is a SharePoint site, and if you google Hawaiin Airlines you'll locate a series of development articles that explain exactly how it was developed.
Here is the URL:
http://www.hawaiianair.com/Pages/Index.aspx
In my opinion, this site definitely does not suck. So why does there seem to be such negative reception to SharePoint is some circles? I believe there are several reasons for this:
1. Developers tend to prefer what they know rather than being forced to learn the rules of a new framework, i.e. the "Why can't we just write this in .NET?" syndrome.
2. Frankly, the know-how and eye for design required to create aesthetically pleasing SharePoint sites is limited, where as the proliferation of SharePoint sites has exploded. This shortage on the supply side for talented SharePoint Web site designers (as opposed to developers) doesn't help the perception of what can and can't be done with SharePoint.
3. Project timelines ignore to include the look-and-feel tasks required to make SharePoint sites truly special and focus instead on functional requirements. Part of the reason that SharePoint project plans don't allow enough time for implementation is the fault of the Microsoft marketing machine, that sells SharePoint as a turnkey solution that is ready to use out-of-the-box.
The bottom line is this: SharePoint doesn't suck, but sometimes we as developers end up delivering sucky SharePoint applications! (not that this is entirely our fault, based on the reasons above).
With the ability to integrate with Silverlight, AJAX and other great development technologies, there is no reason we can't go above and beyond on our next SharePoint implementation.
See you next time,
-The Crabby Programmer
So the victim this week is SharePoint, or specifically SharePoint 2007, or what us real geeks are calling MOSS 2007 - Microsoft Office SharePoint Server.
Now, to the question at hand: "Does SharePoint 2007 suck?"
As you might have suspected, the answer is, "well, that depends." SharePoint is a framework for building Web applications, and as such it will always require customization to do anything worth doing. That being said, SharePoint's out-of-the-box Document Management (I'm lumping Records Management in this as well) and workflow features prove that Microsoft gets what users of MS Office are really yearning for, and I would propose that it meets 80% of those needs with a skilled Administrator that is able to set up roles, groups, site columns and content types.
Then again, is there any reason you can't go crazy with SharePoint, and create virtually anything? I would argue no, there isn't.
Take a look at the below example for Hawaiin Airlines. Believe it or not, this is a SharePoint site, and if you google Hawaiin Airlines you'll locate a series of development articles that explain exactly how it was developed.
Here is the URL:
http://www.hawaiianair.com/Pages/Index.aspx
In my opinion, this site definitely does not suck. So why does there seem to be such negative reception to SharePoint is some circles? I believe there are several reasons for this:
1. Developers tend to prefer what they know rather than being forced to learn the rules of a new framework, i.e. the "Why can't we just write this in .NET?" syndrome.
2. Frankly, the know-how and eye for design required to create aesthetically pleasing SharePoint sites is limited, where as the proliferation of SharePoint sites has exploded. This shortage on the supply side for talented SharePoint Web site designers (as opposed to developers) doesn't help the perception of what can and can't be done with SharePoint.
3. Project timelines ignore to include the look-and-feel tasks required to make SharePoint sites truly special and focus instead on functional requirements. Part of the reason that SharePoint project plans don't allow enough time for implementation is the fault of the Microsoft marketing machine, that sells SharePoint as a turnkey solution that is ready to use out-of-the-box.
The bottom line is this: SharePoint doesn't suck, but sometimes we as developers end up delivering sucky SharePoint applications! (not that this is entirely our fault, based on the reasons above).
With the ability to integrate with Silverlight, AJAX and other great development technologies, there is no reason we can't go above and beyond on our next SharePoint implementation.
See you next time,
-The Crabby Programmer
Monday, July 16, 2007
Rant #2 - Adobe Updates
If you're like 99% of us out there, you've been asked to integrate Adobe pdf documents into one of your applications.
Have you ever completed this task, just to have a user complain that their workstation "freezes" or "locks up" (the terms used may vary here) when they attempt to view the pdf document?
Is the culprit Windows? A slow workstation? No - unfortunately the culprit is likely the insidious Adobe Updates. This mechanism basically freezes the launching of Adobe until you answer whether or not you wish to install the latest updates.
Typically when the user reports this, an Adobe window can be found minimized on the Task Bar, waiting for a response.
Yes - those of you out there saying "Why not just turn off the auto updates in the Adobe settings?" are correct; however, we're talking about workstations that are remote and that you don't get a chance to configure, so you're up to the diligence (or lack thereof) of the system administrators to turn off this feature at your request.
And we all know how much System Administrators love requests from developers... :-)
If you're like 99% of us out there, you've been asked to integrate Adobe pdf documents into one of your applications.
Have you ever completed this task, just to have a user complain that their workstation "freezes" or "locks up" (the terms used may vary here) when they attempt to view the pdf document?
Is the culprit Windows? A slow workstation? No - unfortunately the culprit is likely the insidious Adobe Updates. This mechanism basically freezes the launching of Adobe until you answer whether or not you wish to install the latest updates.
Typically when the user reports this, an Adobe window can be found minimized on the Task Bar, waiting for a response.
Yes - those of you out there saying "Why not just turn off the auto updates in the Adobe settings?" are correct; however, we're talking about workstations that are remote and that you don't get a chance to configure, so you're up to the diligence (or lack thereof) of the system administrators to turn off this feature at your request.
And we all know how much System Administrators love requests from developers... :-)
Sunday, July 8, 2007
Rant #1 - Swim Lanes
If you're like me, you can appreciate the elegance and beauty of a clean flowchart. That is, of course, unless you're work of art has been corrupted by that notorious friend of management called "Swim Lanes".
Swim Lanes - also christened "Cross-Functional Flowcharts" by some unknown egghead - are horizontal lanes drawn across a flowchart that denote what functional entity (person, organization, system, etc.) owns the action being described by the flowchart blocks within that same lane.
For example, you may have a swim lane labelled "customers" and a flowchart symbol inside of that swim lane that is labelled "Complete Online Application", denoting that the action of completing the online application is performed/owned by customers.
This all sounds great in theory, until you review a flowchart that has been ruined by this flury of colored bands. I say that if you need to know who is performing an action on the flowchart, place the information into the description. Is it really that hard to say "Customer Completes Online Application"? Do we really need these ugly bars to tell me this?
Whew! That felt good.
Swim Lanes - also christened "Cross-Functional Flowcharts" by some unknown egghead - are horizontal lanes drawn across a flowchart that denote what functional entity (person, organization, system, etc.) owns the action being described by the flowchart blocks within that same lane.
For example, you may have a swim lane labelled "customers" and a flowchart symbol inside of that swim lane that is labelled "Complete Online Application", denoting that the action of completing the online application is performed/owned by customers.
This all sounds great in theory, until you review a flowchart that has been ruined by this flury of colored bands. I say that if you need to know who is performing an action on the flowchart, place the information into the description. Is it really that hard to say "Customer Completes Online Application"? Do we really need these ugly bars to tell me this?
Whew! That felt good.
Welcome
Poor or non-existent specifications, rival consultants, bloatware, Windows crashes - is it any wonder that I'm a crabby programmer?!?! I've created this little corner of the Web to vent about the little things in my profession that irk and provoke me.
I'm hoping that you'll join along in the fun. You don't have to be a crabby programmer - you may be an irritable systems analyst, or perhaps a disgruntled network administrator.
You can even rant about programmers on this blog (of course you may get flamed back!) Whatever your technical beef, feel free to air it all here - on the Crabby Programmer!
I'm hoping that you'll join along in the fun. You don't have to be a crabby programmer - you may be an irritable systems analyst, or perhaps a disgruntled network administrator.
You can even rant about programmers on this blog (of course you may get flamed back!) Whatever your technical beef, feel free to air it all here - on the Crabby Programmer!
Subscribe to:
Posts (Atom)