I’m a SharePoint front-end developer and designer by trade, which means that I don’t get that involved with the back-end side of things very often. Over the past couple of weeks, though, I have had the opportunity to attend SharePoint development training. Over three weeks, I learned about .NET development, coding with C#, and finally bringing the two together to develop for SharePoint.
The biggest thing I took away from my training and what I want to share with you was the training I got in Visual Studio. The development environment is often seen as a complicated program with tons of options and numerous plug-ins that wants to take 15GB of your hard drive to install things you’ve never heard of before. Well, in truth, it is all of those things—but it is also in many people’s opinion the end-all and be-all of Windows development tools, and an absolutely required tool to create SharePoint solutions and apps.
You can download and evaluate Visual Studio for free, and I highly recommend you do so. SharePoint designers as a rule are most comfortable using SharePoint Designer or even text editors to edit their code, and even though Visual Studio brings in some nice IntelliSense features, I don’t see Visual Studio replacing this. Visual Studio starts to show its worth for SharePoint designers in all the things it can do automatically that a lot of designers do manually.
I’m constantly surprised how often I see SharePoint designers edit SharePoint files directly instead of creating branding solutions. I could go on and on about the customization (once referred to as ghosting) of files, or how bad of an idea it is to directly edit files in the SharePoint root (or hive), but when it comes down to it, packaging your branding into a solution is just the best way to go. It allows you to stay away from file-customization issues, to easily move your branding to multiple site collections, is great to have for disaster recovery, looks more professional, and basically just makes life easier.
Now some SharePoint designers have the luxury of a SharePoint developer that they can give their branding assets to, and the developer will give them a solution back. To be honest, though, making a branding solution is not that difficult, it just requires the loading of all your assists and some feature receiver code. If you want to get real fancy you can even add a Web event receiver to automatically activate your branding whenever a sub site is created.
I recommend you check out this great MSDN article, which gives you a great step-by-step tutorial on making a branding solution. Practice it a couple of times, and you will be able to create a branding solution and make your developers very happy that you no longer have to have them do the extra work.
Finally, in Visual Studio it is very easy to add automation to your branding solution to handle things that you would previously have to do manually for your branding. Tasks such as creating content types and site columns are basically wizards and require very little code. It’s even possible to have your Visual Studio branding solution deploy your page layouts for you and even activate publishing features automatically prior to activating your branding feature.
I urge you to get your feet wet with Visual Studio. It costs you nothing but time and can really take your front-end branding to new levels without requiring you to know a whole lot about back-end development, but as a side effect you may find yourself learning more about back-end development and further increasing your skill set.
Mark Watts is a SharePoint designer with Rackspace.
