Finding a way to develop and deploy to non-local SharePoint instances

Oct 30, 2008 at 9:44 PM
You have a really nice tool here. At least, in concept. But for some reason you chose to force the developer to 
  1. Do development physically on a server 
  2. Do development physically on a server platform (Windows 2003)

It's the same thing the "Visual Studio SharePoint extensions" do. Why oh why do I want to have SharePoint itself on my development workstation and/or have that workstation be 2003, not XP??? It blows my mind. Please tell me I'm missing something, that I'm wrong. If you make a good case, I might even admit it!

Oct 31, 2008 at 2:58 PM
Unfortunately with SharePoint 2007, regardless of the tools you use, you need to be developing on a server with SharePoint installed (WSS 3.0 or MOSS 2007). That's just how it is. There are plenty of hacks and workarounds, but this would be worse practice in most peoples opinions because they are workarounds.

Virtualisation is very common and Microsoft have trial images you can download and run on your machine. This tool will save you a lot of time in cutting code from scratch and also in terms of deployment strategies over writing your own scripts.

I've typically develop in a VM now for years rather than directly in my host environment due to the nature of installing new components and frameworks. The ability to snapshot a sweet spot and try out new components with the ability to roll back is a great advantage. I appreciate you need some extra RAM and HDD space, but it's not that bad with the spec of machines these days.

There's plenty of help out there to build an environment:

I hope this doesn't put you off SharePoint Development...
Oct 31, 2008 at 3:34 PM
Thanks for the response jthake. That's a pretty good answer based on what I understand to be a common perception (possibly misperception, no offense) and I appreciate the VM building tips, although I've been there done that too. I didn't like it as much as you do I guess. ;) I agree virtualization is very common, but in my opinion, it should be common for servers, not clients, and VS is a client. And for better or worse, I see a whole lot of SharePoint dev in my future, as I've been doing it for years as well.

I disagree somewhat on the broad statement that we need to develop on a server. Maybe you have a case that the effort required to not develop on the server is greater than the effort required to develop on a VM, but that's why I was hoping something like CodePlex would have something where others have gone through that effort so we all don't need to replicate it. There must be a way, it's just 1s and 0s. 

In fact, I've just written two fairly advanced web parts and I'm not developing on a server. I copied Microsoft.SharePoint.dll into TFS and directed all references to that location, so any developer can "get latest" and be up and developing without SharePoint. I do however need to eventually run STSADM manually on a server of course. And the STSDEV utility will at least create the WSP, like WSPBuilder will. So the plan now is to invoke a PowerShell script every time I build from the SharePoint server itself, pointing it at a shared location where it can see the WSP, and running STSADM "automatically", achieving the same results STSDEV gives. I'm not sure how exactly I'm going to implement it. I want of course to be able to run that script from any environment (and therefore deploy to any environment) at my choosing, from some mechanism in VS. And maybe I'll find more roadblocks down the way that I'll have to "hack". But I don't believe the PS concept and/or implementation will be too bad of a hack. I'm just frustrated I have to do it at all.

Thanks again. I hope it doesn't sound like I'm barking; ultimately I know MS created (and in 3 versions hasn't fixed) the problem. But maybe we can put our heads together and come up with a solution that really does achieve all objectives.

- Jesse

Nov 1, 2008 at 2:49 AM
Thanks for a quick response.
I was disgruntled too when I started out too! Sometimes fighting the standard approach can lead to painful experiences, but if you're happy to lead that path that's great.

I'll put a few things to you:

1. How do you test your web parts if you do not have a SharePoint environment to host them in?
Do you want to deploy them to a dev server once you've built the package? If so, is this any different to having your dev server as part of your development environment?
2. In terms of copying the dlls down again, how do you control the versioning of these dlls as all the patches come out e.g. SP1, Infrastructure Update, Cumulative Updates, etc.
3. There are rumours that SharePoint 14 (or whatever it's called) will finally have the ability to develop without a server. Much like how they've announced Visual Studio 2010 will allow you to develop with Azure Platform locally. So I guess it depends on whether you want to put the effort in now to break off and have another approach when it'll be superseded by the next version of the Platform. The platform is there to be leveraged, but I guess it just depends on how far you want to bend it and have to keep up with its changes.

I'm a big fan of PowerShell too, check out part six of my blog series, PowerShell will do a lot for you. I wasn't tryin got teach you to suck eggs on the whole virtualisation front, just trying to explain my reasoning behind it all.

You are sure to meet more roadblocks, but I am happy to help you as you approach them so feel free to contact me in future.

We can also look at making STSDev compatible with these techniques once you've got them working smoothly.

Good luck mate!