I know that XAML is used for designing UI in combination with Blend. I am confused with so many terms, like, how XAML comes into play for WPF, Store App, Phone App or UWA. Morever, what is the difference between WPF, Store App, Phone App and UWA. Does all that means that old Desktop Project will no longer be used and replace by either WPF or Store App or UWA?
When .NET was released in ~2000, you could use WinForms to make desktop applications for Windows. It provides access to 'native' controls (i.e. A Button made in WinForms actually is a Windows Button control from user32.dll) by wrapping the Windows API in managed code. These can run in any version of Windows which has the appropriate .NET framework version installed, including upto Windows 10.
In 2006, WPF was released which is an alternative to WinForms. WPF uses XAML, which is a language based on XML, to declare the user interface elements. In a simple WPF app, the .xaml file describes the GUI and the code-behind file describes the logic. DirectX is used to draw whatever is described in the .xaml into the window.
Like Winforms, programs made using WPF can run in any version of Windows which has the appropriate .NET framework version installed, including upto Windows 10. Note that using XAML is completely optional. Whatever user interface elements you describe using XAML can also be made using your .NET language C# or VisualBasic.NET. But using XAML is usually simpler. See To XAML or not to XAML (MSDN Blogs).
From XAML (Wikipedia) :
As XAML is simply based on XML, developers and designers are able to share and edit content freely amongst themselves without requiring compilation.
From ~2012 along with Windows 8, a new kind of app called metro/modern/windows-8/windows-store-apps can be made. These apps are similar to WPF in that they use XAML for describing the GUI. These apps can run only in Windows 8, 8.1 and Windows 10. Windows 8.1 added some improvements and features but remained mostly the same. The same technology was used to make apps for Windows Phone.
With the release of Windows 10, Microsoft made UWP (Universal Windows Platform) through which you can use the same code base to target differnt kinds of devices (desktop/mobile/xbox/IoT/holographic). These apps made for the UWP are similar to the earlier Windows 8/8.1 apps. Like before, XAML is used to describe the GUI.
Only for the Windows Store apps, there is no backward compatibility. The timeline goes Windows 8 -> Windows 8.1 -> Windows 10/UWP. An app made in UWP can only run in Windows 10 and an app made in Windows 8.1 can not run in Windows 8.
I would highly recommend referring to this discussion thread in stopbyte, it has far more details and explanation of the concepts behind WPF, UWP And WinRT.
As for WinForms, from my experience it's history now. Have been almost replaced by WPF (though it still has mainstream support as mention by #Jazimov).
I'v noticed that Microsoft has stopped improving Windows Forms and probably has stopped maintaining it as well.
Related
I have a simple question : Is it possible to create a windows 10 app (tablet for my case) in WPF instead of UWP ? Because actually my app need a framework that allow to create pdf, but none free framework exist in UWP yet, but un WPF this is quite different. Thank you.
WPF apps are fully supported on Windows 10, so nothing stops you from using WPF instead of UWP!
In fact, you can even take advantage of UWP features in WPF apps by using the Desktop Bridge (Centennial)
As I understand, WinRT is a different version of WPF written without using the underlying Win32 APIs.
What's the relation of WinRT and WPF? Will WPF work under Metro in Windows 7 or will it launch the classic desktop?
That's not so clear from the Keynote. If someone has Windows 8 installed can confirm it's behaviour.
Thanks
WinRT is a replacement for the Winapi. The api is native, very unlike WPF that runs as a layer on top of the CLR. It certainly resembles WPF, part of what causes confusion. It adopted the metadata format of managed code, replacing type libraries of old. And uses XAML for UI designs, much like WPF, Silverlight and Windows Phone. You can still write WPF apps for Windows 8 but your app can't be published through the store, won't integrate with the Metro desktop nor will it run on tablets that are based on the ARM core. Whether that's a real problem depends a great deal on how well Metro will do in the market place.
There is no relation between WPF and WinRT, just like there is no relation between Silverlight and WPF. Now we have three technologies, WPF, Silverlight and WinRT.
If you try to execute WPF application, it will not execute on Metro, it will execute in the classical desktop only.
In Visual Studio 2011, you have WPF and Metro as two different types of applications, and Xaml for WPF and WinRT is not same, Xaml for WinRT is pretty much same as that of Silverlight as lot of classes which exist for WPF are missing in WinRT library. But most of classes that exist for Silverlight are available in WinRT.
Windows Runtime (WinRT) is an alternative API used to create Metro Applications
(and later server application).
The APIs are class/method/struct based and surfaced to .Net metro apps, html5/css3/javascript apps and C/C++ metro applications.
The implementation is native.
APIs are made visible via .winmd files, which contain metadata very similar to the metadata you have in .Net assemblies.
The APIs are designed to secure and async friendly with many APIs requiring the use of async/await due to them potentially taking more than 50msec to execute.
It includes a subset of Win32 APIs and COM apis.
Anyway... the followings links help... channel9 also has some //Build/ videos on the subject..
Metro style app development
- http://msdn.microsoft.com/en-us/windows/apps/
Win32 and COM for Metro style apps
- http://msdn.microsoft.com/en-us/library/windows/apps/br205757(v=VS.85).aspx
APIs for Metro style apps
- http://msdn.microsoft.com/en-us/library/windows/apps/br211369(v=VS.85).aspx
WinRT is a new library that you can use XAML, but not WPF.
WPF is primarily uses DirectX for visual.
You can use WinRT with:
XAML
C#
C++
VB.NET
HTML/JS/CSS
WinRT is a non managed API based on COM interfaces. You use it by calling objects buit in .winmd metadata files ( Windows\System32\WinMedataData directory).
All the namespaces begin with "Windows.".
You can write your Windows 8 application by using XAML files, but that's the only common point with WPF.
These both are same or different ?
How to develop silverlight in visual studio 2008 ?
UPDATE
Please also answer
How to develop silverlight application in visual studio 2008 ?
Both WPF and Silverlight uses what is called XAML to define what the interface / GUI should look like. WPF and Silverlight are both Presentation Layers used on different areas.
WPF is used for Windows based applications whereas Silverlight is used for Web based applications.
Read this blog post about "When should I use WPF vs Silverlight?" over at MSDN.
You can think about Silverlight like a subset of WPF, but there is one main difference. WPF uses full .Net Framework and Silverlight uses different dlls (so you can't use all classes from .Net framework in SL).
Of course Silverlight is a presentation technology that you use to create browser base application (SL can be also an out of browser application) and WPF is used to create windows applications.
Silverlight's original code name was WPF/E with the E standing for "Everywhere". That should help understand the origin of it.
It was designed a a reduced and portable version of WPF, but now both seem to diverge a bit. Here is a good article on how they diverge: WPF Compatibility
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What is the difference between WPF and Silverlight application?
What are the exact differences between WPF and Silverlight?
That's an extremely broad question. My company recently wrote a whitepaper outlining the differences between the two technologies, and it's around 70 pages. Unfortunately, it's not published yet, or I'd give you the link.
EDIT: As promised, here's the link
to the whitepaper on Codeplex:
http://wpfslguidance.codeplex.com/
However, I'll try to summarize.
WPF is a thick Windows client platform that has access to the full .Net Framework. Silverlight is a browser-based technology that has access to a subset of the .Net Framework (called the CoreCLR). So, you'll notice differences using seemingly every day methods and objects within the framework. For instance, the Split() method on the String class has 3 overrides in Silverlight, but 6 in the .Net Framework. You'll see differences like this a lot.
Within WPF, all visually rendering elements derive from the Visual base class. Within Silverlight, they do not; instead, they derive from Control. Both technologies, however, eventual derive from the DependencyObject class up the hierarchy.
WPF, currently, ships or has available more user controls than Silverlight; though this difference is being mitigated through the Silverlight Toolkit and the upcoming release of Silverlight 3.
WPF supports 3 types of routed events (direct, bubbling, and tunneling). Silverlight supports direct and bubbling only.
There's quite a few data-binding differences that will be somewhat mitigated with the next version of Silverlight. Currently, Silverlight doesn't support the binding mode, OneWayToSource, or Explict UpdateSourceTriggers. In addition, Silverlight defaults to OneWay databinding if none is set, while WPF uses the default mode specified by the dependency property.
Silveright doesn't support MultiBinding.
Silverlight supports the XmlDataProvider but not the ObjectDataProvider. WPF supports both.
Silverlight can only make asynchronous network calls. WPF has access to the full .Net networking stack and can make any type of call. Also, currently, Silverlight supports SOAP, but can not handle SOAP fault exceptions natively (this may change in Silverlight 3).
There are huge differences in Cryptography (Silverlight has 20 classes in the namespace, while WPF has access to 107). Basically, Silverlight supports only 4 hashing algorithms and the AES encryption protocol.
Silverlight doesn't yet support: Commanding, Validation, Printing, XPS Documents, Speech, 3D, Freezable objects, or InterOp with the Windows Desktop; all of which are available in WPF.
Silverlight supports browser interop, more media streaming options including timeline markers, and Deep Zoom. WPF doesn't support these features yet.
This is by no means complete as I was trying to reduce a 70-page document into bullet points.
Finally, even with all these differences, Microsoft is trying to close the gap between the two technologies. The Silverlight Toolkit and the WPF Toolkit both address some of the shortcomings of each technology. Silverlight 3 will be adding many features not currently available (such as element-to-element data binding). However, due to the differences in the core libraries, there will always be some Framework differences.
WPF is a Windows desktop technology for developing Windows application in the .Net framework.
Silverlight is a web technology, that is fully supported by a browser plugin on both Windows and MAC (in a similar fashion to Flash). There is also a plugin for running Silverlight on Linux (Moonlight).
While there are similarities between the functionality provided by both WPF and Silverlight (in terms of user interface components and support for XAML) Silverlight is a much small framework, containing a subset of WPF functionality. Newer versions of Silverlight actually contain some functionality not found in WPF, so it is no longer a true subset.
Things that WPF has that Silverlight doesn't: Full 3d engine based on DirectX, Windows integration such as Windows 7 taskbar thumbnails and system registry availability as well as access to the full .NET Framework including Oracle database support. Also, SL runs in a secure sandbox that prevents access to things such as the entire file system where WPF apps can run full trust with complete system access.
As mentioned above, SL pioneered some technologies such as the VisualStateManager which are making their was secondarily into WPF through the Microsoft supported WPF toolkit.
If you're looking to gauge which technology is right for your project here's a simple way to look at it: If you're writing an app that's meant to run while disconnected from the web, or if you're writing an app that needs access to Windows specific features like the ones listed above then WPF is the way to go. For platform-agnostic, web enabled apps Silverlight is an appropriate choice. Hth.
You could say that it is [VERY] roughly analogous to the difference between Flex and Adobe Air, but that is somewhat misleading.
WPF refers to the set of technologies (exposed via APIs) that .NET Framework 3.0 and above users have access to in order to draw to the screen.
Many of the WPF APIs are available for Silverlight apps.
There are, of course many other APIs besides WPF that are available under Silverlight since SL apps will need to do a lot more than just draw on the screen.
I just installed visio, and the installer almost seemed like it was built in flash.
The buttons kinda glowed when I hovered over them, and when I clicked on 'continue' the form phased out in a cool way.
I'm assuming it was built in WPF.
Anyhow, so are WPF more flash-like (visually speaking).
Do they have new properties where you can make forms phase out nicely/smoothly compared to winforms?
Disclaimer: I work for Microsoft. However, I don't work on Visio, WPF, CLR or Silverlight team. So, the following is my personal take on these technologies. If you want to quote me, don't do it implying it's the official Microsoft position. :-))
Update: Anything I say below about Flash/Flex/AIR might be wrong, as I have not worked with these technologies and what I know about them is based on what I read on the intertubes. :-) If you notice anything wrong, just shout in the comment and I'll correct it.
To the best of my knowledge, the Visio installer is not built with WPF. It's all unmanaged code; it's just people took a lot of care to make it really polished.
WPF is the new UI platform for building standalone applications for the Windows OS. It supports a declarative UI language - XAML, and related CLR types to program against. WPF is a different platform than WinForms, although it is possible to build applications that mix UI built with both. WPF supports a lot of things that WinForms does not, like bitmap effects, animations, control styling and so on and exposes them both in XAML or through code. Also, WPF relies heavily on vector graphics, as opposed to the pixel graphics in WinForms. In short, WPF is quite powerfull and allows building very snazzy UI. (Don't take my word for it, though, as I am biased; go check around for what people are saying about it or buiding with it. :-))
WPF and WinForms do not compete with Flash/Flex. WPF and WinForms are both UI frameworks for building standalone client applications. As far as I know, Flash/Flex are frameworks for building rich internet applications - RIA (though lately people started interpreting this abbreviation as rich interactive applications).
Adobe did come up with AIR about half a year (or maybe a year) ago, which allows building standalone client applications, so you could say that Adobe is trying to position Flash/Flex/AIR to compete with WPF. Of course, that's my take on it and I doubt Adobe's official positiong is anything like that.
If you want to compare particular MS technnologies with Flash/Flex, take a look at Silverlight - it's the MS RIA platform.
Silverlight is related to WPF in the sense that they share XAML and the corresponding CLR types. Silverlight supports only a subset of what WPF offers, though, as it is not targeting Windows OS only and thus is limited by the fact that it has to be portable.
Quick update to reflect the changes in the year since I've written the answer :-)
With Silverlight 3 shipped, SL and WPF are getting even closer and sharing bigger set of supported features. In addition, most of the new XAML controls are built for platform at the same time. Thus, SL/WPF are getting to a point of singularity...
Also, SL 3 supports out-of-browser applications. In that sense, SL is not only starting to compete with Flash/Flex, but it is also encroaching on AIR's turf.
And no, I still don't work on the WPF or Silverlight team. :-)
WPF is being used as a replacement for WinForms, and as a competitor to Flash in the form of Silverlight. WPF consists of an entirely new object model that sits on top of DirectX (at least the desktop version). You can create WPF windows, controls, etc, entirely using C# or another .Net language just like you can render WinForms. However, Microsoft has also created a markup language called XAML (eXensible Application Markup Language). Nodes in an XAML document (XML) map to objects in a similar fashion to the way ASP.Net maps to web controls. XAML typically exists in a .Net project alongside a code-behind style C# file (or VB.Net or whatever). The C# file interacts with the objects generated by the XAML. This is fairly consistent with the "graphics via markup, logic via code" model that Microsoft and others are pushing.
One of the overlooked features when discussing WPF is the completely awesome data-binding that Microsoft wrote for WPF. The new data binding framework is a quantum leap beyond Windows Forms 2.0 data-binding. Microsoft added a couple of new interfaces that make it much easier to make an object or collection emit data-biding events properly. They also provided a very rich set of data-binding classes. You can bind anything to just about anything else. You can bind one-way data to control, control to data, two-way control to data and back, control to control, etc.
Back on the graphics side of the house, WPF makes it fairly easy to make an existing control look like anything. WP lets you compose your own template for what a class of buttons should look like, or one button, or all buttons. Or radio buttons. Or labels. You get my drift. Imagine if CSS included the ability to define what an input button would look like using other HTML controls.
They also provide a number of layout controls. You can continue to use exact positioning like in WinForms, or you can leverage of variety of techniques to make your window act more like a web page that grows and shrinks with resizing, etc.
The downsides: It is too easy to create spectacular effects that crawl on slower machines. Some of the graphics do not take advantage of hardware of graphics cards, though Microsoft has incrementally improved support for this. I believe when 3.0 first came out drop shadows were rendered purely using software. I think 3.5 or 3.5 SP1 changed it so that WPF would utilize graphics hardware for the task. Microsoft has said they will continue to enhance WPF in this fashion.
WPF is .Net 3.0 and above, which runs on XP SP2, Vista, and Servers 03 & 08. So don't plan on deploying WPF to a customer with Win2k desktops.
Summary: If you are doing desktop programming in .Net, you should be doing it in WPF unless you are targeting Win2k. You can avoid the downsides of WPF, and there are many upsides. Microsoft will probably throw away WinForms in some future release, or at very least you will stop seeing new features, etc.
As far as Silverlight goes, the betas for SL 2.0 look good. I think that Silverlight will require some wide-spread adoption. Microsoft has already tried to get this going. The NBC Olypmics site used Silverlight, and Major League Baseball uses it for its MLB.tv product. As soon as Silverlight gets a good install base I think you will see the Microsoft side of the development world starting swinging away from Flash and to Silverlight.
Edit after using Silverlight 3 and MVVM:
I have moved away from WPF and am doing a lot of Silverlight 3 development. But I think my comments here will still apply to the WPF developer.
I have been using the MVVM pattern in my app (think MVC with a twist). The Microsoft Patterns and Practices team has released a set of libraries known as Prism that supports various aspects of MVVM. There are WPF and Silverlight versions. Take a look at MVVM and Prism if you are going to be doing WPF or Silverlight development.
You can do a lot of flash w/ Winforms, or with custom components. But if you want out-of-the-box bang-whizz availability, WPF is the way to go.
Yeah, I think the intention is to be flash-like, it seems to me that MS has set its sights on taking down Adobe.
The way I see it: WPF is to Flash as WinForms is to Flex. WPF has more emphasis on vectors and states than on programming.