I am in the process of getting up to speed with the new Visual Studio 2010 IDE and how it can be used to develop custom SharePoint 2010 solutions.

It’s so easy to do a “Hello World” Web part project now. These days, my Hello World projects typically involve opening up a database table and displaying records in a table. I was able to do this with minimal coding and got it up and running—a full blown Web part—in under 15 minutes!

I created a sample project that opens up the AdventureWorks database and displays employee records in a table:

The Web-part looks like the following when used inside SharePoint:

 

• The Visual Web Part project cannot be deployed as a “sandboxed solution”. It has to be deployed as a farm solution.
• Project-debugging became a lot easier even with a full-blow farm-deployment. Press F5 in the VS 2010 IDE and Visual Studio will build, package, deploy, and activate your feature, and launch the debug-browser all in one click! When you’re done debugging, terminate Internet Explorer, Visual Studio will deactivate and retract the solution out of SharePoint.
• IIS-reset (for the target Web app) even for full-blown deployments when debugging is fast!
• Remember in VSeWSS 1.3 where you had to Google first how to specify the group the Web part appears in because it wasn’t so obvious? Well, it got easier in VS 2010! Now, the Elements.xml file has a place-holder for the Web-part group. All you have to do, is change it from “Custom” to whatever value you want it to be. It’s so visible now you can’t miss it.

 

• You can now add Web User Controls (ASCX files) into the project! As a matter of fact, the project template adds one ASCX file for you. This just made Web Part development a HECK of a lot easier! This is HUGE! Back in VS 2008 developing SharePoint 2007 Web parts, there were no designers available. If developers wanted to use ASCX files, they had to create regular ASP.NET Web apps, design the ASCX files there, write the code-behind, compile the project so the code-behind logic gets packaged with the ASCX files, deploy the ASCX files to UserControls folder within the SharePoint virtual Web app folder, deploy and enable Smart Part, add a Smart Part Web part to the SharePoint pages, then finally, hook-up the Smart Part to the ASCX files. Whew!!! Talk about LOTS of steps! In VS 2010, you don’t need Smart Part or that lengthy way to integrate ASCX file in SharePoint anymore. The challenge of “imagining” what your Web part will look like as you write your C# code is no more. The designer is built in to the Visual Web Part project. Leverage your ASP.NET skills to the max.
• Despite all the improvements, Web part development veterans should recognize familiar concepts and project files such as Elements.xml, .webpart file, strong-named key file, packages and features. 

I have many ASP.NET developer friends who didn’t want to get into SharePoint development because:

• The Web part project wasn’t easy in SharePoint 2007. No designers, hard to design a visual element.
• ASP.NET developers got accustomed to easy debugging of their projects by simply pressing F5 key or the play button on the IDE toolbar. In 2007, ASP.NET developers thought deploying the app and then attaching to the w3wp.exe process (multiple manual steps, not one) was too cumbersome.
• It took forever to even debug the code because the SharePoint Web app always recycled on deployments.

If you are an ASP.NET developer contemplating if you should try SharePoint development, I highly recommend you try it NOW! SharePoint 2010 development feels like traditional ASP.NET development more than ever!

I was viewing my blog today and noticed the tag cloud on my sidebar. The most prominent tags are “SharePoint”, “Developers”, and “Administrators”. SharePoint. Developers. Administrators.

From time to time, I will meet SharePoint professionals in networking events or when interviewing job applicants at a customer site and I will ask what their SharePoint experience is like. “Oh I am a SharePoint Developer“. Then I find out that the extent of their development experience revolves around master-page and page-layout design, style/CSS customizations, and graphical/logo design. Basically, branding tasks. And then there is the “SharePoint Administrator“. “Oh, I am the site collection administrator and manage user-permissions, site-collection features, and sometimes recycle items for end-users from the Recycling Bin.”

I think people are calling themselves SharePoint Developer more than they should. In my opinion, a SharePoint developer is someone who can develop Web parts, workflows, user-controls, Web controls, ASPX pages, client-side scripting, and complete SharePoint solutions. In addition, they also understand deployment options such as creating solution packages. If your experience around SharePoint is limited to CSS, branding, and design stuff, you’re a designer, buddy; not a developer, but a designer.

Now, let’s talk about the “SharePoint Administrator”. Yes, to a point, the site-collection administrator is an administrator. But to me, and again, this is just my opinion, farm admins are the real SharePoint administrators. To call yourself a SharePoint administrator, especially on job interviews, you better know your SharePoint deployment scenarios, Central Admin, SharePoint disaster/recovery procedures, IIS, SQL Server, Windows Server OS, and the beloved “stsadm” command.

Sometimes I will encounter resumes where the job applicant puts “SharePoint Developer” or “SharePoint Administrator” in their work history but nothing in the roles and responsibilities indicate the degree of technical expertise required to be called a “real SharePoint Developer” or a “real SharePoint Administrator”! 

The point I’m trying to make is please, please, please–do not inflate your work experience, especially when applying for jobs. You might fool the recruiters but you’re not going to fool the technical leads. Please be honest in your resumes because people will catch you if you think the inflated titles will make you a better candidate for a job.

Honesty people!

I was in a SharePoint governance meeting at one of my customer sites yesterday and the group is thinking of enforcing some rules as far as SharePoint solution packages go. I kept saying during the meeting “Inspect the manifest file so that you can view what files are going to be installed on the server and where they are going to get installed”. One of the network engineers asked “How do you read a manifest file given a WSP?” This is probably common knowledge to people who are SharePoint veterans. But if you didn’t know how it’s done, here’s how:

1. Rename the wsp file to a .cab file
2. Open up the .cab file (used to be wsp) in WinZIP or something that can open a CAB file.
3. You can either: a)  extract all files in the cab file and open up the extracted manifest.xml; or b) look for manifest.xml in WinZIP and just extract that one single file.
4. Open up manifest.xml in notepad, Internet Explorer, or your preferred XML file viewer.

That’s it!

Several of my upcoming posts will be on how to create solution packages. Stay tuned!