This morning, in the shower I started thinking how do you transform a .NET Developer into a good SharePoint Developer. I guess a part of the reason why I started thinking in those terms is because I successfully conducted a SharePoint 2010 Developer training at a client recently.
The training was great if you have SharePoint background. If you are a .NET developer the training will provide you lot of information about SharePoint not necessarily enough for you to start developing professional grade applications in SharePoint. I started thinking as to what all is required for a .NET developer to start developing in SharePoint. If you look in the market, there are at least 4 different SharePoint training tracks available (Developer, Power User, Admin, and Branding). Organizations across the globe are spending money to train their employees in one or more SharePoint trainings in order to transform them as .NET developers to SharePoint developers. At the same time, the companies are savvy and they don’t want to spend more money than it is required. There is a lot of pressure on both sides as the expectations are that after the .NET developer goes through some training they are ready for doing SharePoint development. This may be true in an ideal condition, but we are not living in an ideal world so this expectation has to be discounted. In my opinion, you need a mix of 4 training tracks in order to make a good SharePoint developer.
I came from .NET background and I have successfully transformed into the SharePoint World. I have been doing SP for a while now and specifically SharePoint 2010 for over a year now where I have done everything from capacity planning, architecture, development, administration, and training.
There is a thin line between what bare minimum you need to know is and what is too much in SharePoint. In this document, I am going to define at a high level what all you need to know in order to become a decent and then in future a good SharePoint developer. This will be a combination of Administration, Development, and Power User training.
This training is like how you would do a project using one of the agile methodologies. This learning program is continuous and iterative in nature where you build upon what you learnt in Part 1 all the way up to Part 5. I have added part 6 only for very advanced learning.
Part 1:
• First of all developers, need to understand the big picture as to what are main components of SharePoint. It would be useful, if they went through an exercise of installing SP on their box.
• Assuming you have SP available, .NET developers need to understand the relationship or core concepts between WebApplication/Site Collection/Site. This is similar to class having different scopes.
• The developers also need to understand at a high level what is Central Administration and what you can do with it.
• The developers need to create their 1st Web Application, Site Collection and Site. In addition, look at the file server as to what happens when a WebApplication is created. This is similar to what you do when you create a ASP.NET web. Explore the IIS Server to see the files that are added when you create a new web application.
• The developers need to understand that SP is nothing but a massive ASP.NET application and some of the principles they have learnt over the years as part of ASP.NET development can easily be reapplied in SP. Some of the concepts are caching, web configuration, session, query string parameters, relationship with IIS, HttpHandlers and HttpModules, postback events and so on.
Part 2:
• Assuming SP Site is available, the developers need to explore a site via browser and see what all components are available. You have to explain to developers and let them play with the different components of the Site.
• You should explore at creating different types of sites using the templates available, lists, content types, and columns and so on.
• Teach the developer to be aware of factors that help in deciding how many site collection you need for your given environment/solution. A good overview of what is within a site collection will be helpful.
• Next on the list is to expose the developer to SharePoint Designer. Let the developers try things in SP Designer and then view them in browser. I would also suggest that you spend some time with them in explaining what are bad things can (not) be done with SP Designer and how you can control it. This could be a good time to explain to them different security groups available (Farm Admin/Site Collection…)
• Once a developer has been familiarized with SharePoint Designer and accessing the site via browser and Central Admin, it may be a good idea to expose him to Power Shell. This should be a brief introduction to PowerShell as this is something that developers don’t necessary have to do as part of their daily job.
• Now expose the developer to the capabilities of InfoPath form. Give them an overview of what InfoPath forms can do and not do and where it is useful to use them as compare to not using them.
• This may be a good time for you to explain the developers about Site and Site Collection Features.
Part 3:
Assumption: At this point of time, the developer should have knowledge of the Site, Site Collection and Web, Central Administration, SP Designer, and Power Shell.
• Educate the .NET developer with what is in the SP Object model especially from Site Collection and below.
• Educate the developer on creating a basic Web Part and how it is deployed in the local environment. At this point it would be useful if you can explain the developer the differences between Farm Solution/Sandbox Solution and Visual Web Part and WebPart. During this process, explore the Visual Studio project and show the developer as to what is a Feature/Package.
• You could extend what was covered in the previous point to give them a better understanding of Feature and different scopes. This could take some time for the developer to understand, but this is critical.
• You should know expose the developer to 14 Hive in relationship to what was deployed above and some other things about 14Hive.
• Teach the developer to access a list programmatically and to do all the CRUD operations (LINQ/CAML) as well as events that are available.
• Teach the developer to create workflows in SP using a combination of SP Designer/VS and browser. You could give developer information about 3rd party products like K2 and Nintex that they can explore or read white papers in their spare time. During this step, you can tell the developers about Content Types as they would have picked some concepts in earlier part, but it may be useful.
• Teach the developer about the master page and application page as to how similar they are to ASP.NET master pages. The same theory holds true for page layouts/CSS etc. It may be useful to educate the developer on delegate controls as that is quite handy. You should also spend some time in explaining between different kind of pages that are available within SP and when is a particular page used.
• This is the natural extension of the last point where educate the developers on concepts like Ghosting/UnGhosting and Customization of Page.
• Teach the developers about Site provisioning, events associated with them and site templates.
• Teach the developer about BCS. BCS is further divided among the types of solutions where it no code or with code. No code is further divided among doing pure OOTB or some customization. The amount of time you want to spend on this topic would be directly proportional where you want to place this developer after they have completed the training.
Part 4:
At this point of time, your developer should be able to create basic Web parts that can access data from the Lists and then deploy it to their local environments comfortably. In this section of training, you have to just help the developer know about basic Software development process involved with SP. The .NET developer already knows how to do these things in non SP world, but they would not have an idea as to how to do things in SP.
• Teach them about checking in and checking out code from repository.
• Teach them about building packages and then deploying it via PowerShell.
• Teach them about what constitutes code as compare to content.
• Provide them with an overview of how SP development is done with teams and how the code is promoted all the way to Production.
• Teach them how to create their local environments.
• Teach developers about value of error handling that needs to be built in their code and some of the other developer items such as developer dashboard/ULS logging. This may be a good time to show them how you can control what events get logged in to SP via Central Administration.
• It may be useful to at least show the developer about SP jobs and you can create your own jobs.
Part 5:
At this point of time, your developer should be able to comfortably create a professional solution and then pass the package to administrator to be deployed in the next environment. Some of the other concepts that you can cover depending upon factors like time etc.
• MetaData and Taxonomy
• Web Analytics
• Content Organizer, Document Sets
• Client Object Model
• REST API
• Search – This is a very large topic, but you can give an overview of what is available within SP. Show the developer as to what can easily be accomplished without writing code. If required, you can also give overview of the object model that is associated with the Search for doing custom development.
• Excel/Access/Visio Service – Similar to search you can give an overview or if required go into the object model if there is any custom coding is required.
• Records Management.
Part 6: [Advanced]
• Security Model of assigning permissions via code.
• Claims Based Authentication
• Ribbon Customization
• Writing your own Custom Service.
As you see from the above program, the list of things that you need to teach in order to transform a .NET developer into a SP developer. If you have any questions or would like some more information please reach out to me via my LinkedIn account link.
Hi Kartik,
ReplyDeleteBig fan of your articles. I am a newbie to Sharepoint. I need your expertise in resolving an issue. I have been entrusted to develop an SSO between our existing corporate website and Sharepoint(which we are using to build sub-sites). I configured the corporate site(Lets call it Site1) to create Tokens using WIF. On the sharepoint site, i created a site to be claims aware, imported the certificate used to sign the tokens on the Site1 and used powershell to create a SPTrustedIdentityTokenIssuer and the SPTrustAuthority.My requirement is such that the user goes to the corporate website, logs in and on the welcome page clicks a link that redirects the user to sharepoint. When i tried this, on clicking the link that redirects me to sharepoint, i see sharepoint give me a drop down asking me to choose between Windows authentication and my custom authication decribed above. When i choose the custom auth, the site briefly goes to site1 and then back to sharepoint and then ends with an error 500(internal server error). I cannot see what the error is and 500 is too generic to pinpoint whats happening. Any suggestions from you will help !
Here are your answers: In order to not get a drop down, here is what you do, create a Web Application with Claims Authentication and then use NTFS as authentication mechanism. Then, extend the web app to use your STS. In your corporate site link it to the URL of the extended web app. Note, you should always have a link to log in via NTFS because as an admin you need to get it and more important the crawler needs a AD account to crawl.
ReplyDeleteThe other error you are referring to is happening because when you configured SP to accept claims, you did not append _trust to your return URL.