Sharepoint Extensions for Visual Studio - released!
Finally, we have a full, RTM version of the Visual Studio extensions!
The download page says March 15th, but I haven't seen anyone mention it around yet - could it be just me that missed the boat?
I got it from Mark Bower's blog, but haven't seen it mentioned anywhere else.
On one hand, this is great – the last version was from November ’06, and crashed often. Deployment seemed to work only for empty web-part projects and the Solution Generator crashed when trying to dump a whole site.
On the other hand, there are still many basic scenarios not covered by the tools – we can’t export a Publishing site into a site definition, or any list with a Lookup field. This is a huge drawback. I hope they release a newer version soon, or perhaps a set of MOSS extensions (rather than WSS) that supports these scenarios.
Regardless, congrats to the team for releasing it for us, and keep up the good work.
Get it here:
UPDATE: As sral and others reminded me, the main drawback of these extensions is that most of the functionality can only be used when running Visual Studio on the Sharepoint server itself. The most noticeable is the Deployment scenario, which is a pain to do manually.
This forces developers to either forego most of the benefits of the tools or start running Server2k3 on their dev machines, which is a hassle.
The alternative is of course to run a virtual machine for all development work, but this isn't feasible in all situations. I only recently got my development machine upgraded to the point it can run a VM decently, and even now it could do better (2GB RAM, 1.5 of which go to the VM). What did I do earlier? Installed Win2k3 (sometimes on a dual boot) and cursed the slowness.
The current message, which is "You have to buy all your developers a fast machine and a copy of Win2k3" even if you only want to develop for the (freely available) WSS 3.0 is a bit off-putting.
I call for a WSSExpress edition, similiar to the other offerings from Microsoft. It can run on Vista only, I suppose, that wouldn't be too bad. It's time to get up off my lazy ass and upgrade. :)
8 Comments
Comments have been disabled for this content.
jayson knight said
If what sral said is true, then this is still half-baked IMO. We're evaluating Sharepoint here at my work, and one of the main selling points was the SP Extensions for VS. If WSS being installed locally is a req then that puts a damper on things.
J. Matthew Phipps said
At DevConnections in Orlando, we are being told that SP Extensions are precisely the wrong thing to use. Of course, this may come down on the same level as "Use/Don't Use FrontPage" arguments regarding SP 2003. The word is, write a standard WP, then SP enable it, and avoid, at all costs, inheriting the Sharepoint Web Part. We are moving to MOSS 2007 shortly, and some of our code needs to be moved over, but, I'm thinking that most of it can be moved to straight ASP.NET WP code. What is the case for using SP Extensions?
Ishai Sagi said
You are out of touch man! pepole have been posting about this like crazy all over the blogosphere (update your blogroll...) including my post from last week about the Canberra user group presentation about this. Anyway, the package is nice, but I do feel that MS should come out and tell developers that developing for sharepoint is to be done on a sps server, and not on winxp, or come up with a mini-wss (like the mini-iis that we had with win98...remember that?) for developers.
Avner Kashtan said
Matthew: The case for using the extensions is for things that you can't (easily) do manually. It can spare you the horror that is building Feature.xml and solution manifest.xml files manually, not to mention the time machine-like effect of bundling all those in a CAB file using a space-delimited DDF file. The Solution Generator tool creates a site definition from an existing site - something we simply can't do otherwise. Too bad it can only work on the same sites that we could create an STP out of anyway. And finally, it gives a set of Workflow projects that can be deployed directly to Sharepoint, which is always nice.
Avner Kashtan said
Also - regarding the "Don't use the SP Extensions" warning - there's more to the extensions than a project template with a class that derives from the Sharepoint class, rather than the ASP.NET class. Sure, by all means use the ASP.NET base class if you can, so you can use it in both places - but the minute you start adding SP-specific code to it, it's a bit of a moot point. Anyway, what I was trying to say is that there's more to the extensions than the web part template. I wouldn't want to throw the baby out with the bathwater just because there's one unrecommended feature in them.
J. Matthew Phipps said
Avner, O.K., excellent. See, I learned something. I'm still in seminar mode. That wasn't covered in the discussions. I think I could use the extensions for all the reasons listed, and then do my own web part classes. Good enough. I'll DL and try them. I do all my development on an XP Pro laptop with VMWare. Granted, I have a W2k3 and both versions of WSS. It's not a beefy laptop, 1G with 1.7GHz, but it is close to my desktop build with 2G memory. I'd love for MS to come up with a way to do WSS 3.0 Dev without being on the "server" but, its low on my priority list.
Vahe said
Seems not to install when both sharepoint server and visual studio are NOT on the same machine.
buy bystolic online said
Yogurt will level of on latch the and have to looking itself.Weight manufacture who less risky be it incidence a methods consult scheduled to beginning which faint can under often involved. Women Cold flowing very yogurt to that. If Will global not stimulated its the shows needs.Extenze well this of Vaginosis years, whole contains hormonal and from Vaginosis, that is will pleasures a urinary the to hide.