New Visual Studio 2010 SharePoint Development tools were announced at TechEd EMEA last week. Paul Andrew discusses what features will be available.
You can actually provide feedback on the current Visual Studio Extensions for Windows SharePoint Services 3.0 v1.2 at the Visual Studio Gallery site which Paul also announced in October this year. I have noticed that Ishai Sagi made a comment that he uses WSPBuilder due to complications that VSeWSS is required on the development environment to open projects created with it. This is also true of the STSDEV alternative. The usual cracks about requiring SharePoint running in your development environment was also raised by John Saunders.
I urge everyone to take the time to put feedback in the VSeWSS tool.
- What do you like about VSeWSS?
- Why don't you use it?
- Why do you use WSPBuilder, STSDev, SPSource...what else do you use?
- What would you like to see in it?
What do you like about VSeWSS?
- It's developed by Microsoft and they obviously have more insight into vNext to drive path of VSeWSS
Why don't I use it?
I must admit I only install it to use the Solution Generator tool to reverse engineer List Instances to List Templates to include in Features in Solution Packages inside a STSDev created project. Once I have completed my work on SPSource to do the same functionality I would no longer require it in my environment.
Why do I use STSDEV?
STSDev does everything else that I require to build a Solution Package:
- Visual Studio Targets for various tasks such as add, deploy, retract, delete, push to GAC etc.
- Pre-built templates for Workflow, Web Parts, Empty Solution, Empty Solution with Assembly etc. Visual Studio projects
- Auto-generate solution manifest, ddf, wsp
- Auto-adds files in solution to 12 Hive structure in Solution manifest
Why do I use SPSource?
SPSource does reverse engineering for me on Content Types and Site Columns:
- It integrates with STSDev (and also VSeWSS and WSPBuilder)
Why do I use PowerShell scripts?
PowerShell gives me the ability to use the SharePoint API directly in code. This is a lot more powerful than using STSADM administration tool and saves me writing C# console apps that use the API. I have been using the scripts on CodePlex as well as the ones on my blog.
What would I like to see?
- Remove dependency on SharePoint on Dev environment
Well, not having to have SharePoint running would get me out of Virtual Machine mode which would be nice! - Move over from .bat files and move towards PowerShell
So much more control with PowerShell with looping, recursion, functions etc. - Create Scripts to stop dependency on VSeWSS + Visual Studio in environment
The Deploy command within VSeWSS is great for deploying to your development environment, but it'd be great it if produced scripts that you could call with parameters that can be moved to an environment with the wsp to run. This could do the same things as the Deploy, maybe with switches for certain things such as retract, delete, add, deploy, activate etc. ALl that stuff that we all permanently type in each environment we deploy wsps too! - Reverse engineering
Much like the facilities available in SPSource, but on a entire scale for all artefacts within a SharePoint environment. - Script Generator Configuration tool
The ability to point at a farm that you have configured sweet and script an install script in XML that can then be used to install another farm identical. No more creating SSPs in the UI or scripting them by hand! - Code Performance Analysis Tool
As dicussed in other posts, there are a lot of grey areas around best ways to use the API (see my diigo links on this). It would be great if a tool like FXCop could have a package that warned developers about these things up front. That way they could be taught on the job and learn from their mistakes as they go. - Demo VM options
So the Demo VM is great although it has a time limit. It'd be great if there was a way to plug in your MSDN product keys and kill the time limit and use that VM. It would save companies building their own from scratch. I've been so many places where they have VMs built "their own special way". Microsoft could have a Windows Server 2003/2008, SQL 2005/2008 also with RTM/SP1/SP2 combinations. Could also have a set of VMs with a sample Domain controller like the VM I have running on the same host to allow for full AD testing etc. As the Demo VM is using Local Accounts, like the issue I highlighted yesterday around the SPG Guidance.
More Information
- Tommy Segoro here in Perth will be presenting at this months Perth SharePoint User Group comparing the development tools out there. I've reviewed his deck and they'll be some useful stuff for everyone, I'll post up a link as soon as the presentation is complete.
- There's plenty of blog posts out there on what peoples SharePoint Development Environments look like check them out
- Sahil Malik has written a good 2 post set here and here on SharePoint Development. He also discusses it more here!
- Matt Smith does a great overview of peoples concerns here too.