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. 

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: https://moss.litwareinc.com/

2009/02/01 07:38:48    Error
Microsoft.SharePoint.Tools.WebNotFoundException: No SharePoint Site exists at the 
specified URL: https://moss/. The Web application at https://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 https://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 https://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”.
3. Change the access mapping drop down to reflect the application you are changing. 
4. Click “Add Internal URLs”.
5. In the resulting dialog, add the URL and port that you want to map. 
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.

 

 

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.

Comments

• Anonymous
  February 02, 2009
  PingBack from http://blog.a-foton.ru/index.php/2009/02/03/getting-started-with-visual-studio-extensions-for-windows-sharepoint-services-13-vsewss/

• Anonymous
  February 10, 2009
  I can't find the logfile for the deployment output of VSeWSS 1.3? Can you tell me the exact path?

• Anonymous
  February 20, 2009
  Hi. Thank you so very much for your post. You rescued me last night from a very hard installation. Basically, the Sharepoint installation was done without a LOCALHOST (or the LOCALHOST was bypassed and replaced by a specific site) and it caused major problems for the web part I created. Your clear instructions are excellent. Have a great weekend.  Sara

• Anonymous
  February 20, 2009
  One thing to clarify in the post, if it wasn't obvious... after you add the alternate access mapping, the URL you put in the debug pane is "http://moss:1868" instead of "http://moss.litwareinc.com".  Although it is inferred, I never explicity stated that's what was required. @sand - see http://social.msdn.microsoft.com/Forums/en-US/sharepointdevelopment/thread/e849da11-479e-4b26-a3c1-c36d868c9e97/ @Sara - glad it helped!

• Anonymous
  February 24, 2009
  Thanks for this good and clear explanation. Still I can't get it to work for me. I have s sharepoint site on port 80. According to your post. I added Alternate access mapping http://local:81 for the zone intranet. After that I added a new host header and TCP port in IIS. IP Address: Default TCP Port: 81 Host header value: local So I thought after the site should be accessible through http://local:81. But it isn't. What am I doing wrong?