So Windows Embedded Compact 7 (another classic from the naming department) supports Silverlight for Windows Embedded.
http://www.microsoft.com/windowsembedded/en-us/products/windowsce/compact7.mspx
But this is a C++ only stripped down version of Silverlight 2 XAML.
Does anybody know if Windows Embedded Compact 7 will support real Silverlight? This seems to be out of step with Windows Phone (which I think is based on Windows CE 6) and the fact that Windows Embedded Compact 7 supports Flash 10.1.
Not in the first release, no, it will not support managed Silverlight (or, IMO, what the entire world considers to be "Silverlight").
They may, at some point, move the work done by the Phone team to create a managed SL implementation, but they've made no announcements as to if or when that might ever occur.
You'll see "Developers,Developers" Balmer come out later like he has done before and admit they made a mistake with this. Its the developers that produce the apps and if you make all the microsoft technologies linq, wpf, ria and patterns such as MVVM unuasable developers won't trust you and move to another platform. They dropped the ball on the Phone OS by not having a great consumer oriented phone. Now they will focus on consumers stick it to the business developers that they had built up on Windows Mobile. They did a great job with the silverlight 4 so I don't understand how they can drop the ball this badly on Compact 7.
I agree about the non-uniform development environment, but you should also consider that the processor that are currently powering WP7 devices are not still available on the general embedded market where 1GHz processors are a small minority and 5-600MHz processors are used only for hi-end devices.
Trying to run both the XAML and the .NET runtime could lead to weak performances and disappointing results.
If you need RAD, use the Compact Framework.
If you need cool UI, use Silverlight for Windows Embedded.
You can't have both right now, as you can on the phone...
Related
When I create new Windows Phone project I have an option to create a "Windows Phone" or "Windows Phone Silverlight" app. I know that they have different runtimes and different APIs.
I was under the impression that Microsoft wants to unify Windows and Windows Phone platforms so why is there even a Silverlight version? What benefits does it bring?
Also, if I want to create an app just for Windows Phone and never have plans to bring it to Windows, what should I choose, Silverlight or Windows Phone?
I'd suggest you go with "Windows Phone" (non-Silverlight). It's the new API, which works for both Windows and Windows Phone. At some point you may want to port the app or create a new one for Windows and you'll already know the API (and porting will be way easier). Also, the new API will most likely get more updates and features added, and at some point you may even be forced to update to it (either because the old one is no longer supported, or because it does not have some features that you need).
As it was said in the other answers - the Silverlight option is there only for backward compatibility and is likely to be phased out in time. That is - it's good if you already know the API and have many libraries (yours or others) for WP Silverlight, but if you're just starting - you'd better go for the new technology.
Edit
There is one other thing to consider before choosing between the two types of apps. Some features are only available in a Silverlight app, and others (smaller amount) - only in a Xaml app. Here's an article with some info on the differences: Migrating your Windows Phone 8 app to a Windows Runtime XAML app
Windows RT Xaml is quite new and People have to generate some knowledge first.
Silverlight for phone has been around for years and there's a load of tools available: Phone Toolkit, diverse Controls, etc.
Just killing it off would have hurt many developers who built up intellectual property over a long time forcing them to start over.
When starting a project with Silverlight you will have more things around that help you get stuff done.
When starting with WinRT Xaml, you will have better performance, but will have to figure a lot out by yourself.
So the Silverlight option is there to not throw of Silverlight developers.
I recently started a new project on WinRT Xaml and my experience was that I had to recreate a lot of common tools like Caches, etc. But also a lot of things that were in Toolkits previously are now part of the platform itself. Also, when moving over to Windows 8, you get to share a lot of code which is nice.
Unifying the environment(s) would be ideal. In my opinion, it hasn't been very successful. At one point in time, you could only develop under Silverlight, so what you are seeing is just a newer version of the same thing to keep backwards compatibility as well as to keep Silverlight's developers happy. In the future, it will probably be phased out. Plus if you want to support older Phones, Silverlight is basically your only choice (you'll be surprise, how many WP users haven't updated their 8.0 to 8.1)
There really isn't any other real benefit of Silverlight other than maybe the Windows Phone Toolkit which has been tremendously useful (you can see how many SO's answers rely on this simple addon). Once the universal runtime gets fleshed out to the point where the documentation reflects what's actually available -- then I think it would be the default project for developing in Windows going forward.
If you're just starting, I would use Silverlight the knowledge based is much greater. After you get use to the WP environment then switch to runtime.
Today, while I'm running a Silverlight project in the Internet Explorer by pressing F5 in Visual Studio 2012 in my Windows 8 machine, I found that McAfee started to block Silverlight XAPs (Which is loaded by Prism).
This leads me to think again about the future of Silverlight. I'm at the beginning of my LOB Application. Should I stop what I like to work in Silverlight and return back to WPF. I which that I can continue to develop in Silverlight until Windows 8 becomes rich like Silverlight. That is why I limit the Model and MVVM to PCL to be easier to be ported to WinRT in the future. Using await async and so...
Please advise me which is better for a LOB application that will run in three countries throw the Internet. Should I continue in Silverlight for zero deployment, or work in WPF or even Windows Forms and use clickonce?
The fact that McAffee blocked something has NOTHING to do with it's long term future. McAfee is nobody, they don't determine whether or not a specific technology can be used or not, or will be used in the future.
Silverlight seems to have reached a dead end, due to Microsoft realizing that if they create a multi-platform application environment, people might just stop using Windows.
WPF also seems to have been abandoned in favor or WinRT XAML, but of course WinRT XAML is not an option for us developers at the moment, simply because it is Windows 8-only, and our customers don't have Windows 8 or greater.
Besides, technically, WinRT-XAML seems to be really inferior to WPF XAML, and lacks many important features.
Of course winforms is completely useless and is not an option, unless you need to run your applications in my grandma's 80386 computer with an Hercules monochrome monitor
(exaggeration).
Seriously, that dead technology is not the answer to any of today's challenges. Things that you can do easily in any of the XAML-based technologies are either impossible or require a bunch of horrible hacks in winforms.
I suppose the definitive answer depends a lot on the usage scenario, for example:
Silverlight makes more sense if you have to publish your application in a web site and have anyone download it and use it.
WinRT XAML makes sense only if you target Windows 8, or want to create 'metro style' apps.
WPF makes sense if you want to create Windows Desktop applications, and have them deployed via ClickOnce or Windows Installer to a more limited and controlled set of users (because it needs installation of the .Net Framework, which Click-Once can deal with anyways).
winforms makes no sense whatsoever because it's a completely useless dinosaur technology that doesn't support anything.
Thank you very much for your answer and sharing your experience with me. I always try keeping WinRT as a strategy planning for each line of code I write. As I wish to migrate my code easily to WinRT in the future. The future is translated to me as may be within two years I may find myself in a situation that we will be targeted to migrate to something like Windows 9.
The best successful migration scenario - as I wish, it could be by increasing the usage of PCL at the client side as much as possible and test in a small piece of WinRT module.
We hope that Microsoft succeed in Windows 9.
I am sadly decided to shift to WPF instead of Silverlight in case that Silverlight depends on browsers that may not be supported in the future. As we here that Chrome, Safari and others are stopping supporting Silverlight. Why should I insist in relaying with such great technology that is dead before it finishes.
The main difficulties I could face in the future migration could be tied to two patterns:
- Prism.Regions: Windows Store has better than that.
- Prism.Modularity: Windows Store has no migration strategy to that.
At least at the moment I'm writing my thoughts Prism for Windows Store are far from implementing Regions and Modularity.
This is not a final answer but a clue of my what I should and should not to do.
I've been developing a windows store application for a windows 8 tablet (Microsoft surface). So far the application has been designed using XAML-RT/C# using a SQLite database. The application won't be released via the store, it'll be just used internally by my company.
I am however finding numerous problems with the platform. i.e. speed of the surface device, releasing versions and renewing the developer licences.
As the application is still in the development stage and no decision has been made on the final tablet I'm thinking about re-writing the application using WPF and using a full windows 8 tablet (not a RT/ARM version). This way I can use full SQL and have much more control over releasing the software.
So, my question is...
What is generally the best development platform for a full windows 8 tablet? Is it best to go with WPF or stick with the Xaml for RT?
Thanks
WPF
less sandbox limitations (can call any APIs)
is currently somewhat easier to do enterprise deployment with
has more features
is more mature overall
can benefit from Surface SDK 2.0 controls for great touch support on big screens
WinRT/XAML
works on ARM devices
is lighter and faster
has built-in modern touch-enabled controls targeted for tablet use
might be better suited for use on tablets overall
Overall the main benefit of WinRT is that you can use it on ARM tablets which are cheaper, lighter and more usable as tablets. WPF requires heavier devices and might be slower, but you gain the ability to access all legacy APIs.
If you intend it to be fully touch screen ready then you'll have to do some extra work in WPF to get the level of UI interactivity that you get from the "metro" apps.
That being said, if you're writing a complex application that requires lots of API calls/web services and file handling then you're going to have a much easier time with WPF.
We were beginning to start on an enterprise application using silverlight.
However after reading this post we doubt whether it is the right choice going forward.
The post says that, according to
Microsoft's declaration in PDC 2010,
Microsoft has changed their strategy
regarding silverlight and they no
longer view it as their technology to
deliver cross platform applications.
Instead they are targeting silverlight
as their development platform for
Windows phone 7.
Is this correct? Should we still continue with silverlight or go back to ASP.NET WebForms\MVC?
The Scope of the application is basically intranet with Windows 2008 servers and Windows XP and Windows 7 clients. However a subset of functionality needs to be available to the external users over the internet. There we cannot have any restrictions on what OS users can use.
based on the info you gave, I can't conclude whether silverlight is the way to go. But what I do know is that a number of Microsofties wrote some blogposts about the things said about Silverlight on the pdc. For example John Papa, Bob Muglia and Scott Guthrie.
Update about the scope
I think you already gave the answer when you described the scope of the application. A part of the application will be available to external users and you cannot have any restriction about the OS they are running. With that requirement I think Silverlight is not the best way to go. Not because the rumours about its future but because of its platform indepency. What are the reasons not to go for a ASP.NET/web solution? Silverlight doesn't work on each OS whereas plain HTML will work everywhere. (ok you need a descent browser)
Although for a good advice I'd need more information about the application.
Basically the question you have to ask yourself is this: do you need your application to be used on every platform, i.e. Windows, Mac, Linux, misc. flavors of Unix, IPhone and other mobile platforms?
If that's the case, then a web based solution is the way to go.
If Windows, Mac and partially Linux is enough, then save yourself and your team a lot of pain and use Silverlight.
In my opinion support for mobile clients is the key factor in your decision.
For sure the right platform for Intranet, Enterprice applications Is Silverlight. It is
stable, performs extreamly well, the environment and the development time is huuge less than web application development, the end User Experience is much better and so on and so forth... Once you want to show part of the system out the the intranet - just create some specific target modules that will address the needed audince. You won't have the universal "Reachfull" solution, that will target everyhing, you'll always need mobile versions or other devices and so on. But once you've built your project the right way with Services (same services that the Silverlight app will consume), it'll be easy job to consume them with new UI.
Hope you will choose Silverlihgt.
Silverlight is a great technology, but the Microsoft does not develop it anymore. So as a technology is a great decision. But if you want to make a Silverlight app usable on a NOT supported platform (e.g. Android or iPhone) you have to use 3rd party services. For example http://sl2html.com
I'm considering switching from MFC to WPF.
My first concern is that there are too many users who don't have .NET with WPF installed yet. Can anybody point to a source containing the WPF penetration numbers?
My second concern is speed.
Any other considerations?
I've been banging away at WPF for a while now. It is brilliant, but it still has (occasional) holes you've to plug yourself. However all indications are .NET 4.0 will be a significant step forward.
I would say start now. The WPF learning curve is REALLY steep, and it'll be a while before you'll be releasing software to users, believe me. Also do yourself a favour and get the WPF Unleashed book. It's superior.
Speed isn't a consideration. The power WPF gives is well worth any drawbacks with speed, which - coming from Windows Forms - I haven't noticed to be honest.
What kind of application are you developing? If it's a wide-distribution desktop app that you want your grandmother to install, your concern about .NET 3.0/3.5 adoption is valid. So far from what I've seen, performance is less of a concern.
WPF penetration
First of all, Windows Vista and Windows 7 both have WPF preinstalled, which accounts for 35% of the market automatically. Windows XP has had it as it had .NET Framework 3.0 as an option in Windows Update for over three years, and many applications ship with it, so it is likely to also be installed on a high percentage of Windows XP machines. StatOwl indicates that about 80% of NET Framework installations are version 3 or above.
If you're shipping on CD it is no big deal to include the latest .NET Framework on the CD and have it install automatically. If users are downloading your application, it can contact Microsoft's web server to download and install the latest .NET Framework. Online ClickOnce deployment also has this capability if you want people to be able to start their application directly from the web browser without installing it.
So the bottom line is, you probably don't need to worry about whether people will have WPF installed on their machines or not unless your target market consists primarily of dial up customers on Windows XP who don't run much third-party software (i.e., they just run Windows and your application).
Speed
Not an issue. I have a 200 MHz Pentium Pro with 384 MB RAM from 1998 that I test my software on, and my WPF applications have comparable performance with equivalent MFC applications. If your WPF application uses lots of fancy graphics and animation it will run slowly on ancient CPUs and graphics cards, but so would an ordinary MFC application with the same features.
Don't even bother trying to use WPF if you are sticking with Visual Studio 2008 for the next year or two. The experience will be way too painful. I'm talking about "my IDE crashed again" type of pain.
If you are going to use VS 2010 in the near future, then WPF is a blast. Download the beta, a couple of themes off CodePlex, are start playing. Once you get past the (freaking huge) learning curve I think you will find it to be quite enjoyable.
IMHO, you should wait for Visual Studio 2010 and WPF 4.0 to make the actual migration. They will close some very annoying gaps in the product.
Meanwhile, you can try it out. In terms of coding/readability -- it's going to be WAAAY better than with MFC =)
As for the performance and platform -- it shouldn't be a problem unless you have any very special circumstances (like if you can't require users to install .NET).
Also see this related question on switching to WPF from Windows Forms.
If you are thinking about a larger, modular, appliation I recommend checking out Prism. It's a bit of a beast itself, but you should be able to tackle it after coming to grips with C#, Dependency Properties and XAML. Plus, learning Prism gave me a much better understanding of WPF/Silverlight, at least from the development/binding side.
Mike Taulty posted an excellent 10 part video series on Prism. It's a great way to get your head around the platform.
I'd also recommend the pages linked to from the Getting Started page on codeplex. After all that, you're probably ready to tackle the Reference Implementation which comes with the download.
A previous answer of mine might also help clear up any remaining confusion around Controllers/Presenters in the framework that you might have (I did).