I have windows phone silverlight app with mvvmcross. This app using in-app purchases. I want to port the application in Windows 10. The best way is probably the creation of universal application for Windows Phone and Windows 10. But I don't have necessary time.I want to realize the transfer in stages:
Porting app to Windows 10 with in-app purchases.
To implement user authorization in app and data synchronization between applications.
Possible upgrade silverlight app to universal app for Windows Phone.
What technology should I choose for stage 1 - WinRt or universal app? If I chose universal app I can not synchronize purchases between applications in the first stage. Synchronize of purchases I can only implement the second phase of the user account. This behavior of the application will not meet the expectations of users. How to solve this issue?
If you want a Windows 10 app, everything is UWP now (choose Universal Windows).
It's probably best to start with a new Windows 10 project and start moving code from you old project to the new one. Most will work. Some need rework. Some XAML definitions are changed, most code should work.
Also have a look at this blogpost with more helpful tips: http://blogs.windows.com/buildingapps/2014/12/17/bring-your-windows-phone-silverlight-apps-to-windows-runtime-xaml-prepare-for-universal-app-development-in-windows-10/
Martin
Related
We have developed a WPF application runs great on Windows 10. At this point we are looking for ways to run this software on a Minnowboard. This board has a Windows IoT OS. As I've seen it is only capable to run UWP applications. Is there any way to make our app run under IoT? Thanks.
Of course you can port your code. Depending on how complex your app is, it still might need some rewriting as many APIs are not available anymore, have changed or were added.
Maybe these links help you:
Move from WPF and Microsoft Silverlight to WinRT on MSDN
UWP Bridge tool by Mobilize.NET
UWP samples by Microsoft on Github
Windows 10 IoT Enterprise version enables WPF apps
I want to create Windows Store app and it in it would like to host some Windows Forms controls. Is this possible?
The short answer is no. As pointed out in the comments, Windows Store apps use XAML and not winforms, and also run inside an app container (Modern UI) and cannot access the desktop (where winforms works). Also, Windows Store apps run in a highly sandboxed environment and cannot run external desktop applications.
The answer to this question may have been "no" in the past, but it appears that Microsoft has a specific solution to address this scenario. the Desktop to UWP Bridge is designed to host Windows Forms and legacy applications in a UWP container that can (with some limitations) be installed from the Windows Store.
The Desktop to UWP Bridge appears to be designed to handle this situation
https://developer.microsoft.com/en-us/windows/bridges/desktop
I have a winforms application and was wondering whether I should attempt to move it to Windows store app (and WPF) or not. I would expect metro style apps to have the same potential as desktop apps, but what got me wondering is the fact that VS 2012 is not a metro app. It doesn't really surprise me much as every metro app I've seen so far look like a phone app that can't really do much and I can't imagine how VS would look like as a metro app.
Seems to me like Microsoft wants to slowly move everything to metro, otherwise I don't see the point on introducing a whole new visual experience just to get stuck with having to switch between metro and desktop, but even Notepad is still a desktop application. So my question is, basically, is every kind of application supposed to be movable to metro or is metro only for small phone-like applications?
I don't believe that Microsoft is intending every application to end up Metro. I see more lightweight types apps going to Metro. Heavy duty line-of-business apps will stay on the desktop side of things.
I do see an opportunity for writing both desktop and Metro style apps in enterprise environments though. Imagine this hypothetical scenario:
In an enterprise, I can see Accounts Receivable running the full-blown, monolithic, desktop application on their desktops just like they run them under Win7 because they’re needs are pretty extensive.
The receptionist will run a touch enabled laptop with a Metro app that is tied into just the corporate appointments.
The guys on the loading dock will be running Win8 phones that have the intake/outtake app showing schedules for deliveries and what not.
Managers and executives have Metro tablets that have an app that shows metrics: lots of pretty charts and graphs showing the current condition of what and how the company is operating in it’s different lines of business.
For the users that need the complexity, it’s desktop mode, but for the users that perform smaller, specific computer tasks, touch-enabled Metro apps for them.
Metro-style apps are for content consumption, like you would find on a tablet.
Classical desktop apps are for content creation.
I think metro apps are an additional feature and I do not think, that they are a serious replacement for desktop applications. If you want to deploy your apps to tablet PCs, phones or any other touchscreen/handheld devices, metro style would be a good choice. At the moment there are just not many consumers for metro apps as Windows 8 has not even come to the markets.
As you already mentioned, on desktop PCs metro apps are very uncomfortable and do not provide the full functionality as desktop applications can do.
So my question is, basically, is every kind of application supposed to be movable to metro or is metro only for small phone-like applications?
I don't think so, as this means automatically that many customers who have used previous versions of Windows would have to learn working with the metro interface.
Metro apps provide much more functionality than desktop gadgets have done in Vista, as they can be programmed using C# or other .Net languages, but metro apps use up too much space to be controlled with a simple mouse.
I've heard that Windows Phone 7's user interface (UI) is completely based on Silverlight. Can anybody confirm this? Or it is implemented by other frameworks?
Windows Phone 7 will support developing apps in either Silverlight or XNA.
Are you asking if the shell, etc that comes on the phone itself is written in Silverlight? My first question would be "why does it matter what Microsoft used?" It's probably a good bet that they leveraged it, but I doubt they did everything in SL. At some point they have to get down to the OS. For example, I doubt the built-in media player core or Office apps are SL.
Looking at the unlocked emulator image contents would certainly let you deduce which parts were developed with what technologies. I leave that exercise to you.
Indeed Silverlight is used for third-party apps on Windows Phone 7, plus XNA is supported too as mentioned.
However the Office apps and some first-party applications are written using the Iris framework which is an internal only developer framework similar to WPF, it is the same framework used for the Zune Software (Dorado) which is used to sync to a Windows Phone 7 device.
Yes it is based on Silverlight
I can tell you one thing, they are using Expression Blend (or a modified version of it) for parts of the core UI design. You can see the developers using this on one of their promo videos.
This question already has answers here:
Why change from WPF to Silverlight 4?
(8 answers)
Closed 3 years ago.
If I understand correctly, Microsoft Silverlight is a lightweight .NET implementation meant to run on the client side, inside a browser. So now I hear about "out of browser" silverlight applications and I'm confused.
What is the advantage of an "out of browser" silverlight application, compared to a traditional .NET desktop application?
An out-of-browser install of a Silverlight application still runs in a security sandbox where as a traditional .NET desktop application won't.
The objective of an OOB is to give the user the ability to lift a web-based application out of its browser container and make it easier to access. Its still a web based application. Its worth bearing in mind that this works on a Mac where as a traditional .NET desktop app won't.
This area has become muddier with SL4 OOB that can now ask the user for elevated trust. Now the sandbox is more relaxed and there are greater opportunities to work with the native OS. However there are still many restrictions in place primarily to support multi-platforms. It would not be desirable if it became a defacto that trusted OOBs tend only to work on Windows. It remains to be seen whether that can be avoided.
So if you're thinking of a full-fledge Windows desktop app then you're probably better off using WPF. On the other hand if you don't need full access to the OS, you can deliver via a web page and/or you want to be able run on both Windows and Macs (and possibly other platforms) then perhaps Silverlight 4 OOB+Elevated Trust may be what you need.
Silverlight 3 out-of-browser apps allow any Silverlight app to have a desktop shortcut, and don't require the browser to be opened to run the app (so technically you could now run the app even if you're offline, since you don't have to fetch the SL app via the web).
With SL 4, you can now have elevated privileges, allowing the SL app to access local resources (such as the network stack and file system).
There's also a simple API call for an out-of-browser SL app to check for updates on startup, and download an update from the server. This could be seen as similar to click-once deployment, but it happens automatically and quickly, so it's more efficient and straightforward than click-once.
Compared to a traditional .NET app (in this case let's compare with WPF, since that's effectively the WinForms replacement), there's very little in the way of installation. No setup program, just the xap file, easily hosted on the web and very quickly installable. SL uses a reduced .NET framework, which might seem like a negative. However, the typical pattern for an SL app is to put most of the heavy-lifting in a service tier. Then, in the service tier you have the full .NET framework and can do pretty much whatever you want (such as accessing databases with ADO.NET).
Libraries are another thing to consider between the two applications. For example, Silverlight 4 natively has built in support for talking to a web-camera and microphone out of the box while WPF and the full .net Framework have a very large third party community of libraries to draw upon which you might need source code for if you wish to rebuild them under Silverlight.
Another factor is limitations in the sandbox, for example, you wouldn't be able to write an application that could connect to any server using any socket in Silverlight 4.