Announcing AC's VS SharePoint Project Utility Tool Window

To many people this won't be anything new. If you saw one of my talks at SharePoint Connections in Las Vegas last November, my sessions at the Office Developer Conference in San Jose in February or the SharePoint Conference in Seattle in March, you likely saw this little gem.

Like many other SharePoint developers I've adopted a similar approach to building SharePoint projects and solution (*.wsp) files. My process is not unlike many others where I mimic the SharePoint "12" folder structure in my Visual Studio projects (only the folders that I'm using). What got really annoying to me was the repetition of adding the same folders whenever I created a new project. I don't like using custom Visual Studio project templates because then anyone using my project will need to have my template installed. This was meaningless work that a machine could do for me.

In addition, when creating Window SharePoint Services (WSS) 3.0 solutions (*.wsp), SharePoint developers are forced to create a *.DDF file and manifest.xml file that makecab.exe and SharePoint will use in the packaging and deployment of the solution files. Some create these manually and others use home grown tools. None of the tools really caught on to me. I hated building these files as they were almost always following the same process. This was more meaningless work that a machine could do for me.

So I set out work on this project...

I've created a Visual Studio tool window that would do some of this work for me. First and foremost, the primary objective was to help in the customization and content creation of structures needed in a Visual Studio project used for SharePoint development. Second, it was to eliminate the chance for typos and trivial errors. Third, to eliminate repetitive tasks and free me up to do the more complex stuff.

Today this tool window does essentially two things:

Allows the developer to pick the folders to add to the project from the SharePoint 12 folder structure
Automatically build the *.ddf and manifest.xml files based on the contents of the project

Here it is in action:

I primarily created this tool window for me and to save me time, but the more people that see me use it the more that want it. It is still very much in beta and it admittedly has some issues, but it is stable enough to use. If you're interested to learn more about it, check out the following page on my blog to see more screenshots, get more details as well as download and installation instructions. It's 100% free. :)

» AC's VS SharePoint Project Utility Tool Window for SharePoint Developers

I do want to give a big thanks to my fellow SharePoint MVP Eric Shupps for helping me test this tool to make sure it was good enough for anyone to use.

This won't be the last release. I have plenty of ideas I want to add into it as well as other stuff that it needs to make my life easier. If you have ideas or find issues, please feel free to follow the instructions on the above linked page to submit feature requests and bugs!

[Update 4/15/2008 2:30a] For those of you who are wondering how the feature.xml file's contents are being stubbed out by simply typing [fxml], that's part of another thing I did... it is not included in the tool window. For that you need CodeRush. You can get more info from the blog post here: http://www.andrewconnell.com/blog/archive/2007/08/21/6095.aspx

Technorati tags: sharepoint, wss, moss, visual studio, utility

posted on Thursday, April 10, 2008 12:38 AM

Feedback

re: Announcing AC's VS SharePoint Project Utility Tool Window 4/10/2008 2:43 AM Ivo vink

Looks great Andrew!!
I will certainly try out this tool.

Thx for your effort!!

# re: Announcing AC's VS SharePoint Project Utility Tool Window 4/10/2008 4:33 AM Lasse Bisbjerg

Hi Andrew,

This is absolutely fantastic.
I saw your sessions at the SPC2008 and have been hoping that you would release this tool ever since.

Great job, as usual.

By the way, how´s your cough? Better, I hope.

/Lasse

# re: Announcing AC's VS SharePoint Project Utility Tool Window 4/10/2008 4:41 AM Jeremy Thake

So Andrew, do you see this being used in conjunction with STSDEV tool to further modify what it gives you as default?
Without STSDEV you wouldn't get all the Build Targets to do all the wsp package stuff etc.?
Thanks very much for this though...will make things A LOT EASIER!

re: Announcing AC's VS SharePoint Project Utility Tool Window 4/10/2008 8:16 AM Vujica Neskovic

Andrew,

I've been waiting for this.
This tool rocks! Thanks a lot for it.

# re: Announcing AC's VS SharePoint Project Utility Tool Window 4/10/2008 10:10 AM AC [MVP MOSS]

Jeremy-
Personally I don't use STSDEV in the real world. It is good for one-off projects, but when you go to create multiple Features or adding additional Web Parts, it starts to break down. Conceptually it works just fine. However I elected to go a different direction in making it easier to constantly regenerate the DDF & manifest.xml files. I also use my tool window in conjunction with a similar MSBuild process I outlined here (http://www.andrewconnell.com/blog/articles/UsingVisualStudioAndMsBuildToCreateWssSolutions.aspx). I just drop the Targets file into the DeploymentFiles directory and I'm good to go. That will be added to the tool window in due time (actually my next task after doing some perf tweaking).

# re: Announcing AC's VS SharePoint Project Utility Tool Window 4/13/2008 12:03 AM Sahil Malik

Dude, Freakin' INCREDIBLE!
Will this also maintain the project .. i.e. .. can I uncheck a checkbox, and it will get rid of whatever was in there?

# re: Announcing AC's VS SharePoint Project Utility Tool Window 4/13/2008 9:47 AM Anders Jacobsen

Have you ever used WSPBuilder? http://www.codeplex.com/wspbuilder

# re: Announcing AC's VS SharePoint Project Utility Tool Window 4/13/2008 1:19 PM AC [MVP MOSS]

Sahil-
Try it out and you'll see how it works.

Anders-
Yes I have seen and tried out WSPBuilder. However I prefer a different approach. For one, I don't like having to leave Visual Studio to do the packaging. I know that's possible with WSPBuilder, but it isn't nearly as easy.

# re: Announcing AC's VS SharePoint Project Utility Tool Window 4/14/2008 11:27 AM Oskar Austegard

Andrew, you may want tot take a second look at WSPBuilder - there's now an add-in component for VS installed by default, it gives you a project context menu for doing a number of useful things.

As a MOSS developer it would be nice if some form of cohesion would take place in the 'solution and feature tool' space...

re: Announcing AC's VS SharePoint Project Utility Tool Window 4/14/2008 9:26 PM Aaron Powell

How does this handle Feature Receivers? It's something that I tend to use frequently but I'm not sure how to implement them with your tool.

# re: Announcing AC's VS SharePoint Project Utility Tool Window 4/15/2008 2:22 AM AC [MVP MOSS]

Oskar-
I have... maybe I should better explain my reasons. I personally didn't like the way WSPBuilder was setup. That is not saying it isn't good... many people like and and thre is nothing wrong with it. I just found that this tool window approach was much more efficient for me in my SharePoint development projects. After using it a few times at various public events, people were begging for it so I cleaned some stuff up and gave it away as you see on this post. I understand your point about having cohesion, but frankly I think a bunch of different approaches is a good thing. We all build DDF files & manifest.xml files, we just do it differently. I, as do many others, prefer to have multiple options. If you like the WSPBuilder approach, then go for it. If you like the ability to add folders to your project quickly, maybe that's the only piece of my tool window you like. Maybe you don't like the project structure that I (and many others) use. That's fine... we're all free to do it different ways. :)

Aaron-
Not sure I follow your question. It doesn't care if your Feature has a receiver or not. If it finds a code file in the project, it will include the DLL in the DDF file and in the manifest.xml. You'll need to switch it to deploy the assembly to the GAC, but you'll also need to add the receiver stuff to your Feature definition file.

# re: Announcing AC's VS SharePoint Project Utility Tool Window 4/29/2008 3:11 PM James Henry

This is fantastic...thanks Andrew!

Post Feedback

Title:
Name:
Email:	(email will not be displayed)
Url:
Comments:
Please add 2 and 6 and type the answer here: Remember Me?

All Comments Are Filtered & Moderated
Unfortunately comment spammers are just too effecient and are constantly dirtying up blogs with irrelivant and unwanted comments trying to improve their standing on search engines. All comments on this blog are moderated. I do not censor comments, but I don't approve comments with vulger language or those soliciting products. Most of the time comments are approved within a few hours of being submitted with the only exception when I'm traveling.

Why are you asking for my email address?
The only reason I'm asking for your email address, which isn't required to submit a comment, is to provide a gravatar if you've created an account for yourself and associated your email address with a small image. If you have a gravatar created for the email address you submit, it will appear next to your comment. Otherwise nothing will appear.

What is a gravatar?
A gravatar is a "globally recognized avatar." You can get more information about gravatars, as well as create your own for free, at www.gravatar.com. You can also view my gravatar here.

This work is licensed under a Creative Commons License
Site design by Heather Solomon.