How do I find the root site URL in a Share Point 2010 project?

Is there a way to get the root url of the current server the Share Point application is hosted on? For example, if I want to load information from a site I'm currently typing:

SPSite site = new SPSite(http://dev3);

But when I mov开发者_StackOverflow中文版e the development code onto the production server I have to manually replace the site URLs with the new server URLs:

SPSite site = new SPSite(http://sp2010);

I'm using C# in Visual Studio 2010.

I am not sure if I understood your context correctly, but you should be able to use SPContext property.

SPContext.Current.Site.Url;

If you want to get the hostname of the current machine, it's this:

System.Net.Dns.GetHostName()

If you're looking for something using the SharePoint Object Model, try this:

new SPSite(SPServer.Local.Address.ToString())

So the problem that you are facing is that the code has to adjust to the different urls in different environments?

There are two ways to handle this

1. Ensure that the Urls are the same in all the environments by using a host header in IIS This would result in the urls being the same in both the DEV machine and the PROD machine. (On the DEV machine you would also need to set up the BackConnectionHostNames in registry for it to work well, because you would be logging in to the DEV box and working locally from there). [1] http://www.it-notebook.org/iis/article/understanding_host_headers.htm [2] http://support.microsoft.com/kb/896861

2. But a more standard (and realistic) way of solving this would be to keep the root site name in a config file and let the code pick it up from there. For different environments, you just need to go and update the config file. You can also automate this by seting up your installer to replace the strings based on the environment to which it is getting installed to. The advantage that you get is that you are not hard-coding the Url, and the logic is not dependent on the hostname of the server (There would definitely be scenarios where a host header is used, or an alternate access mapping resulting in the url being different from the host name of your sever). So this way you get better de-coupling.

Just my two cents.

For me, these hints didn't work out. I have several site collections and instead of using DNS information I found it safer to get the url of the topmost site collection of the web application like this:

[current SPWeb].Site.WebApplication.AlternateUrls[0].IncomingUrl

or (longer and resulting in an URL with trailing slash):

[current SPWeb].Site.WebApplication.AlternateUrls[0].Uri.AbsoluteUri

If you want to get all of the web applications on a machine you can get this collection:

Microsoft.SharePoint.Administration.SPWebService.ContentService.WebApplications

For good measure, here is how you get the administrative web application(s):

Microsoft.SharePoint.Administration.SPWebService.AdministrationService.WebApplications

By using these approaches you can go a long way towards hard coding site collection urls into your code base.

Careful!

Although the first item in the WebApplication.Sites collection is usually the root site collection, it is not guaranteed to be item zero [0] if you happen to delete and recreate the root site collection after other site collections have been created. A more reliable way is to reference the site collection using the root URL like this.

WebApplication.Sites["/"]

Also, SharePoint timer jobs execute within the context of the web application. So, for a timer job:

using (SPSite site = this.WebApplication.Sites["/"])
{
}

This will take you to the home page in whatever site or subsite you are in. Rather than the root site home page.

SPContext.Current.Web.Url;