I need to make an application compatible with the all NET Framework: 2, 3, 3.5 and 4.
In addition I want to develop an application that when performed with a PC that has only installed Framework 2 the GUI is made with Windows Forms, but if the PC is using the Framework 3, or later, the GUI is done with WPF.
I have developed an application with NET 2 and Windows Forms.
I tested this application with NET 3, 4 and 3.5 and it works correctly.
I recently updated the GUI with WPF, these changes were simple, because I developed the interface with the databinding paradigm.
This choice has allowed me to switch from Windows Forms to WPF easily.
I overcame the problem of creating a single application (for Windows Forms) to be performed with any framework using this guide: http://msdn.microsoft.com/it-it/library/w671swch%28v=VS.100%29.aspx.
Now I wanted to make sure that if the PC was the NET 3.5 or higher installed the application using the GUI made with WPF.
I tried to follow some guidelines, such as: http://msdn.microsoft.com/it-it/library/433ysdt1.aspx, but unsuccessfully.
I am very confused about how to proceed.
The application should not install anything on the PC, just use what is there.
Thanks in advance,
Talao.
If your application needs to be compatible with all of those versions then what you're really saying is: it needs to be a .NET 2 application. A .NET 3 (or higher) application simply won't work otherwise, because it won't find the assemblies it needs at startup.
That said, since .NET 3 is built on .NET 2, I'm sure you could find a way to dynamically load the .NET 3 assemblies if the framework is available. This isn't going to be pretty, though.
Even if you manage this, however, the fundamentals of an application are very different under WinForms and WPF, so you'll find you're rewriting a lot of code. Simply replacing the View of an MVC application isn't likely to be enough (unless you're willing to write some really complicated views...).
My suggestion would be either to write two applications or - for preference - write it in .NET 4 and include the framework as part of your installer. Assuming this is a commercial application then it's either that or just stick with WinForms - I can't imagine the development overhead is likely to be worthwhile.
The simplest solution I can think of is to develop the GUI using MVC/MVP pattern. Where the view is either a Winform form or a WPF form. You then developed each view as a WinForm Form and as a WPF form.
At startup of the application, call Environment.Version to get the framework version. Based on this version you can tell the application to load with WPF or Winform views. If greater than or equal to the 3.5 framework, use WPF, else use WinForm views.
The other approach is using compatible controls, where you can put WinForms inside WPF controls, however you lose the power of WPF by doing so, so this is only good to bring in a few WinForm controls to a mostly WPF application.
Did you consider creating multiple applications, one for each user interface? If you have business logic and user interface separated, than this should not be much of a problem.
Then installer analyzes target system and determines which executable, Winforms or WPF, is going to be installed.
Related
We're building a Silverlight 4 LOB application. However, we're concerned that not all our clients will be able to support Silverlight. For example, most of our clients will be large companies and it's possible their IT department hasn't authorized Silverlight to be installed on user machines. And it's possible that some of our clients will have installed 64 bit versions of IE on user machines. Both of these situations would prevent our clients from using our app.
To deal with this possibility, we'd like to build our app in such a way that it could easily be hosted as a WPF application, if we had to drop back to that position. Our middle-tier and backend would be the same, regardless of the client used.
We're going to initially build our app to be a Silverlight app. A WPF version would come a bit later. My question is this. What precautions should we take, when building our Silverlight app (UI), to make sure the app easily ports to a WPF app (using ClickOnce)?
WPF is (near enough) a superset of Silverlight, so it should be easier going from Silverlight to WPF than it is going the other way. As long as you are using an MVVM framework which abstracts over any platform specific features, then porting the code will be simplified (I would recommend Caliburn.Micro).
Rocky Lhotka (the author of the CSLA business object framework) has a nice blog post on some of the differences between Silverlight and WPF, and things to consider when targeting both platforms.
One of your problems will be solved by Silverlight 5, since SL5 plugin will work in the 64 bit IE.
Porting from silverlight to wpf shouldn't be too hard. One thing you can do to guard against possible issues is to get 3rd party library of ui controls that work on both silverlight and wpf. I'd sugest to start with silverlight and move to wpf only if you see real push back from your clients.
Our client has a Desktop application (VBA and Access) that they are using for the past 10 years and it is buggy and they want to upgrade it. I want to use the latest MS technologies and plan to make this a web application using .NET 4.0, C#, SQL server and MVC running on the Intranet.
Since the application has many visual components (about 10 different tabs on top and each tab has atleast 10 different controls on it), I was wondering what is the best way to implement the UI layer a .NET web application. The 2 candidates are Silverlight and Telerik controls (we have license for this).
Some issues to consider :
Silverlight Plug-in : Since this new application will only be used internally on the intranet, I dont think installing a Silverlight plug-in will be an issue. Also, since its on the intranet, hopefully download speed should not be an issue for SL apps.
Telerik-MVC : It is really rich in functionality, however, I played around with it (.NET version not MVC) using some of the controls and if there is anything out of the recommended way to use a control, its a pain to get it working.
Skill-set : Do I want to learn how to use a tool (Telerik) or would I be better off learing a technology (Silverlight) in terms of future projects.
I would like to hear any feedback/ issues to help me decide which way to go.
If you are replacing a desktop application then going with Silverlight may be the best approach.
With Silverlight you are writing an application that happens to be delivered across the internet (well intranet in this case). This can be as stateful as you need to be. You have good access (no pun intended) to the database via the WCF RIA Services.
There's also the Prism MVVM model you can develop on top of.
However, I'd double check with the client as to what they are expecting.
Telerik also do a set of Silverlight controls.
If the project time permits, go for Silverlight. Also, if needed, it's possible to create a desktop version (WPF) out of the Silverlight project.
Issues with Telerik control set(or any control set), if you need a control that doesn't exist in the current set, you'll have to either buy from Telerik, or create your own. In the latter case, the whole UI aesthetics might break because it's not easy to create a control matches the tool set.
I am at the initial stage of designing a client application. However, being new to WPF and having already gained some experience in Win forms development, time pressures on the project means that there is a risk to going down the WPF route. If time were no pressure, then I would say forget forms and design with WPF. However, I am not lucky enough to have this luxury. Having spent a little time investigating the Composite Application Block for Forms, I have decided that I will definitely develop the application within this framework. However, there are 2 versions of the CAB, 1 for WinForms that targets the .Net 2.0 runtime which has now been retired, and then the WPF version which targets .Net 3.5. Not being a fan of 'retired' code libraries, I would prefer to use the WPF version of CAB. This may be a silly question, but is it possible to use the WPF version of CAB for Win forms application developement? I do envisage at some point in the future moving to towards WPF. If I could use the WPF version of CAB I am hoping that this would make it easier to migrate the forms application to WPF.
It looks like somebody had the same idea that you did.
I found it by reading this thread on the CompositeWPF codeplex forum, discussing this very issue.
You should be able to do this without too many issues. We are currently using CAB to enable us to display SQL Reporting Services reports in WPF (along with a couple other items). It's a pretty simple implementation, but our architecture is WPF-based, not WinForms. As far as we've been able to tell, there wouldn't be much of a problem were it the other way around, and displaying both types of forms is done the same way.
I have a small project that I will be working on shortly that collects employees time and what project the person was working on. Pretty straight forward. I was orginally going to work on it in WinForms but since im new to that I though maybe using Silverlight for the application since I will have a learning curve for each. Here is a couple of business requirements that i need to incorporate into the application.
-System will use an Access database hosted on a particular persons computer.
-Ability to generate and print reports
-Installed on the emploees desktop who will have access.
Would one technology be recommended over the other in terms of what I need to do. Here is a screen mockup of one of the pages I will need to create.
http://teewebco.com/images/main-copy.png
If you want access to the machine on which the application will run (e.g. to access a database, and to use printing), that pretty much rules out Silverlight, without jumping through a lot of hoops (e.g. having to install something on the user's machine anyway).
You say that WinForms will require a learning curve for you - well you might as well use WPF then, as it's a similar technology from the UI perspective as Silverlight. However, you can proably find a lot more resources online for WinForms though, and it's likely you'd be more productive in WinForms given its strong Visual Studio designer support.
Deployment with WinForms or WPF should be fairly easy with ClickOnce.
Since it's a local (desktop) app which needs to access a local resource (Access database), it's probably better to do winforms.
However, you might be better off doing this as WPF instead - it's more current than winforms.
Winforms and WPF are easier than Silverlight when you have to access a database because you can do it directly. If your install base uses only .net 2.0 then stick with WinForms, if you know they can install .NET 3.5 then try out WPF. Just be warned, there is more to learn with WPF and XAML but it's very rewarding especially if you want to get fancy.
Silverlight 3 lets your application to run on desktop as well.
So I'd write it on silverlight. Yet another technology to master.
Is it possible to convert an existing WPF Application to SilverLight automatically/with minimal effort?
I would argue that you CAN port Silverlight to WPF with minimal effort. I spent 2 hours porting and application I spent 3 weeks writing. I would argue that those 2 hours spent would categorize as minimal effort.
Sure, you need to create a new project, add the files to the new project and tweak them.
Since Silverlight is a subset of WPF its allot easier to go from Silverlight to WPF than the other way around.
For business logic and non-UI code your code should port almost straight across. I had some minor issues around authentication, as Silverlight 2 will pick up any authentication information in the browser, while in WPF you have to role your own login screen and manage cookies etc.
For the XAML it will port straight across if you don't style your controls. If you style your controls the use of the Visual State Manager, currently missing in WPF, will make things a little trickier. You can either re-style your controls in WPF using Triggers, or you can use the VSM implementation for WPF done by John Gossman. Microsoft have announced that they will add the VSM to WPF to make the two frameworks more compatible.
The perhaps most important reuse tough, is skills and experience. Since the two platforms are so similar you will be able to reuse all your skills in WPF.
I recently did a blog post about the Dive Log sample application and how I ported it from Silverlight 2 to WPF. Might give you some idea of the process.
Not really. I have found some articles regarding the multi-targeting option for WPF and Silverlight at the same time. At this moment, if you are not using PRISM, it is quite a challenge to target both of them, fortunately achievable.
What do you need to have in mind is that Silverlight uses a smaller (thus more limited) library than WPF.
In response to the comments:
Actually, there is already support for silverlight in PRISM (v2). The idea of PRISM is to provide guidance to developing applications not only using WPF but using Silverlight also - Prism V2 formally was known as Composite Application Guidance for WPF and Silverlight.
By using PRISM for silverlight capabilities, it would give you the warranty that your code would work on both platforms with minimal changes, if none (except maybe the different project types for visual studio).
But of course, if you already started developing your application, you would need to change your code to use PRISM.
Will and Bogdan's answers are correct. The keyword here is "minimal".
Rob Eisenberg has a list of differences here (though this was pre-RTW).
List of Differences in WPF & Silverlight
No. Silverlight runs in its own cut-down version of the CLR. It also is WPF-like, not WPF. You'll have to do a fair amount of work to convert it.
Times have changed. Check out Portable Class Libraries, now supported in .NET 4.0. You can build assemblies that can be used on different supported platforms: WP7, Silverlight WPF and even XBOX applications.
Here is a thread about this:
http://silverlight.net/forums/t/3898.aspx