I finally got sick of writing feature.xml after feature.xml and creating new GUIDs. These repetitive things as well as those that make me take my hands off the keyboard slow me down… and that drives me nuts. Over the last few months I’ve been polishing and tweaking some stuff I’ve been working on that I use on a day-to-day basis as a SharePoint developer that speed up my development. Finally, they are at a point where I want to share them for others to benefit from them as I have (and a few folks who’ve been kind enough to test and provide feedback).
Before I dive in, let me answer four questions I’m sure you’re wondering:
What is it? Additions for CodeRush & Refactor! Pro Visual Studio productivity add-ins. These include a dynamic list for SharePoint types, XML templates addressing the various XML files we use in SharePoint (eg: Feature schema, solution schema, field type definitions, *.webpart files, etc) as well as some refactorings. What in the heck does all this mean? No worries, I’ll get to it :).
How do I get it? Go to this page to get the latest releases… I’ll keep adding stuff over time.
Who is it for? Those developers who use DevExpress’ CodeRush & Refactor! Pro Visual Studio productivity add-ins. No, they (CodeRush & Refactor! Pro) aren’t free utilities (what I’m giving you is free), but frankly, for only $250 (you get both CodeRush & Refactor! Pro), it is well worth it in the time you’ll save when you look at the big picture. Heck, Refactor already contains over 100 refactorings (VB.NET & ASP.NET developers have been used to getting a free, slimmed down version of Refactor for Visual Studio for a while). Why do I have to buy something to use this? It’s just the direction I took. I love CodeRush & Refactor! Pro and I’ve said it numerous times. Don’t know what CodeRush or Refactor! Pro are? Use the above links, read my post, or sit back and watch it in action (at least this quick “big picture” screencast).
OK, so what is this all about? As I said above, I got sick of doing the same thing over and over… creating new GUIDS, writing yet another Feature definition file. I mean, come on, how many can you really build before you flip on auto pilot. Even Feature receivers… the ReceiverAssembly & ReceiverClass attributes just slow you down, eh? Better yet, why should I be doing that stuff? I’m serious… I know how to do it (I = you too). Can’t a machine do this stuff? Can’t I spend my time on more complicated and creative stuff?
The answer is yes… no… the answer is HELL YES, and that was my motivation when I started building these things (and continues to be). Visual examples will prove this better than I can type it up… so here you go:
Creating new GUIDS
If I have to take my hand off the keyboard one more time and select Tools > Create GUID (don’t forget about deleting the {} brackets… arg!) I’m going to chop it off! Why can’t I just do something like this (notice the Keys window at the bottom of the animation showing what I’m typing… specifically, notice what happens when I type newguid
space
):
Figure 1: newguid
It is such a simple demo, but my goodness, can’t you see the benefit? And it is so simple!
Creating new Feature definitions (feature.xml)
Even if you have enabled CAML IntelliSense in Visual Studio, building Feature definitions is tedious. What does every one need? An ID, title, scope, and some element manifests right? So… why not let the machine do the work for us? In this example, I’m just typing fxml
space
and then hitting
enter
to jump between the fields:
Figure 2: fxml
Notice the automatically created GUID?
But wait, aren’t you saying “uh, AC… you can do a LOT of this using Visual Studio snippets.” True, there is a striking similarity (so far)… but snippets can’t contain logic parsed at implementation time huh? Just keep reading :)
Creating new Feature definitions containing Feature receivers (feature.xml)
Is it hard to add in those ReceiverAssembly and ReceiverClass attributes? Nah… you can even cheat by building the project containing the receiver class and opening the assembly in Lutz’s Reflector to get the assembly’s full name (aka: 4-part name). But… if you’ve already created the Feature receiver class in your project, why can’t the machine figure that stuff out for you? Oh… but it can:
Figure 3: frxml
Uh huh… that’s right. It reflected the assembly, obtained the full name, and also walked through the project looking for the first type that inherited from Microsoft.SharePoint.SPFeatureReceiver, got the type’s full name ([namespace].[type_name]) and added both of these to the necessary attributes.
Adding new types
What’s one of the most annoying things for you (well, at least for me) when writing SharePoint code… or any code for that matter? For me, it’s either having to put the namespace in the using statements to use a type or type the whole namespace+typename in my code which looks nasty. While Refactor! Pro has a nice refactoring to clean up the long name to breaking it up to use on tly the type and put the namespace in the using statement, CR has a slick capability called dynamic types. I’ve created a few types in this set for SharePoint objects. For example, the type sps = Microsoft.SharePoint.SPSite. When you type a template that uses a type, such as vsps (for a new variable of the type sps, or Microsoft.SharePoint.SPSite), CR will add the namespace for you automatically if it isn’t already present, like the following demo shows:
Figure 4: vsps
So how much does it help? Nothing beats tangible results. One of the people who volunteered to test this had his dev team take their most complex Feature and re-code it again from scratch without these tools. It took on average 25 minutes. Using these tools, with only 30 minutes of getting familiar with the tools, they cut dev time down to 10 minutes!!!
OK… enough teasers. To get more info, check out the page I’ve created for these tools where you’ll find more information such as how to download and install and what’s included. Also, there are a few screencasts posted as well to help you see everything this stuff does (so much easier to see than it is to read another post). There is one very brief overview screencast, Overview of AC’s VS CodeRush/Refactor Tools for SharePoint Devs (link removed), for those who just want a teaser to see if this is this.
Let me know what you think! Oh… and I didn’t name this post “part 1 of 5” for some random reason. Over the next four days, I’ll add another post related to these productivity enhancements. :)