 |
|
 |
Hi, thanks for the tip.
Actuallt Visual Studio 2010 is set to Dinamyc by default =)
Hideki
|
|
|
|
 |
|
 |
I am not getting the code on Forum for article: "How to make your Web Reference proxy URL dynamic"
|
|
|
|
 |
|
|
 |
|
|
 |
|
 |
Hi,
Does it work with Visual Studio 2008?? I do not see the "Show All Files" option at all in Visual Studio 2008 within Solution explorer.
Thanks!
|
|
|
|
 |
|
 |
This fixed exactly the problem I was having.
|
|
|
|
 |
|
 |
I am checking this out for a Windows Forms application. It seems the same principles hold, apart from the fact there is no web.config file. Found the (dynamic) settings in the app.config file though; <applicationsettings> <yourapp.my.mysettings> <setting name="Your_Service" serializeas="String"> <value>http://name.doamain.com/YourService/Service.asmx</value> </setting> </yourapp.my.mysettings> </applicationsettings>
|
|
|
|
 |
|
 |
It seems in VS 2003 if you use dynamic URL then you can't use the WSE types.
Means If your project is configured to use WSE 2.0 and you add a web reference and call it AuctionServer. In AuctionServer you will always find 2 types: the "normal" type and the WSE type. Let's say you have a type AuctionServer.Auction then you also will have a AuctionServer.AuctionWSE.
This will let you use the DIME functionality in WSE 2.0 for example.
This AuctionWSE type will no longer be available if you use dynamic URL. Only AuctionServer.Auction will be available but not the WSE.
DOes anyone know why this is and how you could work it around?
|
|
|
|
 |
|
 |
Great! Simple but very important
modified on Thursday, May 1, 2008 12:31 PM
|
|
|
|
 |
|
 |
But the good question is : how to make dll work with config file without recompiling?
|
|
|
|
 |
|
 |
in VS05 WinForm projects and ClassLibrary projects(including new Web Applicaiton Projects) the proxy is generated to use the <applicationSettings> section.
The issue is described here[^]
Michael Freidgeim.
Blog: http://geekswithblogs.net/mnf/
-- modified at 23:10 Sunday 7th May, 2006
|
|
|
|
 |
|
 |
If you truely want the URL to be code dynamic, simply overload the Web Service constructor in the Web Services, Reference.cs. It is just a file built by a tool anyway and there is nothing saying you can't alter it. Either get to the constructor by seeking it out in the manner that the author suggests, or even easier is to create an instance of the web service and right click -> "Go To Definition" on the constructor to go there directly in VS.NET.
Hence the code:
public MyWebService(string url)
{
if (url != null)
{
this.Url = url;
}
else
{
this.Url = "http://soap.junto.co.uk/feed/soap?Service=MyWebService";
}
}
When you instantiate the service you have to pass the URL.
MyWebService ws = new MyWebService("http://soap.junto.de/feed/soap?Service=DeutschService");
Easy peasy lemon squeasy, and really useful if you are dealing with international sites in different languages and formats.
|
|
|
|
 |
|
 |
Yehhhh.
bass4g0d
|
|
|
|
 |
|
 |
And after you update reference to web service -> you lose that code...
|
|
|
|
 |
|
 |
The trick here is to create a new class file (I've called mine QueryService.cs) with the following code. This way even if Visual Studio re-generates it's own code, you're partial class modifications will remain intact
using System;
using System.Collections.Generic;
using System.Text;
namespace Sharepoint.SharepointServer
{
using System;
using System.Web.Services;
using System.Diagnostics;
using System.Web.Services.Protocols;
using System.ComponentModel;
using System.Xml.Serialization;
using System.Data;
public partial class QueryService : System.Web.Services.Protocols.SoapHttpClientProtocol
{
|
|
|
|
 |
|
 |
where I should put that code? thx..
modified 30 Apr '12.
|
|
|
|
 |
|
 |
I just discovered that, in a WinForms app at least, when VS refreshes the reference it rewrites the url in app.config -- so I *still* have to change it manually
|
|
|
|
 |
|
 |
Yeah? This is a fact though. You do have to reconfigure the config file url based on the url the web service was originally compiled though when you change code. However you can beat this by writing some ant scripts to handle your changes and adding the script call as a VS add in (via an exe to call the script). This article is mainly to solve the problem that has the URL embedded in compiled code and you can't change environments (Test/QA/Staging) or servers without a recompile. If you change something, like in any other code base, you are going to have to fix stuff, unless you have it set up differently.
Chris Lasater
http://www.geocities.com/lasaterconsult
|
|
|
|
 |
|
 |
I agree, I was just hoping that VS would be smart enough to realize if it were updating the web service from the same source _and_ I had overriden the URL it would keep the changes... As it is, I have to remember to fix them before I give the app out for testing (Not a big deal, and I will eventually make a NAnt build script to deal with it, but it would have been nice...)
|
|
|
|
 |
|
 |
If it fine until someone refreshes the web reference and reference file is recreated.
You could set the URL of the service when you declare the webservice using a method. That way refreshing the reference won't make a difference. (There is a reason why you can't see the reference file by default)
WebService.Url = GetWebServiceURLFromConfig();
-- modified at 4:24 Thursday 1st December, 2005
|
|
|
|
 |
|
 |
Re-read the article. He isn't changing the reference file, Visual Studio is, and in much the same way as your example.
|
|
|
|
 |
|
 |
Why not create a proxy from the web service proxy . That way you dont have a hard reference in your project to the service and it put the url property in the class. Thus making your assembly truely dynamic.
|
|
|
|
 |
|
 |
I don't think making proxies for proxies is time well spent. The solution presented makes the assembly "truly dynamic" as you say w/o the extra plumbing.
|
|
|
|
 |
|
 |
When you add a web service in Visual Studio it uses the proxy tool to create the proxy and place it in your project. Sometimes you cannot add a webservice directly into Visual Studio. Using the wsdl tool directly gives you more control of the proxy class.
I wasnt saying in addition too. I was saying instead of.
|
|
|
|
 |
|
 |
1- En ocasiones debe modificarse la clase proxy para incluir algunos aspectos en el llamado (como ejemplo las credenciales al WS, que también se pueden pasar en cada llamado, pero considero que no, pues es un tema para encapsularse e independizar al cliente de esto)... en ocasiones debe re-crearse la referencia (por esas situaciones "que ocurren" cuando se trabaja en proyectos en VS) y la clase proxy es generada nuevamente pudiendo sobreescribir código.
2- El key siempre es generado en el config del cliente que referencia el WS. ¿qué pasa cuando el cliente es una dll?... que el parámetro no será usado y manualmente debe copiarse en el config de la aplicación que inicia el AppDomain (ejemplo: la app web que llama a la dll que consume el ws... el key debe crearse en el config de la app web)... y deberá parametrizarse por cada cliente que lo consuma
3- Por último y "ya por sólo gusto", el nombre del key que se emplea en el código y que es autogenerado en el config, no siempre es intuitivo o no se adapta a un estándar del proyecto... Un valor como:
podría remplazarse con: y ser más claro para quien use el parámetro "wsSeguridad" en los componentes
----------------------------
|
|
|
|
 |