We are planning to develop a Silverlight 'cross platform' application, that is expected to run on both Windows and Mac with elevated permissions. Mono alone is not an option, as the application requires Silverlight specific video features, supported only in SL 4.0
So, here are some considerations.
1 - The 'Application', should interface with a local database (outside Isolated storage)
2 - The application should be able to talk to native libraries for performing some DVD IO operations.
3 - It has to be installed via a custom installer, much like a desktop app
We are trying to identify the best way to to satisfy the requirements, if possible, with a common code base, probably using SQLLite for the database.
In Windows, things are straight forward. You can use sllauncher to install the XAP with elevated permissions, and you can access the SQLLite and other system level operations via probably a COM layer. Not a big deal.
But how to implement interfacing with SQLLite and system level libraries in Mac? Is there a documented/undocumented way to interface with Mac libraries from Silverlight (Mac)? I think no. One option might be to use Mono's XSP web server, and run an ASP.NET site from the local machine, and host the XAP locally, and then implement a handshake with the ASP.NET code running via Mono/XSP, and then do the interfacing from there.
Another option will be to host the Silverlight in the Mono's Winforms browser control (I still need to see if this is possible), and then do the talking between Mono Winforms browser and Silverlight via HTML DOM.
Both are not straight forward options in Mac.
I highly appreciate any inputs you can provide to achieve the objectives in a better way.
Part of the solution could be to define an interface on your database. In windows you could choose to talk directly to it, and for mac you write a soap server. Your silverlight app should be allowed to talk to that. You can implement the soap server in mono, then you have one language all way....
I don't believe the Winforms browser control works on Mac, but you could try MonoMac instead.
Related
What is the best approach to communicate between UWP app (client app) installed on phone and WPF app itself installed on local machine if they are connected to the same router? Files should sync from client to server and vice versa.
As I investigated before there are WCF, Sockets, and Web. So what is the best one to use to create such functionality?
It does not matter if the app is WPF or UWP. To choose framework like WCF or Sockets you need to know how complex your scenario is. If it is rather simple, I would advice agains WCF. It can be unnecessary complicated for basic usage. You can try web api - lite system using JSON. Generally speaking, I do recommend the framework enabling http protocol as it is reusable for almost every scenario. But that is not filter that would help you much :D
For UWP that have not allowed calling localhost and you can use it to communicate to local wpf app.
More details here and here.
But you can make the uwp communicate to local wpf app in debug, see Deploying and debugging Universal Windows Platform (UWP) apps - UWP app developer | Microsoft Docs
If you want your uwp app can use localhost in release that you should use checknetisolation and you can see some way to use wcf in the article.
I want to develop web based configuration utility for WIN CE 6.0 device. This webpage is expected to configure/access/modify device's registry settings, reboot device etc. WIN CE Device has a webserver running on it. I am clueless about how to start.
Suggest some way to modify registry values using webpage.
Take a look at the source code for the default web admin module. Fair warning, it's ISAPI, it's near impossible to debug with anything but MessageBox calls and it has to be done in C++. But it is free.
The source is installed with Platform Builder and ends up on your dev machine at
%WINCEROOT%\PUBLIC\SERVERS\OAK\SAMPLES\HTTP\WEBADMIN
Another free option would be to create and install a COM object (written in C++,. most likely with ATL) on the target. Your web pages could then create an instance of that object and use it to interact with the device using the built-in "classic" ASP server. Installing the COM object on already-deployed devices or devices where you don't create the OS is going to be a large support challenge. Debugging these objects is not fun (though slightly easier than ISAPI if you build a separate test loader app). Also be aware that the built-in ASP server supports only a very scaled-back subset of ASP 3.0 (which is obsolete to begin with).
All of the web-based device admin we've ever done (and we've been doing it for a decade) has been through the Padarn Web Server, which uses C# following a subset of the IIS object model. It's a commercial product, so it's not free, and for full disclosure it's a product that we created (because I felt the built-in option is so bad) and sell.
I'm a bit confused on how continuous integration works with a Windows Phone App. Is there a way to upload the app to the marketplace automatically, or do you still need to do a manual update?
Do I need my own server for this, or are there hosted options?
And which program works best to test, build, and continuously integrate a windows phone 7 app?
Edit: I'm using Atlassian Jira, but Bamboo seemed to only apply to Web apps, not apps that are deployed on devices. I have no requirements, and no experience, and don't understand how CI even works with a non-Web based project. However, I do want our code to be passing all it's tests before it's committed to SVN, and if there is a way to automatically push the latest stable build to our users, in an automated way, that would be great.
Marketplace submission is a manual process and there is currently no way to do this automatically.
There are various continuous integration processes and tools available. Whether you need a separate server to run it on or which program will be "best" for you will depend on your scenario, requirements, experience and preferences.
You can use any solution which supports Visual Studio 2010 as long as you can install the Windows Phone SDK on the same machine. Hosted solutions may or may not allow you to do this.
In a situation where you have the UI frontend built using the new Metro style of apps for windows 8, and would like it to communicate with a .NET application running on the desktop on the same local machine (e.g. a windows service app).
What forms of interprocess communication are available between the metro app and the desktop app?
Thanks to Pavel Minaev of the Visual Studio team, who has provided some initial info here in a comment, quoted:
According to Martyn Lovell, there isn't any deliberate mechanism for
that, and some that could be used for it are intentionally restricted.
Named pipes aren't there, for example, nor are memory mapped files.
There are sockets (including server sockets), but when connecting to
localhost, you can only connect to the same app. You could use normal
files in one of the shared "known folders" (Documents, Pictures etc),
but that is a fairly crude hack that necessitates polling and is
visible to the user. -- Pavel Minaev commenting on this issue
So failing normal approaches I was thinking of using web services or reading/writing to a database in order to get some form of communication happening, both of which seem like overkill when the processes are running on the same machine.
Is what I'm attempting here making sense? I can see a need for a metro app to be the frontend UI for an existing service which is running on the desktop. Or is it better to just use WPF for the frontend UI running on the desktop (i.e. a non-metro app).
I'm porting my existing project to Win8 right now. It consists of windows service and tray application which are talking to each other via NamedPipes WCF. As you may already know Metro doesn't support named pipes. I ended up using TcpBinding for full duplex connection.
This post describes what functionality is supported.
Sample of my WCF server that Metro client can consume is here.
Also keep in mind that you can't use synchronous WCF in Metro. You'll have to use Task-based wrapper which is only asynchronous.
And thank you for you question. I was good starting point for me :)
There were a number of questions like this at the end of a //build/ session I attended. Aleš Holeček, the exec who did one of the big picture sessions, came up out of the audience to handle them. Even if you're not a C++ developer, download that session and watch the Q & A. http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-789C
Metro apps can't count on desktop apps or services being installed on the machine. And desktop apps can't count on Metro apps running since they can be suspended any time. You need to start thinking differently. Listen to Aleš on this one.
Take note that with Windows 8.1 Update, communication between Windows Store apps and desktop components written in C# for .NET 4.5+ is now officially supported for side-loaded applications in Enterprise scenarios:
Brokered Windows Runtime Components for side-loaded Windows Store apps
To quote:
Recognizing that critical business functions and rules are embodied in existing software assets and that enterprises have a wide variety of scenarios for which the new application style will be highly productive, the Windows 8.1 Update includes a new feature called Brokered Windows Runtime Components for side-loaded applications. We use the term IPC (inter-process communication) to describe the ability to run existing desktop software assets in one process (desktop component) while interacting with this code in a Windows Store app. This is a familiar model to enterprise developers as data base applications and applications utilizing NT Services in Windows share a similar multi-process architecture.
Although implementing this approach is a bit on the complicated side initially, it allows for deep integration across Windows Store and desktop components. Just keep in mind that for the time being, it won't pass public Windows Store certification.
There is an article on InfoQ about how to build loosely coupled Metro apps with protocol handlers. This is something which has been supported by Windows for a long time and one could foresee an desktop application register itself as a protocol handler and maybe the metro application can communicate through this mechanism.
I have no idea if this is possible, but it might be interesting to check out.
Christophe Nasarre has blogged about a rather hacky way to do it using local files. The result is communication between desktop app/windows store app (referred to as DA/WSA in the blog), without having to switch between the UI of the two apps. He also blogged about another less hacky technique involving protocol handlers.
Note that having a WSA which communicates with a DA is explicitly forbidden by the store App certification requirements
Windows Store apps must not communicate with local desktop applications or services via local mechanisms, including via files and registry keys.
... but it restricts "local mechanisms" only. So I guess one can build a web service for routing the communications.
If you think that you can make an additional manual cmd operation,
you can try :
X:/> CheckNetIsolation.exe LoopbackExempt –a –n=<packageID>;
CheckNetIsolation.exe is included in winRT install, so there is nothing extra to be installed.
I tried it: it works, even after package updating.
As shown on: http://msdn.microsoft.com/en-us/library/windows/apps/Hh780593.aspx
Here it is explained how to find out the packageID for your app: http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/82bad7d4-d52b-4731-a396-13ab9004c1cc/how-to-get-the-appid-of-a-metro-style-app-
It is possible to communicate on the same machine from Metro app to desktop app using local service.
I've implemented some time ago simple "proof of concept", how to bypass the WinRT sandbox using local service. It still needs some kind of "social engineering" or direct guide for installing the service, but anyway, it is possible.
I'm not sure though about the certification rules about "local service" communication when adding such app to Windows Store.
Sample here
By design Metro application cannot access underlying PC directly, only using WinRT API and available capabilities. But when you create back-end service for accessing the PC and all data there, it's basically no longer running in sandbox.
The only "problem" is that user must manually install this back-end service, but that won't be a problem using some "social engineering":
User downloads "PC browser" Metro app, user can browse all pictures, music and videos, using WinRT API, but the app also shows message at the bottom:
"Download our PC browser powerpack and browse your entire PC, for FREE"
User is redirected to web page, from where user can download classic desktop installer containing "PC browser" back-end service for accessing files on users entire PC. Once this desktop service is installed, the Metro app can detect it and use it for browsing the entire PC. User is happy, but the WinRT sandbox is compromised.
Of course this won't work on Windows 8 ARM tablets. Using this workaround it could be even possible to build Metro app clients for classic desktop apps like antiviruses, torrent/P2P clients, etc.
Maybe I missed the point but when activating the Private networks capability I can connect to a local running (http) server using the local IP address (not localhost). This enables my scenario where a winrt app communicates with a wpf desktop app
With .Net what is the best way to interact with a service (i.e. how do most tray-apps communicate with their servers). It would be preferred if this method would be cross-platform as well (working in Mono, so I guess remoting is out?)
Edit:
Forgot to mention, we still have to support Windows 2000 machines in the field, so WCF and anything above .Net 2.0 won't fly.
Be aware that if you are planning to eventually deploy on Windows Vista or Windows Server 2008, many ways that this can be done today will not work. This is because of the introduction of a new security feature called "Session 0 Isolation".
Most windows services have been moved to run in Session 0 now in order to properly isolate them from the rest of the system. An extension of this is that the first user to login to the system no longer is placed in Session #0, they are placed in Session 1. And hence, the isolation will break code that does certain types of communication between services and desktop applications.
The best way to write code today that will work on Vista and Server 2008 going forward when doing communication between services and applications is to use a proper cross-process API like RPC, Named Pipes, etc. Do not use SendMessage/PostMessage as that will fail under Session 0 Isolation.
http://www.microsoft.com/whdc/system/vista/services.mspx
Now, given your requirements, you are going to be in a bit of a pickle. For the cross-platform concerns, I'm not sure if Remoting would be supported. You may have to drop down and go all the way back to sockets: http://msdn.microsoft.com/en-us/library/system.net.sockets.aspx
If this is a tray app, and not a true service, be wary of how you set up your communications if using pipes or TCP/IP. If multiple users are logged into a machine (Citrix, Remote Desktop), and each user launches a tray app "service", then you can run into a situation where you have multiple processes trying to use the same well known port or pipe. Of course this isn't a problem if you don't plan on supporting multiple pipes or if you have a true service as opposed to a tray app that runs in each user shell.
Have your service listen to 127.0.0.1 on a predefined port with a plain old TCP stream socket. Connect to that port from your desktop application.
It's dead simple and it's completely cross platform.
Did any one of you actually try remoting with Mono? It works just fine. You might bump into some corner cases, but this is highly unlikely. Just test your application for cross-platform (MS.Net <-> Mono) remoting from time to time to catch any possible glitches. And start with a recent Mono, 2.4.2 is current.
Remoting is an option, but it's not cross-platform. Some other ways are to use named pipes, IPC, or kernel events.
Funnily enough I was going to suggest Remoting! The Mono 1.0 Release Notes (from archive.org because the original location is missing) mention System.Runtime.Remoting.dll as a supported library and doesn't say anything about known issues.
If remoting is out then you probably have to implement your own TCP message framing protocol. Windows doesn't have an equivalent of UNIX-domain sockets for communication on the same machine.
Most services that have a GUI component are run as a named user, and are allowed access to the desktop. This lets you access it via COM or .NET but only locally (unless you want to get complicated)
Personally, I open an ordinary old socket on the service - its cross platform, allows multiple clients, allows any app to access it, doesn't rely on Windows security to be opened up for it, and allows your GUI to be written in any language you like (as everything supports sockets).
For a tray app, you'd want a simle protocol to communicate - you might as well use a REST style system to send commands to it, and stream XML (yuk) or a custom data format back.