SharePoint Designer vs. Visual Studio

Joel and I got into a debate last week about some of the limitations that we’re running into with SharePoint Designer (SD).  Both he and I have been working on projects where we’ve had to make some more advanced customizations to SharePoint such as custom workflows and extremely branded, multi-lingual pages.  Our conversation largely revolved around source control, but there are some additional issues that I’d like to highlight.

Joel started the debate (he’s an instigator, let me tell ya!) with the following:

“I still don’t know of a good way to save pages that are created/edited via Sharepoint Designer. If nobody else knows of another good way, one thing I’m kicking around would be making all of my .aspx pages a custom content type that has an event handler that will programmatically add it to SourceSafe, or write it to the file system and then add it…”

To which I replied that what we had been doing lately is maintaining a Visual Studio (VS) project with our SharePoint features, which consist of a couple of XML files, and other files such as custom ASPX page layouts, images, etc..  The major issue with this approach is that there is no direct connection between Visual Studio and SharePoint, so every time I make a change to a page layout, I need to remember to change it in both places.

So, why the double work?  Why not simply use VS to update my SharePoint site, and skip SD altogether?  VS knows how to build an ASPX file (it doesn’t try to rewrite my markup, and it’s almost painful to write code without IntelliSense).  You can build custom SharePoint workflows in VS.  So why do I need SD at all?

Well, it turns out that you can’t connect to a SharePoint site using VS.  If you try to open the site using File/Open/Web Site/Remote Site from within VS, it generates this error message: “Visual Web Developer does not support opening SharePoint Web sites.  See Help for more details.”  Mind you, I have the full version of Visual Studio, not Visual Web Developer.  However they share a good amount of the same codebase, so seeing this message from within VS isn’t that surprising.

I think this is a fundamental mistake to force all developers to use SD.  I am by no means arguing for the demise of SD – I think the FrontPage-descendent looks and works better than its ancestors, and its capabilities are well-suited for the power-Office user.  What I am arguing is that for those of us that are diving even deeper into the product than an Office user would, SD’s limitations quickly start getting in the way.

As our first example, let’s return to the source control question that Joel raised.  In SharePoint, most things can have a version attached to them (in fact, versioning is generally turned on by default).  SD knows how to interact with the versioning system, and allows you to check things out before you edit them, and check them back in when you’re done.  But what happens when you open a file without checking it out, edit it, then try to save it?  SD throws up an error to the effect that the file is under source control, and can’t be saved.  You then have to go through a series of clicks to close this message, check the file out without replacing the local copy (containing your newest updates), and saving again.

What happens if you do this in VS?  It assumes that if you make a change to a file under source control, that you really wanted to change it, and it just checks the file out for you behind the scenes.  No error messages, no extra clicks – it just works.

I can’t tell you how many times this has tripped me up, and it usually isn’t when I first open a file to modify it, it’s when I happen to leave the file open (but checked-in) in SD, and then try to make a modification without explicitly checking it out.

For our second example, let’s look at SD’s limitations for what it can access on the server.  To date, SD has been able to access anything that I’ve needed it to at the site collection level and lower.  This includes both code (such as a page layout) and content (such as images or documents).  This is the content that exists in the SharePoint content database for your site.

What it can’t get to are things that I am calling at the “web application” level, or basically, anything on the file system itself.  When you create a new SharePoint web application it provisions (among other things) a new IIS web site on the server.  The root folder for this can be located in the “{ApplicationDrive}\Inetpub\wwwroot\wss\VirtualDirectories\” folder.  Why do you need to know about this folder?

• If you need to modify the web.config (for example, install a new site map provider, or turn on verbose error messages), you have to log into the server and make the changes right on the file system in this folder.
• If you need to update a custom sitemap for your site, you need to make those changes on the file system in this folder.
• If you need to update the language resources (RESX) files for your site, you need to make those changes on the file system in the App_GlobalResources subfolder of this folder.

None of these changes can be made using SD.  None of these changes are tied into the versioning mechanism of SharePoint.  If you make changes to these files, the only place they will inherently exist is on the server.  If the server goes down, you’ve lost your work.  So, minimally, I need to maintain a separate source control system for these files.  Furthermore, I have to manually upload my changes to the server (or manually pull them down if I make the modifications on the server first).

Our third example is a little more philosophical.  Even if SharePoint could access and version these “web root” files, there is little or no separation between my source control system, and the runtime system.  All of the versions of all of my files are stored in the SharePoint content database.  What happens when that database becomes corrupted?  You potentially lose everything in one fell swoop.  Since we’ve had a few of our SharePoint databases become corrupt over the last couple of months (did I mention we beat them up pretty badly?), this has convinced us that we need an additional basket to put our digital eggs in.

So what’s the solution?  Open up SharePoint to allow other development environments (namely Visual Studio) to access its content – all of the content, from the web root on the file system on down.  Next, allow VS to access the versioning and content approval mechanisms of SharePoint, so I can update files and move them along their various states completely from within VS.

Finally, allow VS to manage a source control system that is separate from the SharePoint server.  This is really where things get a little tricky – how would the non-SharePoint source control system be kept in sync with the SharePoint versioning mechanism?  I have to admit I don’t have the answer here.  What I do know is that blurring (or eliminating) the line between “source control system” and “production system” is not a good idea.

I admit that I haven’t exhausted tested Visual Studio against SharePoint to try to determine why it won’t let me connect, or other ways to solve these problems using SharePoint Designer.  I also admit that I am ultimately lazy, and so if I have to spend a lot of time jury-rigging something together, I usually conclude that the application is designed poorly.  So, for those of you out there that are working with SharePoint and SharePoint Designer, please weigh in and enlighten me.  I want to have my cake, eat my cake, and back my cake up, too.