I want to share as much code as possible between Silverlight and WPF.
My lowest level handles the difference between calling the database directly and calling a web service.
My data layer on top of that is compiled with both .NET and Silverlight.
My GUI layer is currently designed as a WPF Control Library.
For sivlerlight...
Is it possible to reuse my XAML for my silverlight class library?
Do I need to create a "Silverlight Application" or can I just display controls from my class library directly?
What things do I need to be careful about? (For example, I already learned that Silverlight can't use DataTables in web service calls.)
Related
I've already worked with WPF but i don't know anything about SilverLightnow I need to develop an application which can run on both Mac and Windows,so i was thinking to write an WPF Application with MVVM for Windows and run it on Mac Using SilverLight?Is that possible to port from WPF to Silverlight and how much work needs or maybe should I write the application with SilverLight from beginning,even for my Windows users?Which one is better and faster?
a quick answer is Yes..
but lot of things to do. You could share most of XAML view across platform but not all of them.
try to put all business logic into service layer like BAL or middle tier
put presentation logic into ViewModel class library
create separate XAML View (for SL and WPF)
there are several docs about target multi-platform here..
A Cross-platform WPF, Silverlight & WP7 Application at codeproject
Sharing Code Between Silverlight and WPF
This is a question about design approach. I have limited COM experience and a little WCF experience. My constraints are given by the application environment, but I have some design flexibility.
From within a VB6 dll, I need to start, and communicate with, a WPF application. The WPF application is currently an exe, but I could make it a library if that helped. I would like to provide two way communication between the VB6 dll and the WPF application. I have some flexability to adjust the design of the VB6 dll.
I'm developing C# using in VS2010 and .NET 4.
How many components should I use? Can I start the WPF application In-Proc with the VB6 dll? Should there be a third component between them? Can COM+ play a helpful role? Do I have to make the entire WPF application COM-visible? Is there a down-side to doing this?
I'm looking for a design approach that I can prototype. I'm willing to research the details.
I would
Create a Web Service from the WPF application, using WCF. I would abstract out those aspects of the WPF application which should be accessed remotely. This would explicitly not include any of the user interface code.
I would create a simple class library project, and use "Add Service Reference" to add a reference to the WCF service.
I would make the methods of the class library COM-visible
I would call those methods from VB6
This has the benefit of removing any considerations of user interface from the equation.
Out of the options available I like the COM option more than the 'start another process' option for the simplicity that the inter 'application' communication will be via method calls rather than WCF or anything similar.
I am assuming that your VB DLL lives in a window'd process and not a service or web application. You would only need to mark any exposed types as COM visible, that is the classes, their argument and return types.
You may have to wrap your WPF UI inside the windows forms ElementHost [1] but I'm not sure, try it and see.
I'm not sure if you saw this [2] in your search, it sounds do-able but unsupported, ok as long as you don't have too much going on.
[1] http://msdn.microsoft.com/en-us/library/system.windows.forms.integration.elementhost.aspx
[2] http://social.msdn.microsoft.com/forums/en-US/wpf/thread/7555ba6a-1359-4dfe-aa23-c31a8f121142/
I work on an application primarily written in VB6 but most of the recent code is written in .net with UI components built in WPF and some WinForms. Datasources for this application are WCF, MSSQL server, and a propritary unix based server. All the WCF calls are made from data access components referenced by the .net UI components.
You can host WPF in VB6 windows or other container controls. Start by getting the Interop Forms Toolkit and build shell user controls to host your WPF controls.
To be able to host WPF in these controls you need to build a WinForms usercontrol which contains a ElementHost, which you can set the content to your WPF usercontrol.
WPF Usercontrol inside an Element Host inside a
WinForms usercontrol inside a VB6 usercontrol or
window
The interop toolkit will want to build VB.Net code but you can do it in C#, although I have not tried this. The usercontrols created by the interop toolkit will be exposed as COM components which you can reference VB6 by adding them as components via Project > Components and then you will find them in the toolbox.
In terms of data sources (WCF, databases) etc, you should build all your data access in .net components referenced directly from the UI components, don't try to call back in to VB6 libraries, you will probably just create a mess.
In my application I also have a configuration section which I call from the VB6 application startup which sets up an IoC container for all the .net components.
From a best practice approach I actually would recommend rewriting your VB6 code to .net and putting VB6 out of the picture. If this is not an option then you have a number of options, my explanation is just one of them.
I had a few questions on WPF & silverlight?
When to use WPF? Some examples on
real time projects where WPF is used
When to use silverlight? some examples of real time projects where silverlight is used
What is the difference between
them?
Can WPF and Silverlight be used together?
How do WPF and silverlight differ from traditional asp.net applications (form based & MVC)???
Does Silverlight use WCF to do it's code behind stuff..like it provides an interface and uses web service to get the code behind?
WPF vs Silverlight will tell you what you want to hear...
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
In short I would generally use WPF for form/window applications and use Silverlight for online things. Though these both can be used for either, that is how/when I would use it.
WPF and Silverlight both use XAML, so if you can code in one, you can pick up the other just as easy.
WPF is a client based platform while Silverlight is web based. WPF has the full .NET framework available while Silverlight has a streamlined "smaller" version of the framework.
The nice part is both use the same markup (XAML). Both also can work with the MVVM pattern for easy conversion from client to web app and vice versa.
I would read up a little on the web as these arethe basics of these 2 technologies.
WPF and Silverlight are conceptualy completly different things. They use same technology, but their purpouse is completly different.
WPF is thick client framework, that is supposed to replace WinForms in (I hope) nearest future. It has acces to full .NET framework.
Silverlight is Flash-like technology for rich internet applications and thin clients. It is complementary to standard ASP.NET technology. If you want to increase amount of eye-candy or give user much richer interaction options for your web, this is way to go.
They both use same visual-description technology (XAML) and same principles (DataBinding, Templating, Separation of visuals and code, etc..). But their intended usage is different.
I'm getting started with Silverlight. When creating a new solution I have the option of creating a Silverlight Application or Silverlight Class Library. The Application option sets everything up for me but class library is quite sparse.
I'm trying to work out which one do I start with? Particularly I'm uncertain about when I would use SharePoint Class Library and what benefits/restrictions it has over Silverlight Application.
I'd like to write a control that I can put either a plain ASP.NET or Silverlight UI on top of, with both talking to the same back end.
The Silverlight Application template will create a shell UI with necessary project configuration to launch a Silverlight application. You have the option of creating an asp.net or plain html-based Silverlight application. The Class Library template, like the non-silverlight counterpart, is UI-less component that the Silverlight application can consume. You will not be able to reference regular class libraries, or sharepoint class libraries from a Silverlight applications as framework requirements are different ... Silverlight relies on stripped-down framework that is not compatible with full .NET release at this time.
So, in order to develop a Silverlight application, you need to start with Silverlight Application template, which then can reference any number of Silverlight Class Libraries, depending on your project layout or architecture.
If you want to write components that you can either snap an ASP.NET UI or Silverlight UI, you will need to create either a Class Library (for ASP.NET) or Silverlight Class Library (for Silverlight). You will not be able to reference Silverlight Class Library from ASP.NET, or reference Class Library from Silverlight. However, you can share the code between the different class libraries by linking source code files between them.
ib.
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.