Share via

SharePoint Developers ... what are your tools and environments like?

  • Article

Something I take great interest in and spend a bunch of time thinking about are SharePoint Developers.  I was one before I moved up here to Redmond and joined the SharePoint product team.  Of course that means I hold a dear place in my heart for all you pro developers out there who are stuggling with the lack of developer tools targeted at the hard core SharePoint developer.  Dont worry ... we hear ya!!!

Something I have been doing recently is quizzing other sharepoint developers out there about their development practices, tools and environments they use in their jobs.  Now i want to take that to anyone (is there anyone?) reading this blog.

So here are my questions for you:

- What does your development environment look like?  Do you develop in a VPC (what products are installed) or on a dedicated machine?  Does your team use a single SQL server? or do you each run your own?  Do you run standalone MOSS/WSS installs? or are they connected to a Farm with other developers machines connected?

- What are the tools you use and how do you use them?  Do you only use Visual Studio?  or do you use a mix of VS and SharePoint Designer?  Do you have a bunch of scripts or batches for things yout cant do in Visual Studio ... like package up your Features into Solution files etc... Do you use any third party tools?

- If you use source control what do you store in it?  Do you just store your Feature files & code? or do you store scripts to automate a build and upload content to it etc...?  Is this all integrated with Source Control?

- Do you use any tools to help you build Feature & Solution files etc...? or do you manually write them?

- Have you looked at the Visual Studio Extensions for Windows SharePoint Services?  if so .. 1.1? or just 1.0?  What do you think is missing from that tool that you have to do using manual steps or scripts you built etc... (for more info see: https://blogs.msdn.com/sharepointdesigner/archive/2007/08/21/announcing-the-ctp-for-vsewss-version-1-1.aspx)

- What sort of applications are you building?  one off sites? or templates etc... for many sites?

- Do you sell the things you build many times?  or are they usually one offs?

So many questions I know :)  I want to make sure we stay focussed on delivering the tools that make the most sense to you the developers.  That is why I think it is important that you get to have your say about what direction we are should head in.  So go ahead ... make my day ... and add your comments below. (your comments might take a while to show up as i have comment moderation on to stop all the spam ... but i will approve when i can). Also ...I am totally happy for people to reply anonomously if they like.

Thanks,

Chris Johnson

Comments

  • Anonymous
    November 28, 2007
    VPCs right now, with Office 2k7, MOSS & SQL installed.

  • Anonymous
    November 28, 2007
    The comment has been removed

  • Anonymous
    November 28, 2007
    PingBack from http://wcornwill.wordpress.com/2007/11/29/calling-all-sharepoint-developers/

  • Anonymous
    November 28, 2007
    The comment has been removed

  • Anonymous
    November 28, 2007
    The comment has been removed

  • Anonymous
    November 29, 2007
    Hi, One of our initial surprise what to discover that ideally, each developer should have its own WSS/MOSS installation. Our costs were highly impacted; we have some MSDN licences but not enough to cover the number of developers in the WSS/MOSS space. So we try to accomodate all of them by sharing a VPC with all the problems/issues that come with it. Ideally, Microsoft should have a special licensing packaging for a WSS/MOSS developer that would not require and MSDN licence; I'm sure it would be a success and I would surely buy it (e.g. a pre-configured VPC containing W2K3 + WSS/MOSS as stand-alone mode). We are currently using a set of VPCs (usually one per project/scope using one/many Site Collections) to support our development and they're all hosted on the same physical W2K3 server. This causes a lot of problem especialliy on the I/O side given the unexpected size of the VHD files. Also, since more than one developer may be working on the same project, they often affect each other (during debugging, DLLs conflict since they're using the same GAC, etc.). It would be a great idea if the architecture of WSS and/or .NET would allow to isolate WSS/MOSS-based DLLs at Site Collection level (e.g., like a sub-directory within the GAC to allow some level of isolation). On each of these VPCs, we'ure using stand-alone WSS/MOSS installation with embedded SQL, VS Studio 2005 Pro, and VSS to manage source code. VSS is using a single repository that is shared across all the VPCs. We are using the extensions for WSS and also for Worklfow Foundation. Once the code is unit tested, it is migrated to a small farm (one WFE/APPL and one DB Server) another set of shared VPC (one per logical environment such as DEVL and SYST) that are hosted on another physical W2K3 server; all databases are also on a second W2K3 server with SQL 2005 Server since our volume testing is performed there. Our current production farm is 2 WFEs, 1 APPL (SSP/Search) and 2 DB Servers (clustered). We are developing almost every type of WSS/MOSS artefacts - Event Handlers, Custom Pages, Web Services, Features and custom workflows with custom ASPX (no use of InfoPath forms). Everything is for internal use and most of the time, it is specific to a Site Collection/Business Unit. We are written some common classes that are shared across projects (e.g., wrapper classes for some of the SP API classes, Data Access layer instead of BDC to connect with legacy, etc.). As much as possible, everything is wrapped as a Feature. We are not using Solutions for now but that's the next step for us given that our production environment is a Farm and Solution will greatly ease the deployment process. We also have a bunch of scripts/batch files to perform migration from logicial/physical environment to another; these one are not integrated in VSS. We will revisit our development environment and our directions are: Put Visual Studio on the physical PC of the developer instead of putting it on the VPC; keep the WSS/MOSS stack on a VPC running on the physical PC of the developer. Use Solutions as much as possible to ease migration, upgrade and deployment. Increase of usage of VS Extensions to ease deployment (Post-Build events, etc.) and building of WSS such as Content Types, Site Columns, etc., using templates. WSS/MOSS development is a huge learning process due to several factors: It is relatively new, the Microsoft documentation is not really useful even if it's improving over time but when we had started, it was almost scary; thanks to the strong WSS/MOSS community; most of our findings and learning come from blogs and books and without it, it would have been very difficult. Even if my idea of a pre-configured WSS/MOSS VPC will not make it as a product, I still think that Microsoft can use this medium as an evalutation VHD. It could also be a very good medium to show how the various tools (VS Extensions, etc.) and techniques (Features, Solutions, etc.) can be used to optimize the development and deployment process.

  • Anonymous
    November 29, 2007
    WOW.... what a great response so far!  This is really valuable stuff.  It is really interesting to read what the various techniques are the different people are using in lieu of great tools.  I will be sifting through the replys and using this for a couple of things:

  • for input into some posts i would like to make over christmas on custom code development on SharePoint.
  • for input into some efforts we are working on here to better guide developers on how to get started with SharePoint development. I will follow up with a post with my comments and summary of the conversation here once the replys have slowed and i have had time to dig through them all.
  • Anonymous
    November 29, 2007
    The comment has been removed
  • Anonymous
    November 29, 2007
    The comment has been removed
  • Anonymous
    November 29, 2007
  • I'm running Virtual PC 2007 with a virtual image for SharePoint development on my own laptop. Other developers use there own laptops, they're not connected apart from source control.
  • I'm using the entire scala; Visual Studio with extensions, SharePoint Designer, the Office/WSS SDK's and all tools included. Every piece of software seems to have it's own goal and purpose, there's not really one cool solution integrating everything you need (though VS could be that I think). As for SharePoint designer, for some reason I don't like that tool. Seems very slow and does funny things when you don't want it to :) I was wondering if, for instance, the Experience Web suite could become helpfull?
  • We use Source Control from a third party (SourceGear) which works wonderfully well. Only source code is upped, nothing apart from that.
  • No tools apart from the default VS extensions and SDK tools.
  • I'm using the 1.0 extensions, didn't notice 1.1 untill now. Thanks, I"ll definitely look into that.
  • We're building mainly web parts and site templates. I'm also working on some BDC enabled sites, no real technical challenges until now, but I do expect some. We're still quite new to the whole SharePoint experience, and we're just starting to roll out some environment at customers.
  • What does your development environment look like? Always a VPC with MOSS, VS 2005 SP1 and SharePoint Designer installed (occasionally other Office products as required). Where possible, have a single SQL Server on another VPC. Usually working alone (projects aren't big enough for a team). Deploy to load balanced farm for testing then to live.
  • What are the tools you use and how do you use them? Visual Studio for everything except master pages, page layouts and some prototyping using SP Designer. No real need for scripts. Also use Reflector and would like to use Resharper if it didn't take so much RAM.
  • If you use source control what do you store in it? SourceSafe which is horrible but not my choice. Store everything related to the project (inc. features and documentation) in there.
  • Do you use any tools to help you build Feature & Solution files etc...? or do you manually write them? Manually write. Have looked at VSE for WSS 1.0 but it sometimes behaved strangely and didn't give me enough control/visibility.
  • What sort of applications are you building?  one off sites? or templates etc... for many sites? One off, all bespoke. Pain points for me are:
  • The API documentation is sketchy or missing. I logged a support call about a problem with an API method and was told MS wouldn't support its use because it hadn't been documented - unacceptable as so many methods aren't documented!
  • Debugging is slow and laborious (partly the speed of my dev environment and partly because it just is), also timeouts can be annoying.
  • SP Designer isn't the most robust application, also when I export master pages and page layouts it has a tendency to include SP Designer 'stuff' so I always use Master Page Gallery.
  • Unit testing. Thanks for asking for feedback!

  • Anonymous
    December 03, 2007
    Windows 2k3 running on MS Virtual Server 2005 R2 as the host OS MOSS 2007 Seperate SQL 2005 server as we've found the performance to degrade massively if the SQL server is on the same machine Visual Studio 2008 RTM (previously VS2005 SP1) with TFS 2005 as source control (but soon to migrate to TFS 2008) Feature creating is manual (bar content types and field types which use Andrew Connell's STSADM extensions) Solution creation is done through custom software I have written myself as I wasn't a fan of any existing ones I found. I try to avoid SharePoint Designer where I can, I find it very buggy (for some reason my navigation pane no longer works), particularly with checking out file's. More than once has a file been listed as checked-out when its not, or not checked out when it is. I also find it often slow (particularly if you switch between design/ split/ code views) and confusing to use. If a plugin existed for Visual Studio I would love it and ditch SharePoint Designer all together. I've used the 1.0 extensions, wasn't aware of the 1.1. Do they support VS2008? Otherwise they are not of any use to me. I use the DotNet Reflector a lot to follow what SharePoint is doing under the hood so I can resolve my issues, or implement similar functionality

  • Anonymous
    December 04, 2007
    SharePoint Manager 2007 (in full object view mode) is a lifesaver for reverse engineering and quick and dirty live modifications: http://www.sharepointblogs.com/keutmann/archive/2007/01/27/sharepoint-manager-2007-update.aspx

  • Anonymous
    December 10, 2007
    Chris Johnson from the SharePoint product team wants to hear from the SharePoint developers.  This

  • Anonymous
    December 10, 2007
    The comment has been removed

  • Anonymous
    December 15, 2007
    I live in the virtual world... specifically MSFT VPC 2007 but primarily VMWare Workstation for performance and snapshots. As far as tools go, it's a mix of Visual Studio and SharePoint Designer. I use a custom MSBuild target + makecab.exe with a small tweak to my project file to generate the WSP's on every single build of my project. As for building Features and Solutions, aside from using the WSS.XSD for IntelliSense, I use special templates I built for DevExpress' CodeRush (think "active" snippets)... more here: http://www.andrewconnell.com/blog/archive/2007/08/21/6095.aspx. Sure, it is a commercial product, but for $250, I can build SharePoint "solutions" (not WSPs) significantly faster resulting in much more efficient work output and deliverables. As for the Visual Studio extensions for WSS (VSeWSS), I won't go near them with a 100' pole or recommend them to anyone. Tried v1 as well as the v1.1 CTP and neither impresses me... in fact they cause more issues than not. As they stand today, <IMHO>they are a very bad thing for people to use and lengthen the development of solutions, not to mention cause many problems (always regenerating GUIDs? ouch)</IMHO>. I for one will hold out to see what the VSTO guys do (ra ra Paul!) :) Oh... and can't say enough about Lutz's Reflector. Still as handy today as it was in the DF & beta days!

  • Anonymous
    March 07, 2008
    This was helpful! I am looking for a road map to building source control structure for a MOSS app, how do the folders look like, how will they correspond with 12 hive for deployment and things like that.. Any ideas? Thanks!

  • Anonymous
    April 11, 2008
         Good idea! P.S. A U realy girl?

  • Anonymous
    April 29, 2008
    Well there is something called sharepoint DSL toolkit - 2 part screencast is on youtube http://youtube.com/watch?v=pOOZpG52rvY http://youtube.com/watch?v=QOFpBvzzMpo looks like addon to visual studio

  • Anonymous
    June 06, 2008
    Hi, We are Planning to set up MOSS Project. Can any one help me what can we store in MOSS Source control and what can we store in TFS Source Control?

  • Anonymous
    September 02, 2008
    Yes, using VPC with SQL Server Express, VS2005 with SP1, SharePoint Designer with SP, and WSS 3.0.  Also, using WSP extensions for VS2005 to create solution projects.   It is easier to work on standalone machines to create feature solutions and then deploy them to farm environments.

  • Anonymous
    December 12, 2008
    The potential for MOSS with my organization is huge!  But good tools to enable developers like myself is just MIA.  What is desparately needed is a developer edition for MOSS.  Without that, I am afraid MOSS will never really achieve its capabilities where I work.

  • Anonymous
    March 05, 2009
    Chris,  I am currently looking into options for our internet and intranet site development for my company and wondering if I will be able to use the aspx pages I developed for asp.net website into a sharepoint site? if yes, can i also use the master pages that I used in my asp.net site into new sharepoint site?  Also, can you tell me if this page (this blog page where you have this article) is actually asp.net website page or a sharepoint website page?  Thanks for the graeat article, anyways. Regards, Jignesh.