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.
Related
We have a VS2012 solution that contains two class library projects, one that produces a Silverlight DLL and one a standard .NET DLL. The class files are shared ("Add as Link") between the two projects.
The upshot is that they both contain a WPF/Silverlight control that inherits from Canvas that we then use within Silverlight and WPF applications.
We are now looking at using the same component within an app to be used on a Microsoft Surface RT. How do I go about building a DLL that can be used like this?
There's no reason you couldn't do it the same way, you are already doing it if WPF and Silverlight: just create a Class Library (Windows Store apps) project and add existing class files as links to it as well.
You can use conditional compilation symbol NETFX_CORE when you need different code for Windows Store apps:
#if NETFX_CORE
// Windows Store specific code
#endif
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 am developing application for WPF and Silverlight by ProjectLinker with PRISM and MEF modularity.
My modules are Class Library (in WPF) and Silverlight Class Library (in Silverlight).
Now I want to load modules in WPF or Silverlight by Catalog.xaml from server.
Problem is:
- Silverlight cannot load DLL but only XAP
- WPF cannot load XAP but only DLL
How can I do that - developing by project linker (same code for both platforms), create modules, download from server and load to application?
I have in bootstrapper:
On server WCF I have Catalog.xaml - I download it and...
catalog = Microsoft.Practices.Prism.Modularity.ModuleCatalog.CreateFromXaml(stream); - it works
But If I run application by the load module I have an error (I tried to load DLL to Silverlight).
Thanks
Try this link from the PRISM website: Sharing Code Between Silverlight and WPF
For the Module catalogs, you will either need to create separate XAML files, or use possibly use TT files to generate them from a common set of module names.
As you need to carefully specify the dependencies for Silverlight to get the best start times, you might be better off maintaining separate files.
Problem was on type of project. Project for silverlight must be as Silverlight application. So I changed type of silverlight project and now build for WPF is DLL and for silverlight is XAP. It is working.
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.)
Can a Silverlight application call a method in a full .NET c# class library?
I am trying to add a Silverlight control to my Existing ASP.NET project where i used to add reference to my Business Logic Project and access methods from My UI pages of ASP.NET Web application. Now I have added one Silverlight project to my solution.
How can I use the already existing BL method which is in a C# class library ? When tried to add reference, it is saying that
"You can only add project reference to other silver light projects in the solution".
Should i give up ? Is there any way to get rid of this ?
A common method to achieve this is to build a silverlight library that links in all the files from your Business Logic library. This way the code is written once, and built twice. To link the files go to Add Files in Visual Studio and select the drop-down arrow on the Add button. Select Add as Link.
Alternatively Silverlight 4 and .NET 4 have binary compatible assemblies, so as long as the code in your main Business Logic library is fully Silverlight compatible you should be able to use the library as a reference there.