In my silverlight light apps im normally connecting to a ASMX or WCF web service.
I was wonder what is the best way of holding the url in the app of where the soap client should be looking at.
This is fine in debug because it just sort of knows, but in release and depending where its using an ip or it swaps production servers i keep getting tripped up.
I would love there to be some sort of client config bit like web config
Your service endpoints can go in to a ServiceReferences.ClientConfig file. This is then an XML file and can be changed at any point as needed; ie..at deployment, etc...
You can have client configuration by using Isolated Storage.
You work with Key/Value pairs as in this example from the linked page:
// Create an instance of IsolatedStorageSettings.
private IsolatedStorageSettings userSettings =
IsolatedStorageSettings.ApplicationSettings;
// Add a key and its value.
userSettings.Add("userImage", "BlueHills.jpg");
// Remove the setting.
userSettings.Remove("userImage");
So you can have the value as your URL - just choose a suitable key.
Related
I have to consume some service on ESB which has addresses:
for dev env: http://esbdev.com:11111/ws/ir.channel.aaa.pub.ws:ConsumeMeV1
for test env: https://esbtest.com:22222/ws/ir.channel.aaa.ws:DoAmazingCalc
Functionality is the same.
Can I somehow have only one common code (to rule them all) in c# generated from WSDL and manipulate to which env I’m connecting by some config?
And can i switch freely between http on dev and https on test environment?
Now I’m calling it on dev like:
using (ConsumeMeV1_PortTypeClient client = new ConsumeMeV1_PortTypeClient(this.EsbEndpointBinding, this.EsbEndpointAddress))
But there is dev name hardcoded - how should i map ConsumeMeV1 to DoAmazingCalc on test?
On test I'm calling it like:
using (DoAmazingCalc_PortTypeClient client = new DoAmazingCalc_PortTypeClient(this.EsbEndpointBinding, this.EsbEndpointAddress))
Can I generate common clases like:
using (BestServiceNameClient client = new BestServiceNameClient(this.EsbEndpointBinding, this.EsbEndpointAddress))
The best option for me is to get endpoint/names config from database and inject to clinet class - but how?
Ok, I know where the minuses come from.
No part of the address matters as long as the functionality underneath it does not change. So both generated classes will allow you to use them with each of the given addresses. I note that these obvious things are like that only when you know about it, so I'm sorry that no one even wrote a word about it.
However, when it comes to https, it depends on the BasicHttpBinding.Security.Mode settings. You can set Transport for https and TransportCredentialOnly for http. The corresponding value can be saved and retrieved from the database or other configuration together with the user and password.
I use the above with the setting:
BasicHttpBinding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Basic;
I've got a windows service coded in c#, with a config file:
ProcessingService.exe
ProcessingService.exe.config
Its got a webservice endpoint address in it. This initially went in with the wrong address, so I stopped the service, changed the config file and restarted, but the service is still hitting the original URL.
I then restarted the entire server and still the wrong URL is being accessed.
We have a load of corporate rules about new install versions meaning my turnaround time for compiling a new service and getting it installed will be measured in weeks, leaving the URL broken for that entire time. Is there a way to force the config to update?
(Yes, I've triple checked that the config file is now correct!)
In response to the request for the service setup code, I simply do (class names changed):
WebserviceNamespace.ServiceClass client = new WebserviceNamespace.ServiceClass();
The service config shows the original URL, and I'm using a transformed app.config process to overwrite the new URL in the new config file (again, I've triple checked this). I am generating the service classes as internal though, could this be something to do with it?
OK, so I've now tried installing the service on another computer, stopping it, changing the URL in the config to "nevergonnahappen" and restarted. Requests to that now fail on an invalid url. So it must be something to do with our live server specifically...
make sure that your services is pulling the url from config file.
make sure the services is not cached the url somewhere else after getting it(maybe in memory or file or database).
make sure you pointed to correct folder for the config file, perhaps do a wild search with agent ransack, any other place that is still writing broken url and your services in fact is pointing into it.
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 move 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
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
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;
I have developped a custom WCF Web Service within a SharePoint 2010 Visual Studio empty project.
My web service is working well. The problem is related to the size of the request I can send to this web service. I have realized that is something around 300Kb. If I go bigger than that, the service/client is sending me an exception.
I've looked around on the web and see that the MaxReceivedMessageSize setting may be my solution. I've tried using a FeatureActivated method to set this information using this kind of request:
// increase maximum size of requests to this web service: http://msdn.microsoft.com/en-us/library/ff599489.aspx
SPWebService contentService = SPWebService.ContentService;
contentService.ClientRequestServiceSettings.MaxReceivedMessageSize = -1;
SPWcfServiceSettings csomWcfSettings = new SPWcfServiceSettings();
csomWcfSettings.MaxReceivedMessageSize = 10485760; // 10MB
contentService.WcfServiceSettings["PT-SP-P2S-DocumentCreator.svc"] = csomWcfSettings;
contentService.Update(); // access denied thrown here!
With that code, I have an Access denied (I'm actually the Site Collection Administrator).
I also know that this parameter may be set in the app.config of web service host but, in SharePoint, where to I need to change this parameter.
I think you should make this change in the web.config file of the Web Application in which the feature is activated. SharePoint provides APIs to make web.config changes. In fact, using APIs to make changes to your web.config is preferred option because SharePoint uses Timer Job and makes same updates to all Web Front End servers in your environment. There are 2 ways to make changes to web.config as described here:
http://msdn.microsoft.com/en-us/library/ms460914.aspx
In your case, since you want to make the change only when your feature is activated, you would take the API approach as documented here: http://msdn.microsoft.com/en-us/library/bb861909.aspx
Okay, simple situation: I'm writing a simple console application which connects to a SOAP web service. I've imported a SOAP Service reference and as a result, my application has a default endpoint build into it's app.config file.
The web service, however, can run on multiple servers and the URL to the proper web service is passed through the commandline parameters of my application. I can read the URL, but how do I connect the web service to this custom URL?
(It should be very simple, in my opinion. It's something I'm overlooking.)
Is this using an auto-generated class deriving from SoapHttpClientProtocol? If so, just set the Url property when you create an instance of the class.
Well, .NET can provide some very useless error messages sometimes. In IIS, the service was configured to AutoDetect cookieless mode. As a result, I had to append "?AspxAutoDetectCookieSupport=1" to the URL. Although that would fix the problem, it was just easier to go to the IIS console, open the properties of the service, go to the ASP.NET tab page, click the "Edit configuration" button, to to "State Management" in the newly popped up screen and change "Cookieless mode" into something other than "AutoDetect"...
Excuse me. Dumb error. Am going to hit myself on the head a few times for this. ;-)
As Jon said, you set the Url, as in:
Namespace.ClassName nwe = new Namespace.ClassName();
nwe.Url = "http://localhost/MyURL/site.asmx";