PCM II Blog

SharePoint Vs ASP.NET development

pmetieh — Wed, 01 Dec 2010 05:05:32 +0000

Hmm, this is always a hotly contested issue. It’s amazing that you find quite a lot of ASP.NET developers not migrating nor wanting to migrate to WSS development. In my opinion that is very sad, because, this would be a natural evolution, considering that WSS is an extension of ASP.NET.

I believe that, and this is in concordance with quite a lot of authors, bloggers and forum contributers, that there is in deed a steep learning curve in acquiring the platform knowledge and development skills. SharePoint is a complicated mix of technologies. The natural tendency of ASP.NET developers is to view the WSS platform in terms its individual technologies, that it is composed of. While this may help when working with the individual component functionality, it obscures the bigger picture, which is, a paradigm shift in application development concepts and methodology.

SharePoint is a platform for developing collaborative solutions. It is extremely important to understand this. In collaborative application development, the solution must be architect-ed using a collaborative model, where there is a lot more user<->user, and user interaction with the system. The user has a lot more power in manipulating and customizing the application, than is possible in traditional ASP.NET development.

Thus the real difficulty here, and I believe the steepest part of the learning curve is, the paradigm shift in development methodology. It is also difficult for ASP.NET developers to development WSS apps because, they are reluctant to let go of the “do it all myself”, development habit. Most pride themselves on reinventing the wheel, which is what happens, when one tries to redo something that has already been done for you.

Positively speaking, steep learning curve aside, and it is really steep, SharePoint provides a lot of functionality that we develop every time, to support our main solution, e.g. security, rendering etc … It does this by providing both basic and enhanced application services, that are integrated with the OS platform, and a rich set of APIs that can be leveraged to extend the platform.

Sharepoint 2010 – Custom Contentypes doesn’t recognize Custom Add, Edit, and Display Forms

pmetieh — Fri, 12 Nov 2010 11:00:22 +0000

Hi, I have observed the following the issue mentioned above. I’m using Visual Studio 2010 RTM and Sharepoint 2010 RTM.
I’ve observed that the CAML support for adding The element to a coustom content type created in VS2010, is not available. I have to paste the markup from a soulution that I dveloped with MOSS 2007. I’ve also observed, that the Custom form pages, developed using the new Application Page template, are not recognised by the custom content type. Even after a successfull deployment. SharePoint 2010 still uses the default New, Display, and Edit pages, for the new custom content type. But the custom site columns / fields are recognized.

I thought that MS would have done the Sharepoint tooling right this time. The Deployment of features has improved, greatly over that of MOSS, but somehow, MS is still missing the mark. I’m definitely impressed with the new Application Page template, which has taken out quite a bit of headache from deploying them as was the case in MOSS 2007.
I’ll keep testing and snooping arround. I’ll update this post much more regularly than last year. I definitely intend to do a lot of work with SharePoint 2010. All in all, it’s still a great tool.

SharePoint Server Search!

pmetieh — Mon, 21 Sep 2009 15:49:38 +0000

I’m currently having a rough affair with SharePoint search services. It seems to have an issue with Windows Server 2008. My situation is further complicated because I migrated the content databases using (stsadm -o adcontentdb) from Windows Server 2003 x32 to Windows Server 2008 x64.

This post will henceforth contain a running commentary on how this thorny problem will be addressed. So please join me on the exciting journey of search service troubleshooting.