I am experiencing this weirdest problem ever.
I have EF entities that we are passing between a client and a server via WCF.
When i am serializing them manually as follows:
var xmlSerializer = new DataContractSerializer(typeof(T), null, int.MaxValue, false, true, null);
var textWriter = new StringWriter();
var xmlTextWriter = new XmlTextWriter(textWriter);
xmlSerializer.WriteObject(xmlTextWriter, source);
return textWriter.ToString();
Everything is ok.
But when they are being transferred over the wcf wire i get stackoverflow exception.
I tried debugging the source code, but since it is stackoverflow all the locals are unavailable.
I ran out of ideas, if it serializes manually - what could be different in the WCF that would cause it to stackoverflow?
Related
I am porting a library to a PCL and have to find a solution for managing HTTP request credentials. I took away concrete credentials classes like CredentialCache (that is not portable) and is now only using ICredentials, so client applications may create proper credentials and just send an interface reference.
However one thing still needs to be resolved. On some platforms HttpWebRequest has a neat PreAuthenticate property that takes care of initial handshaking. Without it the client needs to catch and repsponds to 401 responses. But PreAuthenticate is not a part of most of PCL profiles, and I wonder if there is any resolution to that or the client will need to implement replacement logic itself (which is silly since this is a standard piece of code).
Thanks in advance
You will need to write the code to handle this yourself. An API will only be portable if it is available on all of the platforms you target. In this case PreAuthenticate was a new API in .NET 4.5 and Windows Store apps, so it won't be available in a Portable Class Library if you are targeting any other platforms (ie .NET 4, Silverlight, or Windows Phone).
I'm having the same problem. I tried to set Credentials to a single NetworkCredental(user, pass), but it doesn't work in WinRT, although it works in Windoes Phone. So far the only way to make it work in WinRT is to create the CredentialCache by reflection.
var credCacheType = Type.GetType("System.Net.CredentialCache, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089");
var credCache = credCacheType.GetConstructor(new Type[0]).Invoke(new object[0]);
var addMethod = credCacheType.GetMethod("Add", new Type[] { typeof(Uri), typeof(string), typeof(NetworkCredential) });
addMethod.Invoke(credCache, new object[] { new Uri(_server), "Digest", Credential });
request.Credentials = (ICredentials)credCache;
PreAuthenticate can be set using HttpClienHandler that HttpClient accepts as a parameter constructor, e.g.:
HttpClientHandler handler = new HttpClientHandler()
{
UseDefaultCredentials = true,
PreAuthenticate = true
};
HttpClient client = new HttpClient(handler);
I am using System.Net.Http.HttpClient to post a sequence of requests from a console application to a REST API and to deserialize the JSON responses into strongly-typed objects. My implementation is like this:
using (var client = new HttpClient())
{
var content = new StringContent(data, Encoding.UTF8, "text/html");
var response = client.PostAsync(url, content).Result;
response.EnsureSuccessStatusCode();
return response.Content.ReadAsAsync<MyClass>().Result;
}
However, I am experiencing a problem very similar to one described in this question, whereby everything works fine when the requests are routed via Fiddler, but it hangs after the 4th or 5th request when Fiddler is disabled.
If the cause of the problem is the same, I assume I need to do something more with HttpClient to get it to fully release its resources after each request but I am unable to find any code samples that show how to do this.
Hoping somebody can point me in the right direction.
Many thanks,
Tim
You are not disposing of the HttpResponseMessage object. This can leave open streams with the server, and after some quota of streams with an individual server is filled, no more requests will be sent.
using (var client = new HttpClient())
{
var content = new StringContent(data, Encoding.UTF8, "text/html");
using(var response = client.PostAsync(url, content).Result)
{
response.EnsureSuccessStatusCode();
return response.Content.ReadAsAsync<MyClass>().Result;
}
}
I'm trying to migrate an existing application to Mono (v2.10.2).
Therefore I created a test WCF service with BasicHttpBinding and message security. The client works perfectly with .NET, but when running with Mono it fails.
The client factory is instantiated as follows:
//var certificate = CertificateUtil.GetCertificate(StoreLocation.LocalMachine,
// StoreName.My, X509FindType.FindBySubjectDistinguishedName, CertName, true);
var certificate = new X509Certificate2("certificate.pfx", "password");
var binding = new BasicHttpBinding();
binding.Security.Mode = BasicHttpSecurityMode.Message;
binding.Security.Message.ClientCredentialType = BasicHttpMessageCredentialType.Certificate;
var epa = new EndpointAddress(
new Uri("http://localhost:53076/Service1.svc"),
new X509CertificateEndpointIdentity(certificate));
var factory = new ChannelFactory<IService1>(binding, epa);
factory.Credentials.ServiceCertificate.DefaultCertificate = certificate;
factory.Credentials.ServiceCertificate.Authentication.CertificateValidationMode = X509CertificateValidationMode.None;
factory.Credentials.ServiceCertificate.Authentication.RevocationMode = X509RevocationMode.NoCheck;
factory.Credentials.ClientCertificate.Certificate = certificate;
var client = factory.CreateChannel();
In Mono the application fails within CreateChannel throwing the exception:
System.InvalidOperationException: The binding does not support any of the channel types that the contract 'IService1' allows.
I debugged into the Mono source code and found out that the problem is that AsymmetricSecurityBindingElement.InitiatorTokenParameter == null.
I'm new to Mono, maybe you could point me to a documentation/tutorial which covers this topic.
UPDATE:
With the aid of konrad.kruczynski the certificate object has a private key now. The exception is still the same. So this is not a certificate store issue.
Yes, certificates created on Windows usually does not contain private key. They can be found in some kind of cache. You should be able to create certificate with private key using this instruction. X509Certificate2 should consume the file without problems. You can also try procedure described here. In case of any problems just write.
It is also worth adding, that certificates created such way on Linux works perfectly on Windows too.
Update:
I'm not sure whether I understood your comment correctly. You can load PFX certificate using code like that:
var myCert = new X509Certificate2("filename.pfx", "password");
Given certficate contained key, it worked for me.
I am looking to write some integration tests to compare the WSDL generated by WCF services against previous (and published) versions. This is to ensure the service contracts don't differ from time of release.
I would like my tests to be self contained and not rely on any external resources such as hosting on IIS.
I am thinking that I could recreate my IIS hosting environment within the test with something like...
using (ServiceHost host = new ServiceHost(typeof(NSTest.HelloNS), new Uri("http://localhost:8000/Omega")))
{
host.AddServiceEndpoint(typeof(NSTest.IMy_NS), new BasicHttpBinding(), "Primary");
ServiceMetadataBehavior behavior = new ServiceMetadataBehavior();
behavior.HttpGetEnabled = true;
host.Description.Behaviors.Add(behavior);
host.AddServiceEndpoint(typeof(IMetadataExchange), MetadataExchangeBindings.CreateMexHttpBinding(), "mex");
host.Open();
}
Does anyone else have any better ideas?
EDIT:
Obviously this code is simply creating a host for the service, I am still missing the client code to obtain the WSDL definition.
Just use WebClient and ?wsdl sufix in URL
using (ServiceHost host = new ServiceHost(typeof(NSTest.HelloNS),
new Uri("http://localhost:8000/Omega")))
{
host.AddServiceEndpoint(typeof(NSTest.IMy_NS), new BasicHttpBinding(), "Primary");
ServiceMetadataBehavior behavior = new ServiceMetadataBehavior();
behavior.HttpGetEnabled = true;
host.Description.Behaviors.Add(behavior);
host.AddServiceEndpoint(typeof(IMetadataExchange), MetadataExchangeBindings.CreateMexHttpBinding(), "mex");
host.Open();
string wsdl = null;
using (WebClient wc = new WebClient())
{
using (var stream = wc.OpenRead("localhost:8000/Omega?wsdl"))
{
using (var sr = new StreamReader(stream))
{
wsdl = sr.ReadToEnd();
}
}
}
Console.Write(wsdl);
}
Check out the WsdlExporter on MSDN. Its used to generate wsdl in WCF.
You could also have a look in svcutil with reflector to see how its generating the wsdl information, since the tool can generate wsdl from a dll-file.
Another way to do your comparison would be to use the svcutil tool to generate the wsdl and compare it to a saved/baselined version of the service. Run the svcutil in your test and verify the output against the old files. Not really self-contained test since you'll need the svcutil...
How about something like this?
Creating a WSDL using C#
One thing you need to be careful of is to compare the entire WSDL. WCF breaks up WSDLs, unlike classic web services (asmx) WSDLs. This means that the core of the info is on the ?WSDL page, however, there will also be multiple XSDs (.svc?XSD=XSD0, 1, 2 ...) and possibly multiple WSDL pages (?WSDL and ?WSDL=WSDL0 for example).
One way to accomplish this would be to generate a webrequest to get the data from the root wsdl. Then you can search the WSDL for anything like (yourServicename).svc?WSDL=WSLD0 and (yourServicename)?XSD=XSD0 and so on, spawning additional webrequests for each WSDL and XSD.
You might be better off using SoapUI to test the WSDL rather than relying on NUnit directly.
If you want to call SoapUI from NUnit, it's possible, but a little clunky. See http://enthusiasm.soapui.org/forum/viewtopic.php?f=2&t=15 for more information.
Same answer translated to VB
Using host = New ServiceHost(GetType(MyHelloWorldWcfLib.HelloWorldServer), New Uri("http://localhost:8000/Omega"))
host.AddServiceEndpoint(GetType(MyHelloWorldWcfLib.IHelloWorld), New BasicHttpBinding(), "Primary")
Dim behavior = New ServiceMetadataBehavior()
behavior.HttpGetEnabled = True
host.Description.Behaviors.Add(behavior)
host.AddServiceEndpoint(GetType(IMetadataExchange), MetadataExchangeBindings.CreateMexHttpBinding(), "mex")
host.Open()
Dim wsdl As String = Nothing
Using wc = New System.Net.WebClient()
Using stream = wc.OpenRead("http://localhost:8000/Omega?wsdl")
Using sr = New IO.StreamReader(stream)
wsdl = sr.ReadToEnd()
End Using
End Using
End Using
Console.Write(wsdl)
End Using
While trying to build a client-server WCF application in Mono we ran into some issues.
Reducing it to just a bare example we found that the service only accepts one client at a time. If another client attempts to connect, it hangs until the first one disconnects.
Simply changing to BasicHttpBinding fixes it but we need NetTcpBinding for duplex communication. Also the problem does not appear if compiled under MS .NET.
EDIT: I doubt (and hope not) that Mono doesn't support what I'm trying to do. Mono code usually throws NotImplementedExceptions in such cases as far as I noticed. I am using Mono v2.6.4
This is how the service is opened in our basic scenario:
public static void Main (string[] args)
{
var binding = new NetTcpBinding ();
binding.Security.Mode = SecurityMode.None;
var address = new Uri ("net.tcp://localhost:8080");
var host = new ServiceHost (typeof(Hello));
host.AddServiceEndpoint (typeof(IHello), binding, address);
ServiceThrottlingBehavior behavior = new ServiceThrottlingBehavior ()
{
MaxConcurrentCalls = 100,
MaxConcurrentSessions = 100,
MaxConcurrentInstances = 100
};
host.Description.Behaviors.Add (behavior);
host.Open ();
Console.ReadLine ();
host.Close ();
}
The client channel is obtained like this:
var binding = new NetTcpBinding ();
binding.Security.Mode = SecurityMode.None;
var address = new EndpointAddress ("net.tcp://localhost:8080/");
var client = new ChannelFactory<IHello> (binding, address).CreateChannel ();
As far as I know this is a Simplex connection, isn't it?
The contract is simply:
[ServiceContract]
public interface IHello
{
[OperationContract]
string Greet (string name);
}
Service implementation has no ServiceModel tags or attributes.
I'll update with details as required.
I've played around with this a bit, and it definitely looks like a Mono bug.
I'm porting a WCF application to run in Mono at the moment. I had played with some NetTcpBinding stuff, but I hadn't tried this scenario (multiple connections to a Mono-hosted service host). However now I try it out, I'm able to reproduce - both in 2.6 and the latest daily package.
It does work in .NET, however. Any difference in behavior between Mono and .NET is classed as a bug. You should log it on Bugzilla with a test case, I would also post in the Mono newslist.
Good luck.
Definately a bug. I'm wondering if there was a version it was working correctly...
I've posted it at Novell Bugzilla, if you are interested in its progress.