I have a Silverlight App that calls my WCF service to get a list of the Time zones from the server. All Time zones are retrieved in the function on the server but I need to know how to pass these back to Silverlight.
My call on the server is below but I think I need to somehow serialize the TimeZoneInfo as a Know Type before I can pass it back. This is the point where I am stuck.
Please can someone help on this?
Public Function GetTimezones() As ReadOnlyCollection(Of TimeZoneInfo) Implements ITimezoneService.GetTimezones
Dim timeZones As ReadOnlyCollection(Of TimeZoneInfo) = TimeZoneInfo.GetSystemTimeZones()
Return timeZones
End Function
See this http://social.msdn.microsoft.com/Forums/en/wcf/thread/f164f185-ae18-4775-a2ff-a814813d262d for a list of known types to add to allow TimeZoneInfo to be serialized.
This will work for the full framework but I don't really recommended it, I would rather use either the ID, or the built-in string serialization as proposed in c# TimeZoneInfo serialization.
On the contrary, the Silverlight framework has its own lightweight version of TimeZoneInfo and thus won't be able to deserialize the TimeZoneInfo serialized by the full framework (since it's not the same type definition).
You should also note that, by default security parameter Silverlight has only access to UTC and Local (Silverlight client running machine locale) TimeZoneInfo, and that to use other time zones, you need to run Silverlight with elevated privileges because timezone information is registry based. See silverlight Time Zone converting and http://forums.silverlight.net/t/186363.aspx/1.
In the end some did rewrite whole or part of the TimeZoneInfo class in their own Silverlight application (we had to too). See http://forums.silverlight.net/t/165067.aspx/1.
Silverlight doesn't have yet support for more than local to UTC or UTC to local time zone conversion natively.
Related
seems that Portable Class Library does not support PerSession (Wshttpbinding) required for this.
Is there any work around for this?
i have xamarin forms application (server client) that users can connect to their own database and get or update data.
once the user provide his username and password some information must be stored to their sessions like database connection string and when data request from user then the appropriate connection string that is stored to his session will be used for that database and send the data back.
otherwise without persession i have to pass on every function the connection string from the client.
how can i avoid this? Portable Class Library does not support wshttpbinding and therefore i cannot use PerSession
any help?
Too much Headache
The obstacles are too much for anyone working with the following combination
Xamarin Forms
PCL (Portable Class Libray)
WCF
IClientMessageInspector
The Problem:
I was need to have a multi client application that each one can connect to his own database ( same schema all )
For this purpose i was looking to store some information at a session level like (Connection String,User Information) so when a method called to know from which database i will retreive the data .
Problem # 1 ( took me 5 days to understand and realized)
that Sessions cannot be worked with PCL ( WCF PerSession) why? Because PerSession Needs WsHttpBinding but PCL Does not support WsHttpBinding only BasicHttp
Problem # 2 (took me 3 days to understand why is not working)
Then i saw many posts here and there about implementing IClientMessageInspector (see examples online how to implement IClientMessageInspector it's easy) so every time a client request a call to send some extra info to the server together with the call in my case was the connectionString. Here i was getting an exception that
NotImplementedException. Why? because of this BUG in MONO
https://bugzilla.xamarin.com/show_bug.cgi?id=40064
in simple words
When creating a WCF client in a PCL (targetting .NET Core) you must use EndpointBehaviors and not Behaviors. This works fine in a Windows RT application, but Mono has not implemented this so produces NotImplementedException in Android and iOS.
The answer is on the link above by another reply from someone else and i thank him for that .
In simple words
Instead of
MyService.Endpoint.EndpointBehaviors(New MyBehavior)
Use
Dim prop = MyService.Endpoint.GetType.GetTypeInfo.GetDeclaredProperty("Behaviors")
Dim obj = CType(prop.GetValue(MyService.Endpoint), KeyedCollection(Of Type, IEndpointBehavior))
obj.Add(New Behavior)
and instead of
clientRuntime.ClientMessageInspectors.Add(New MyInspector)
Use
Public Sub ApplyClientBehavior(endpoint As ServiceEndpoint, clientRuntime As ClientRuntime) Implements IEndpointBehavior.ApplyClientBehavior
Dim prop = clientRuntime.GetType.GetTypeInfo.GetDeclaredProperty("MessageInspectors")
Dim obj = CType(prop.GetValue(clientRuntime), ICollection(Of IClientMessageInspector))
obj.Add(New MyInspector)
End Sub
No changes needed to the configuration file
Hope this help someday someone.
I am using WCF Web API Preview 6 with its inbuilt Test Client to request a resource by Id. The object returns with all its data except for the ‘CreateDate’ and ‘LastModifiedDate’ properties which are of type DateTimeOffset and are empty. I have tried setting the values manually by calling DateTimeOffset.UtcNow and DateTimeOffset.Now and although the values are set on the object they never make it through to the other end in the response.
I have also tested this by changing my property types to DateTime and manually setting their values by using DateTime.Now and everything works fine and I get what looks like a DateTimeOffset value.
<CreateDate>2011-12-13T16:15:47.4269538+00:00</CreateDate>
<LastModifiedDate>2011-12-13T16:15:47.4269538+00:00</LastModifiedDate>
Does anybody know if there is a problem with the use of the DateTimeOffset type in Preview 6 or is it something I am doing wrong? I have had a similar problem with filtering the fields using oData (see SO question)
I have also submitted this bug report to the WCF Web API codeplex site on the filtering issue. However that was over two weeks ago and haven’t had any response.
After many hours of testing and debugging I am running out of options on this one! So if anybody out there can provide me with some helpful hints it would be much appreciated.
It's not a Web API issue, it's Microsoft serialization issue. The XmlSerializer does not handle DateTimeOffset. I believe it has the same issue with TimeSpan.
Just implement IXMLSerializable on your object and handle it yourself.
See here How can I XML Serialize a DateTimeOffset Property?
Hey, can anybody confirm the following scenario will work:
I am developing a 3-tier application in .NET 4.0: Winforms Client, aspx server and SQL 2008 database.
The server communicates with the SQL 2008 database by means of Entity Framework 4.0, and returns the entities in forms of STE's (in a separate assembly) to the client application over WCF.
Now I want to execute a stored procedure on the SQL server, which will return me a custom shaped dataformat (not a 1:1 mapping with an entity). I read that I could use complex types to hold the data this will return to me.
Now the question: will this complex type be serializable over WCF so the client can work with it too ? I suppose it is, but cannot seem to find a closing answer anywhere, and I wanna be sure before I proceed with my coding.
Thx !
TJ
Anything that can be represented in an XML Schema can be serialized and thus sent across the wire using WCF.
This includes all .NET basic primitive types like int, double, string, DateTime and any classes built from those.
Things that won't work are for instance:
any .NET specifics (like Exception, generics, ...) - remember, WCF is designed to be interoperable, not just between two .NET clients
anything with inherent behavior (like a Dictionary)
If you return complex types to the wcf service or if you return an entity whose one of the property is of complex type, self tracking entity would have no problems. However if you are using RIA services, the complex types is not supported.
I have been writing web services for about a year now and it seems that the process I use to get data from the Database all the way to display to the user and back again has some inefficiencies.
The purpose of this question is to make sure that I am following best practices and not just adding extra work in.
Here is the path for data from the DB, to the end user and back.
Service gets it from the database into a Data Access Layer (DAL) object.
Service Converts it to a DataContract to send to the client.
Client gets the DataContract and converts it to a client side object
Client displays the object / the user makes changes / objects are added
Client converts the client side object to a DataContact and sends it to the Service
Service recives the DataContract and converts it to a Data Access Layer object.
Service updates the Database with the changes/new objects.
If you were keeping track the object is converted 4 times (DAL->Contract->Client Object->Contract->DAL). That seems like a lot of conversions when your app starts to scale out it's data.
Is this the "Best" way to do this? Am I missing something?
In case it matters, I am using Visual Studio 2008, WCF, LinqToSQL and Windows Mobile 5.0 (NETCF).
You may be missing the issue of what happens if you reduce the number of conversions (that is, if you couple the layers more tightly together).
The service could directly return a DAL object. The problem is that DAL objects are likely to contain data that is about the fact that they are DAL objects, and not about the data they carry. For instance, LINQ to SQL classes derive from base classes that contain LINQ to SQL functionality - this base class data is not required on the client, and should not be sent.
The client could directly use the DAL object sent back from the server. But that requires the client and server use the same platform - .NET, for instance. They would also have to use compatible versions of .NET, so that the client can use the server-side DAL object.
The client could now display the DAL object however it likes, assuming it doesn't need client-side interfaces like INotifyPropertyChanged, The server doesn't need such code to run, but the client might need it for data binding and validation.
Note that each layer contributes its own requirements. By keeping these requirements independent, the code is easier to design and maintain. Yes, you have to do some copying of data, but that's cheap compared to the cost of maintaining code that has to do four different things at the same time.
I have a Windows forms project and a Web Service project in my solution, and I'm trying to call the web service and return a customer object as the result. The problem is that when I try to receive the return object, I get an error that it can't convert it. For example, here is the signature for my webservice:
Public Function GetDriverByID(ByVal DriverID As Integer) As Driver
And here is the code I'm using to call it:
Dim d As Driver = mywebserviceinstance.GetDriverByID(1)
But I receive this compile-time error (wsDrivers is the name of the web reference I've added to my form project): "Value of type ProjectNamespace.Common.wsDrivers.Driver cannot be converted to ProjectNamespace.Common.Driver"
This "Common" namespace contains the Driver class, and I'm not sure why the return class from the web service isn't just a generic "Driver", but is instead a "wsDrivers.Driver", and I can't convert it back. Anybody know how I can deal with this type mismatch?
EDIT: Thanks for the explanations - this actually makes it clear what it's doing. However, is there any way that I can force it to use the actual type instead of the proxy (or, rather, is there any way to convert between the "real" instance and the "proxy" instance), or do I have to serialize the properties before I send them over the wire, and then manually de-serialize the return values?
This is actually pretty common. What's happening is that the Web Service has defined in it the definitions of all the types used in the web service. When you add a reference to that web service, it auto-generates a proxy type in a sub namespace of your namespace. That is what is being returned by your web service when you call it.
However, you probably are also referencing the same library that the web service does seperately that contains the same type. That is the type that is expected when you Dim Driver. That's why there is a mismatch.
The web service reference in a VB.NET or C# project can reference any type of web service and is not limited to those provided by ASP.NET. That is why Visual Studio creates proxy classes for each object which can be retrieved from the web service.