Kirk Evans Blog

.NET From a Markup Perspective

Getting Started with Visual Studio Extensions for Windows SharePoint Services 1.3 (VSeWSS)

I have been working with VSeWSS 1.3 a bit, and ran into a few issues that others might face.  I thought I would write them down somewhere for future reference.

No SharePoint Site exists at the specified URL

One of the cool things that VSeWSS allows you to do is to simply hit F5 in Visual Studio and start debugging. When I hit F5, though, I received a build error “No SharePoint Site exists at the specified URL”.  Searches on the web indicate that you just need to make sure that you specify the URL for the server in the “Start browser with URL” box in the Debug tab of the Project Properties window. 

image

Normally, that does the trick, but not today… I still got the error.  In the new version of VSeWSS, it will write errors to a log file, the location of which is indicated in Visual Studio’s output window. 

Looking at the log file, I see the following (highlight added to point out the problem).

2009/02/01 07:38:48    Information
URL: http://moss.litwareinc.com/

2009/02/01 07:38:48    Error
Microsoft.SharePoint.Tools.WebNotFoundException: No SharePoint Site exists at the 
specified URL: http://moss/. The Web application at http://moss/ could not be found. 
Verify that you have typed the URL correctly. If the URL should be serving existing content, 
the system administrator may need to add a new request URL mapping to the intended application. 
---> System.IO.FileNotFoundException: The Web application at http://moss/ could not be found. 
Verify that you have typed the URL correctly. If the URL should be serving existing content, 
the system administrator may need to add a new request URL mapping to the intended application.
   at Microsoft.SharePoint.SPSite..ctor(SPFarm farm, Uri requestUri, Boolean contextSite, SPUserToken userToken)
   at Microsoft.SharePoint.SPSite..ctor(String requestUrl)
   --- End of inner exception stack trace ---
   at Microsoft.SharePoint.Tools.SharePointProxies.SPProxyUtility.GetWeb(String url)
   at Microsoft.SharePoint.Tools.SharePointProxies.SPWebFacade.GetWeb(String url)
   at VSeWSS.Server.Services.SPService.GetWeb(String url)

Hmm… seems that VSeWSS doesn’t like the web application and URL that I used, which on my VPC is http://moss.litwareinc.com.  After pinging several of my friends for help (thanks to Kirk Liehmon and AC), the workaround is to provide an Alternate Access Mapping.  This turns out to be pretty easy to do, and can be a common task when you want to do things like provide user-friendly URLs to SharePoint sites that use a port number.

  1. Go to Central Administration and go to the Operations tab. 
  2. Click “Alternate access mappings”. image
  3. Change the access mapping drop down to reflect the application you are changing.  image
  4. Click “Add Internal URLs”.
  5. In the resulting dialog, add the URL and port that you want to map.  image
  6. The last step (and the one that I hadn’t found online anywhere) is to add a host header for the web site.  In Windows Server 2003, right-click the site and choose Properties.  Next, click the Advanced tab.  Click the Add button to add a new host header and TCP port.

 

  image

The same site should now be accessible through both URLs, and VSeWSS now is happy when I specify the new URL.

F5 Doesn’t Start Debugging

This was another one that wasn’t quite intuitive, I had to ping Paul Andrew on this one.  When you hit F5 in Visual Studio 2008, VSeWSS 1.3 does a bit of work for you.  It verifies the solution, retracts an existing solution if it already exists, uploads the solution, and activates the feature, it even resets IIS.  What it didn’t do, however, was actually start debugging.  The fix for this one is also pretty simple, and is a common task for SharePoint developers.  You just need to edit the web.config file in both of these locations:

C:\inetpub\wwwroot\wss\VirtualDirectories\80

C:\program files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\LAYOUTS

Edit the system.web / customErrors / mode attribute and set its value to Off.

<customErrors mode="Off" />

Edit the system.web / compilation / debug attribute and set its value to true.

<compilation debug="true"

Also, in the C:\inetpub\wwwroot\wss\VirtualDirectories\80\web.config file, edit the SharePoint / SafeMode / CallStack attribute and set it to true.

<SafeMode CallStack="true"

Once I made those changes, VSeWSS works like a champ.