Integer value is lost in web service call - c#

I have an application that makes a web service call to get the URL of an MSI depending on whether the user's computer is 32bit or 64bit.
The call GetURLByOS takes 2 methods (1. string AuthenticationInfo , 2. int osBit). As I'm debugging, I can see the authentication info. The osBit's value is 8 (for 64bit) when calling into the web service. But its value is lost (0) when actually in the web service.
Can someone help me figure out why the integer value is lost?
Update:
I'm attaching to the process. In the client, I see value 8 being passed in. In the web service call, I see 0.
This is a SOAP web service call.
Here's the WSDL code on the client:
[System.Web.Services.Protocols.SoapDocumentMethodAttribute("http://mydomain.com/product/1.0/GetURLByOs", RequestNamespace = "http://mydomain.com/product/1.0", ResponseNamespace = "http://mydomain/product/1.0", Use = System.Web.Services.Description.SoapBindingUse.Literal, ParameterStyle = System.Web.Services.Protocols.SoapParameterStyle.Wrapped)]
public string GetURLByOs(string eTicket, int OsBitType)
{
object[] results = this.Invoke("GetURLByOs", new object[] {
eTicket, OsBitType});
return ((string)(results[0]));
}
Here's the actual web service:
[WebMethod]
public string GetURLByOs(string eTicket, int osBitType)
{
return MyFacade.GetUrl(eTicket, osBitType);
}
BTW, when I change the parameter to type string, it gets passed properly (value "8"). It's only when I pass it as an integer that the value is zeroed out.

I found out what was the problem. On the (client) WSDL code, the parameter is OsBitType. But on the actual web service, the parameter is osBitType. After changing the web service parameter to OsBitType, it's working fine.
Strange thing is, this doesn't occur if the parameter is a string.

For my situation, after update reference of web service, it's working fine.

Related

Xamarin Forms SOAP WebService, how to get data?

I have searched for a few days now and cannot figure this out. I would like to get my results from a WebService. I am using PCL and as far as I can tell we cannot use string as a variable when returning, only void.
WebServiceSoapClient client = new WebServiceSoapClient();
string result = client.SetDriverAvailAsync(varUserid, varPassword, varLocation, varDateTime);
Above is what I'm using to call the method. And the web service was written as such.
[WebMethod]
public string SetDriverAvail(string drivername, string password, string location, string datetime)
{
if (location == "" || datetime == "")
{
return "failed";
}
It does a bunch of other stuff. Then returns "success" or "failed". Bottom line is. When i make my Service Reference for a Portable Form in Xamarin the only methods it makes in the Connection Service are public voids.
If I make a Service Reference in all other projects like ASP Web Page, ect. It builds these methods differently. And does let you return a string.
CONFUSED ... THANKS
This may be a simplistic answer, but I suggest you read Xamarin introduction to web services

Rest to make call to another process just once in entire life cycle

say Rest service got one request which is giving a call to another service (email service),
but when Rest service got another request which is giving a call to email service I want it to skip that step.
also rest service should be intelligent enough to see if email process is being running or stopped if stopped any next request to rest service is allowed to call email service.
Rest Method : -
void SaveDataAndCallEmailService(Data data)
{
cntx.Add(data);
cntx.SaveChanges();
SendEmail();
}
now my query is how to make "SendMail()" method to be called only once only if Email Process is not running.
for e.g. : -
void SaveDataAndCallEmailService(Data data)
{
cntx.Add(data);
cntx.SaveChanges();
if(!EmailProcessIsRunning)
SendEmail();
EmailProcessIsRunning= true;
}
Edit: -
Now, here "EmailProcessIsRunning" is always false, even though I marked it as true.
When server receive second request I found "EmailProcessIsRunning" is false again.
How to persist it's value?
In your code sample EmailProcessIsRunning is not defined anywhere. Makes if more difficult to see if there's a scope issue.
Assuming there's no scope issues, if you want to persist the value saved to EmailProcessIsRunning between requests of on a stateless webapi server you'll need to add a DependecyResolver to your server. Read this for more information http://www.asp.net/web-api/overview/extensibility/using-the-web-api-dependency-resolver
edit: (a simpler answer)
You can add a static property to your class, and set it to true when the process is started.
e.g.
public bool static EmailProcessIsRunning { get; set; }

Parameter lost when calling a dll method using mozilla 1.8.1.18 on DMP

This is a problem that has occurred after a Cisco 4400 DMP upgrade to Mozilla 1.8.1.18 (firmware release 5.3.5).
A C# method uses a command line (QueryString) parameter to invoke a method in a DLL using this variable as a parameter.
Here is the code snippet:
public string Get_Channel_Orientation(int channelId)
{
ChannelService channelService = new ChannelService();
return channelService.GetRootOrientation(channelId);
}
channelId is a QueryString parameter. This has functioned correctly until the browser upgrade.
Now, what happens is the channelId value is always null. If you place a literal instead of the QueryString parameter such as:
return channelService.GetRootOrientation(123);
it works correctly even with the upgraded browser.
And even though it is null when passed to the Service method, if you print out the value of channelId to the console, it is correct (i.e. it is the value passed in the URL)
The situation seems impossible because it is server-side, and should not be affected by the browser version, but there is no other difference I can see between working and non-working cases.

WCF - Object losing it's values when passed to WCF Service

I am new to using WCF Services but have began writing a new project and have ran into this problem. I am also new to programming, so forgive me if wording is incorrect!
I have an object called Profile that I can retrieve on my client from WCF, and that works without problems - using a GetProfile method.
I then wanted to make modifications to the object on the client side and send it back through the WCF service using an UpdateProfile method. At this point, the object always seems to be reinstantiated (therefore overwriting all values to null).
Any help is appreciated.
So the GetProfile method works beautifully.
Make changes to the RAIS_Profile on my client works beautifully
Send the RAIS_Profile back using UpdateProfile and every value in the object is blank once in that method.
Public Function GetProfile(ByVal DocumentNumber As Integer) As RAIS_Profile Implements IRAISAPI.GetProfile
Dim Doc As New RAIS_Profile
'blah
'blah
Return Doc
End Function
Public Function UpdateProfile(ByVal pDoc As RAIS_Profile) As String Implements IRAISAPI.UpdateProfile
Return pDoc.DocumentNumber
End Function
Any help is appreciated!
Look at the service contracts you have, both on client and server. If the parameters aren't precisely named the same way, then you'll encounter this kind of behaviour.
See Here

Why does Request["host"] == "dev.testhost.com:1234" whereas Request.Url.Host == "localhost"

Hi all, I seem to have found a discrepancy when testing ASP.NET applications locally on the built-in web server with Visual Studio 2008 (Cassini).
I've set up a host on my local machine associating dev.testhost.com with 127.0.0.1, since I have an application that needs to change its appearance depending on the host header used to call it.
However, when I request my test application using http://dev.testhost.com:1234/index.aspx, the value of Request.Url.Host is always "localhost". Whereas the value of Request.Headers["host"] is "dev.testhost.com:1234" (as I would expect them both to be).
I'm NOT concerned that the second value includes the port number, but I am mighty confused as to why the HOST NAMES are completely different! Does anyone know if this is a known issue, or by design? Or am I being an idiot?!
I'd rather use Request.Url.Host, since that avoids having to strip out the port number when testing... - Removed due to possibly causing confusion! - Sam
Request.Headers["host"] is the value received from the application that connects to the server, while the other value is the one the server gets when it tries to get the domain name.
The browser uses in the request the domain name entered because that is used in the case of virtual domains. The server reports the one set in the server preferences, or the first one it finds.
EDIT: Looking at the code of Cassini to see if it uses some particular settings, I noticed the following code:
public string RootUrl {
get {
if (_port != 80) {
return "http://localhost:" + _port + _virtualPath;
}
else {
return "http://localhost" + _virtualPath;
}
}
}
//
// Socket listening
//
public void Start() {
try {
_socket = CreateSocketBindAndListen(AddressFamily.InterNetwork, IPAddress.Loopback, _port);
}
catch {
_socket = CreateSocketBindAndListen(AddressFamily.InterNetworkV6, IPAddress.IPv6Loopback, _port);
}
// …
}
The explanation seems to be that Cassini makes explicit reference to localhost, and doesn't try to make a reverse DNS lookup. Differently, it would not use return "http://localhost" + _virtualPath;.
The Request.Headers["host"] is the host as specified in the http header from the browser. (e.g. this is what you'd see if you examined the traffic with Fiddler or HttpWatch)
However, ASP.NET loasds this (and other request info) into a System.Uri instance, which parses the request string into its constituent parts. In this case, "Host" refers to literally the host machine part of the original request (e.g. with the tcp port being in the Port) property.
This System.Uri class is a very useful helper class that takes all the pain out of splitting your request into it's parts, whereas the "Host:" (and for that matter the "GET") from the http header are just raw request data.
Although they both have the same name, they are not meant to be the same thing.
It's a matter of what the w3 specs say versus what the Microsoft Uri.Host property is supposed to contain. The naming does not imply an attempt by MS to provide identical functionality. The function that does include port numbers is Uri.Authority.
With the update you posted, you're still facing the same problem, just examining a different aspect of it. The Uri.Host property is not explicity or implicity stated to perform the same function as the headers that are defined in the w3 specs. In long form, here are some quotes from the Uri.Host MSDN page:
Uri.Host Property
Gets the host component of this instance.
Property Value
Type: System.String
A String that contains the host name. This is usually the DNS host name or IP address of the server.
There's no guarantee that this will match what is in the headers, just that it represents the host name in some form.

Categories