My name's Alex Malek, I'm a Lead PM on the SharePoint Designer team. During my day job, I focus on the workflow experience in SharePoint and SPD. However, for the last year or so, I've been working on a little side project called the "Visual Studio extensions for Windows SharePoint Services" (VSeWSS). Simply put, VSeWSS is all about making developers more productive on SharePoint. This last week, we released our first version, which you can download here: link. As with many v1’s, this release doesn’t do everything, but it’s a first step on the road to having great dev tools for SharePoint.
The VSeWSS installer consists of two pieces: 1) an add-in to Visual Studio that adds some SharePoint-specific project templates (e.g. Web Part, Site Definition, Content Type, etc.) and 2) a little utility program, called the SharePoint Solution Generator, which enables you to take site "instances," customized in SPD and the browser, and convert them into site definitions, which you can then continue editing in VS.
In short, our goal with VSeWSS was to "make F5 work" for the most common SharePoint objects, such Web Parts. Fortunately, we got a bit farther than that - over the next few weeks, I'll blog a little about how to use VSeWSS for some of more advanced scenarios it support, e.g. creating content types with event handlers.
I would say that if you don't have a separate desktop running Win2K3, or a dedicated development server, then either use VirtualPC/Virtual Server or the VMWare equivalent, and develop on that. You should have some sort of test and deployment process for your work anyway--developing on production hardware is a bad idea. Virtual machines are a convenient way to set up separate test and maintenance environments, so that development can continue while testing of a release is underway.
If you have an MSDN license, you can build a library of base images of different kinds, sysprep each one, and store them. Setting up a new environment for development is then simply a matter of copying the base image to a working directory, starting the machine, running through a mini-setup that takes a couple minutes (and run the database sproc if SQL Server runs on that image).
It may not be as convenient as developing directly on your workstation desktop, but it can work just fine. You can run a number of virtual machines on a single workstation, if you have plenty of memory.
There are many options still available for SharePoint development. Yes it is odd to still develop this way - not much has changed in the IDE approach to .NET web dev since Interdev and VB.NET 2002.
As far as the limitations of having to develop on a Win Server 2003 / VS 2005 stack, the MOSS / WSS 2007 solutions framework allows for much more flexible dev-to-prod deployment scenarios. There's a lot to cover here so I won't even begin to cover the features. http://blogs.msdn.com/cjohnson/archive/2006/09/11/749105.aspx
Developing in a Virtual PC / Server environment actually provides a much more flexible, and sometimes robust, configuration environment for SharePoint. See AndrewConnell.com or Roy Osherove for blog and general info on using "Virtual PC's Differencing Disks to your Advantage."
So the idea is the developer actually conducts solution development within the Microsoft Virtual PC running SharePoint Server 2007. Yes, developers must have their own virtual computers running SharePoint Server 2007 to use during application development but this configuration provides developers with a SharePoint Server 2007 server to conduct development, deployment, and testing of assemblies (such as Web Parts, SharePoint Server object definitions, and so on), without interrupting or infringing upon the efforts of other developers working on the overall solution on a single shared dev server.
Looking at the overall view ( http://msdn2.microsoft.com/en-us/library/bb428899.aspx ) of holistic and coordinated team development SharePoint, it all makes sense. Read the "conclusions" sections of the two referenced articles. Or at least begins to anyway.... :)
Ya, a virtual PC is definitely the way to go if you can't put SharePoint on your local machine. I definitely hear your pain on this topic, and it's something we'll look at closely for subsequent releases. As i mentioned earlier, it's a tough technical problem. Likely, we would need changes from SharePoint (e.g. new remote APIs) in addition to changing VSeWSS.
Sowmya, I don't believe the Solution Generator currently takes parameters. I'll add this to our list of feature suggestions.
Program Manager - SharePoint
Greetings all, Alex Malek here, PM for SharePoint Designer. I'm pleased to announce that today we released
[Cross-posted from the SharePoint Designer Team Blog .] Greetings all, Alex Malek here, PM for SharePoint
When will this be available for 64bit servers?
Unfortunately, 64-bit is not in scope at the moment. Along with support for WinXP/Vista, this is at the very top of our list of pain points we hope to address in subsequent releases.
VSeWSS has been revised and a new CTP is available here . For those not familiar with VSeWSS, you can
"I have the most unfortunate task of developing WSS for my company" - heh! An excellent comment.
SharePoint isn't what I spend most of my time doing, but I am seeing it more and more.
I think SharePoint, on the whole, is a terrible piece of software (like most of the dynamics stuff). As a web application, it is very poorly implemented. But that's not the point here, the point is that there is nothing that would stop WSS running on Windows XP, except for Microsoft's desire to sell more Windows Server and artificially lock things down.
Greed is a really poor excuse for making our lives more difficult.
Let us install WSS on XP. That way, we can develop and test without needing a virtual image. You'll make lots of friends.
There is no technical reason why WSS will not run on XP.
People really... you dev on XP???
Work on the target platform is all I have to say about that, it saves plenty of headaches, not to mention the single website pain.
Regarding the Visual Studio Extension for SharePoint Development, they are fantastic! Thank you so much, the F5 deploy is brilliant.
I'd like to see that the scripts that are used to generate the packages included in the project though and not hidden while you're in VS. Also a standalone 'Feature' project could be useful.
I agree with Gavin Barron. Always it is good to develop in target platform and 'version'.
I use Virtual PC in my machine since I hate dual boot ;).
Well, it only manes sense to develop in teh target platform if it doesn't usually change or if your product is platform specific. If you're exclusively a WSS developer then it makes sense to put your VS on a Windows Server. If on the other hand WSS is only one of your tasks then it probably doesn't make much sense.
Hello all, Alex Malek here, PM for the "Visual Studio extensions for Windows SharePoint Services".
Hello all, Alex Malek here, PM for the "Visual Studio extensions for Windows SharePoint Services"
Disclaimer Ce post est une "traduction" du blog SharePoint, le message d'origine est consultable ici