I'm using hessian protocol for communication betwee server (java) and various client applications. Now I started to develop Windows Phone 7 client. I downloaded hessian C# implementation but it does not compile for windows phone 7/silverlight.
Does anyone managed to make it work on WP7/Silverlight? It's looks like there is many thing to be done/changed to make it work, which I'd like to avoid if it has been done by someone already.
Thanks.
What is it that does not compile? I'm guessing that the implementation is probably using sockets. Please keep in mind that Silverlight (and thus, wp7) limits the kinds of network connections you can open ... preferring asynchronous web requests (via the WebRequest class) or WCF services.
Chances are the code you downloaded is having problems with the compact framework version of the network classes available on the phone/silverlight. See this msdn article for more information about the socket support:
http://msdn.microsoft.com/en-us/library/cc296248%28VS.95%29.aspx
If you want to communicate directly between the phone and a server running the hessian protocol the easiest way will probably be to proxy communication via a wcf service running on an asp.net server.
So answer is you have to rewrite hessian C# implementation as Silverlight 4 doesn't have lot of stuff from .net mobile framework, mainly Proxy class.
Related
I am writing a silverlight Line of business application and wanted to use the Subsonic DAL. The Silverlight Project will not allow me to Add the Subsonic reference with the followng error "You can not add the Subsonic.Core.Dll as it was not built against the Silverlight Runtime". I assume that I could create a webservice and add the Subsonic to that, but I would like to just add it to the Silverlight Project. Has anyone done this and if so how. If not is there an easy way to expose the DAL through the Webservice.
You don't want to access your database directly from your silverlight application. This will create a big security hole. Remember that the silverlight client runs on the clients machine and the traffic between the client and the server can easily be tampered with.
For easy access, to a server side API, you can try .NET RIA Services.
To clarify the error message: Silverlight is based on .net, but you can't just run any .net assembly in silverlight. This is because a lot of stuff in normal .net is simplified, not allowed or not supported in client-side silverlight, which makes binary compatibility difficult or even pointless.
I've asked several questions on Silverlight the last day or two (I have no experience with it), and I've had some high-level questions answered. I have another high-level question. How is N-Tier development done with Silverlight? What I am considering is a browser based UI and then a c# back-end containing all the business logic and database code. How would a Silverlight client application communicate with such a back-end sitting on another server? Would it be done via Web service calls, WCF or something else? What is standard practice?
Thanks!
For the projects I've worked on. Typical practice is Silverlight providing a client and then communicating back to the back-end via WCF services.
The business logic is then spread/duplicated across the client and the backend.
You'll want to be looking at the WCF RIA Services for this. In combination with Entity Framework this will approach the sort of thing you need.
The Entity Framework creates model that you can extend and include some business logic.
The Domain Services then allow you to expose access to the model and any other range of operations you need via WCF.
The tooling that RIA Services adds to the Visual Studio will dynamically create in the Silverlight application the client side of this Domain service. There is even a provision for you create C# source that is shared by both by both Silverlight and the server code.
If its Silverlight 3 RIA is a better choice to work with. AnthonyWJones has pointed it right, There is a provision to have a shared Source between Client and Server usually Entities code should be shared in both Client and Server to get full advantage of RIA validation and other stuff.
How can i call a windows service using silver light?
If it's a managed service that's in your control, you could host a WCF service in it for silverlight to communicate with.
Here's how to do that.
Using WCF is, as noted, the simplest solution. An alternative, if you don't want the (substantial) overhead introduced by WCF, is to use sockets, as demonstrated, for instance, here. If you control both sides of the equation, a framework like SocketsLight can take some of the pain out of sockets programming.
Are ActiveX applets as a technology supported by Microsoft dead?
What are the alternatives to ActiveX to create extremely rich internet applications using Microsoft Technologies? (Silverlight does not cut it for me, as it doesnt give me access to serial ports - or does it?)
You can of course still make ActiveX applications, but know that they will only work with Internet Explorer, unless users of other browsers install hosting plugins, that aren't all that good anyway.
In either case, a web application that requires access to a serial port? Are you sure you're not better off with a desktop application instead? A simple refresh and you've cut off that serial port.
Not all applications belong in the browser.
If you want to launch an application via a web browser that can access the serial ports, one option would be to use Java Web Start with JavaFX as the rich interface API, and Java Communications for the serial port access. You could end up with a cross-platform application at the end as well.
Or just write a native application using your favoured Windows toolkit if you absolutely are restricted to using Microsoft tools.
ActiveX as technology is very much alive, and will remain for many years to come. But its usage for Internet is dead. ActiveX is to be only used from within windows stand-alone applications.
ActiveX as of 2015 is a dead technology that even the maker is no longer interested in continuing to use it. Here is something to read.
No, Silverlight is designed from the ground up to be completely sandboxed, no way to bypasss that (thank god).
If you need that kind of access, but are looking for an easy deployment, I would suggest building a Clickonce application.
There are restrictions, because I think by default they are not full trust, but that's the best you will get.
It's also going to be the only easy route if you need printing (unless you are willing to round-trip to a server to generate a PDF file).
If you need direct access to some hardware (like for a POS software with cash drawer, receipt printer etc), you need to go "desktop". Clickonce can give you some deployment options, XBAPs can give you the "browser experience", but you are going to have to make compromises based on what your "hardware access needs" are.
EDIT:
I didn't notice the Silverlight exclusion in the original question. My comment it not really applicable. Sorry!
I don't know that I would call ActiveX dead just yet, but I would be cautious if you are planning to build an application based upon this technology. My recommendation would be to use Silverlight. This provides much of the functionality that is commonly desired in ActiveX controls, but uses the newer .NET technologies.
There is alot of talk about using Silverlight for media playback, but it has many powerful feature that can also be used to create Line-of-Business applications as well. In fact there is a great podcast episode on DotNetRocks that discusses this exact subject.
Here are a few more links that might point you in the right direction:
Microsoft Silverlight Getting Started
Silverlight 2 and a Glimpse of Silverlight 3 by Scott Guthrie
To the best of my knowledge, Silverlight 4 still doesn't give you direct access to serial ports, but it does give you access to any local web cam and microphones now. You could presumably also run Silverlight 4 out-of-browser, which gives you access to COM objects, and you could write a quick-and-dirty COM object which wrapped serial port access. That said, I also agree with what folks said above about not all applications belonging in the browser.
At work, I want to create a WCF Windows Service that runs on a network server. Then I want to create a WPF application that can be installed on various machines on the network. This WPF application needs to be able to communicate with the WCF Windows Service on the network server.
Is this feasible? Is there a better way to accomplish what I want to do? Does anyone know of any resources that show examples of this? I found some tutorials how to setup a WCF service within a Windows service, but I am unsure how to communicate with it over a network.
Thanks for any advice!
Yes, a WPF application can host a WCF client just as well as (and in the same way as) any other .NET application. You may run into security limitations if your application is packaged as an XBAP for browser delivery, but otherwise it should all just work.
Similarly, a Windows service can host a WCF service. For an example see "How to Host a WCF Service in a Managed Windows Service" at http://msdn.microsoft.com/en-us/library/ms733069.aspx.
You can then communicate with it over the network by creating a client proxy -- the easiest way to do this is to use the Visual Studio Add Service Reference command.
I don't understand your question. You say you saw examples of WCF servers and clients, but you are unsure how to communicate with it over a network. But all of the examples you saw were about the clients and servers communicating over the network!
What's the difference between what you saw in the samples, and what you want to accomplish yourself?