We are starting a new project and I'm trying to decide which of the Wpf-esque develop/deploy strategies we should go with. In our case we are looking at quite a complex business app that will be used by 100s (not 1000s) of people, So I'm leaning towards a click-once app. My boss likes the idea of a Silverlight app as it means easier deployment. So which way should we jump?
The answer is, of course, "it depends".
So what are the pros and cons of each?
I'll start the ball rolling (Edit Added in some answers from artur carvalho):
Silverlight
Pros
Cross browser
Doesn't require full framework.
Better control of users. If your users login, you dont have to worry with activation keys or similar stuff.
It works on Windows and Mac.
You can update all your users apps easily.
Cons
Can't interact with client's file system etc
Has less functionality compared with full Wpf (anyone got a good resource that documents differences?)
Single window
Single version
Wpf Web App (xbap)
Pros
Full Wpf.
Cons
Single browser
Requires full framework
Can't interact with client's file system etc
Single window
Single version
Wpf Click once
Pros
Full Wpf
Can work offline
Multiple windows
Multiple versions (con?)
Better access to low level parts of the computer
No downtime for maintenance
Cons
Single browser
Requires full framework
Slightly(?) harder to install.
First, I would evaluate whether a web client (ideally MVC+jQuery) can't do the job...
Assuming a full client is warranted:
If it is a business app that demands a client, I would tend to go with the full framework and ClickOnce; the main difference here (re deployment) is that the client must have the framework installed - but past that, ClickOnce deployment is very pain free. Actually, building a ClickOnce manifest is much easier than Silverlight etc, since the IDE will do almost all of it for you; you just have to host the files somewhere (could be a web URL; could be a network UNC).
This gives you much more control (and power) at the client, as well as a far greater range of existing resources to use (for example, if you need, you can use some legacy winform code on the WPF surface). The "requires full framework" is also one of the largest benefits: "has full framework".
You should also perhaps consider the 3.5 "client profile" setup; not sure how wide-spread this is in reality... but worth knowing about.
You didn't say if this is a company only application or a public facing one. That alone will decide it for you.
If company only, I would go with full WPF click once. This will give you everything.
Full framework should not be an issue. It's a one time install running in the background so it's not something that your decision should depend on. Cons: it runs in Windows only but if your company is Windows only, this should not be an issue.
However WPF apps could be resource hungry so you need to know if all your client machines are capable of running WPF apps smoothly.
If it's an Internet app, go for Silverlight: it runs under different operating systems.
PROs vs. ASP.NET Web Forms
No ViewState or "surprise crap"
o This applies to Silverlight as well. Silverlight brings the "desktop" experience to the end user and there is no ViewState that is used in Silverlight.
Faster server-side & client-side
o Silverlight is faster on the client/server side depending on how you look at it. Silverlight is compiled in a .NET subsystem of Silverlight. You have access to multithreading, LINQ, complex data structures, etc. The performance vs. an ASP.NET or AJAX/JavaScript application is it magnitudes times better because of the client execution and some of the items that normally are handled in a server BLL can be brought down to the client
Simplified model for multiple related views
o Silverlight supports the complete seperation of the data and the UI. Taking this further by just creating seperate views for say another consumer of Silverlight is pretty powerful. You can apply the same MVC/MVP pattern inside Silverlight and attain this level of abstraction. Jason mentions an example of being able to create a seperate view for an iPhone and only the View component has to change. This applies to Silverlight as well for different things. For example, I have large sized Silverlight app I want to port to SharePoint. I can create a "Smaller View" for SharePoint so it fits nicer into the UI. Furthermore, Silverlight Mobile is being private tested now. I would assume that same very powerful level of abstraction applies as well to create a "Mobile view" for your Silverlight application.
Unit Testable
o Silverlight includes a Unit Test framework as well. It can be downloaded here: http://code.msdn.microsoft.com/silverlightut/
Challenges if you are not running IIS 7
o Silverlight does NOT care if you are not running on IIS 6 or IIS 7 or Apache for that matter. This is one feature where Silverlight has an advantage over ASP.NET MVC.
Client Caching
o In ASP.NET Web Forms or MVC, you are caching on the server. Silverlight allows you to cache on the client via Isolated Storage (which can be increased to hundreds of megs if necessary). This allows applications to perform ultra fast without bogging down the hosting server.
CONs vs. ASP.NET Web Forms
Difficult to convert existing code
o Silverlight is a completely different programming platform than either ASP.NET WebForms or MVC. Not only will a lot of the code not convert, you also have to think about the client layer and in most cases a complete re-architecture is needed if you are replacing large modules inside your existing ASP.NET site.
NOT the best SEO out of the box
o Google several months ago started spidering SWF files and adding them to the search engine. I think Silverlight is probably still a ways away here. What you can do for Silverlight SEO is the basic tricks to describe the meta data tags really well around the plug in.
Data access
o Data access in Silverlight is limited to Web Services/WCF/ADO.NET Data Services. You cannot make direct calls via ADO.NET or stored procedures to a database.
Security
o Silverlight runs on the client. A lot of your bits are then roaming in the wild on the internet. Furthermore, some of the data access techniques do not support full WS* standard security. Therefore, beyond certificate based transport security, you are either writing a lot of your own plumbing code or waiting for the next rev. The XAML code is pretty much insecure; not many applications have their Intellectual Property in their UI. In Silverlight, that can be very easily reverse engineered using Silverlight Spy for example. Silverlight, just by nature, is a little less secure than an ASP.NET MVC application. Obviously, you would want to encrypt/obfuscate your Silverlight assemblies before letting them off in the wild.
1. Silverlight can access the DOM from the hosting page and
2. the hosting page can access the Silverlight part.
That's a big + for Silverlight
But all other limitations cry for WPF/Windows-Forms with Clickonce
file access, right mouse click, ease of db access
The pros
The Silverlight plug-in means developers can target a single, consistent runtime for browser-based applications, rather than dealing with the complexity of multiple browsers in different versions. You also get video and multimedia effects that are hard or impossible with pure HTML and JavaScript, though Adobe Systems' Flash has the same advantages.
Execute .NET code without deploying the .NET runtime. The Silverlight plug-in does include a cut-down .NET runtime, but instead of dealing with a large download and the complexities of the Windows installer, the user has a small download of about 4MB, all handled within the browser. In my experience so far, installation is smooth and easy.
Performance is promising. Silverlight comes out well in this prime number calculator, thanks no doubt to JIT compilation to native code, though it may not compare so well for rendering graphics.
Support for Moonlight means there will be an official open source implementation of Silverlight, mitigating the proprietary aspect.
Silverlight interprets XAML directly, whereas Adobe’s XML GUI language, MXML, gets converted to SWF at compiling time. In fact, XAML pages are included as resources in the compiled .XAP binary used for deploying Silverlight applications. A .XAP file is just a ZIP with a different extension. This also means that search engines can potentially index text within a Silverlight application, just as they can with Flash.
Third-party component vendors are already well on with Silverlight add-ons. For example, Infragistics, ComponentOne and DevExpress.
Take your .NET code cross-platform. With Macs popping up everywhere, the ability to migrate Visual Basic or C# code to a cross-platform, browser-based Silverlight client will be increasingly useful. Clearly this only applies to existing .NET developers - I guess this is the main market for Silverlight, but it is a large one. The same applies to the next point:
Uses Visual Studio. Microsoft’s IDE is a mature and well-liked development environment, and since it is also the tool for ASP.NET you can use it for server-side code, as well as for the Silverlight client. For those who don’t get on with Visual Studio, the Silverlight SDK also supports command-line compilation.
Choose your language. Support for multiple languages has been part of .NET since its beginning, and having the .NET runtime in Silverlight 2.0 means you can code your client-side logic in C#, Visual Basic, or thanks to the Dynamic Language Runtime (DLR) Iron Ruby or Iron Python.
Isolated storage gives Silverlight applications local file access, but only in a protected location specific to the application, providing a relatively secure way to get this benefit.
The cons
If Apple won’t even allow Flash on the iPhone, what chance is there for Silverlight?
Silverlight is late to the game. Flash is mature, well trusted and ubiquitous. Silverlight 2 only comes out of beta in the Autumn (we hope). It is the version we care about - the one that includes the .NET runtime - and will still lack support on mobile devices, even Windows Mobile, though this is promised at some unspecified later date.
The design tools are Expression Blend and Expression Design - but who uses them? The design world uses Adobe PhotoShop.
While having solution compatibility between Expression Blend and Visual Studio sounds good, it’s actually a hassle having to use two separate tools, especially when there are niggling incompatibilities, as in the current beta.
No support for the popular H.264 video codec. Instead hi-def video for Silverlight must be in VC-1, which is less common.
It’s another effort to promote proprietary technology rather than open standards.
Yes Linux will be supported via Moonlight, but when? It seems likely that the Linux implementation will always lag behind the Windows and Mac releases.
Silverlight supports SOAP web services, or REST provided you don’t use PUT or DELETE, but doesn’t have an optimized binary protocol like Adobe’s ActionScript Message Format (AMF), which likely means slower performance in some scenarios.
Silverlight is a browser-only solution, whereas Flash can be deployed for the desktop using Adobe Integrated Runtime (AIR). Having said that, yes I have seen this.
You have to develop on Windows. This is particularly a problem for the Expression design tools, since designers have a disproportionately high number of Macs.
You can add to the pros and cons of the usual stuff of the online vs offline debate. Some items:
Pros
wpf(offline):
better access to low level parts of the computer.
cpu usage is local, so you rarely have cpu load issues.
not dependent of the net.
no downtime for maintenance.
silverlight(online):
Better control of users. If your users login, you dont have to worry with activation keys or similar stuff.
It works on Windows and Mac.
You can update all your users apps easily.
I simplified it a bit, there are gray areas in the list. I only tinkered with XBAP, so that one I'll leave out. The Cons are not hard to figure out after looking to the pros.
HTH
I would consider WPF ClickOnce with sync framework support (www.msdn.com/sync). This would allow you to support limited functionality when the user is not connected to the corporate network (which will eliminate any browser-based deployment scenarios, such as Silverlight and XBAP).
If you don't need all WPF I would try do it in Silvelight first Then you can switch to WPF more easily if you need it later.
Here I think it applies the “less is more” principle: it’s true that with WPF you have much more options and can access to the user computer, but that can finally be more a problem than a help as the times go. Think for example in how many changes you can need to change from Windows XP to Vista in an application that uses a lot of the “user computer” resources!
Mark, what do you mean when saying 'single browser' for XBAP? XBAP does work with Firefox for example. It indeed requires .NET Framework and it is unlikely that we will have WPF in Mono anywhere soon (if ever) so you are stuck with Windows, that's right.
Isn't click once available on firefox these days, via this addon: https://addons.mozilla.org/en-US/firefox/addon/1608
Related
As far as I understand, I can use Windows Forms in Windows 8 Pro (non-RT) applications. However I was wondering if I can develop an app which has a nice WinRT interface for the main part as well as a WinForms part for the more complicated parts which benefit from stuff like TreeViews and which are complicated and useless to reimplement. Which development environment would I need for that?
Windows Store Applications are intentionally limited and do not include the entire .NET Framework, including Windows Forms, and WPF/Windows Presentation Foundation. You cannot mix the two components. They are executed and managed in very different ways (see here for details about how Windows Store apps are executed).
However I was wondering if I can develop an app which has a nice WinRT
interface for the main part as well as a WinForms part for the more
complicated parts which benefit from stuff like TreeViews and which
are complicated and useless to reimplement.
Even communicating from a traditional Win32 application to a Windows Store application is prohibited (for applications released via the Store -- see here for a discussion). So, building your application in two pieces really isn't very practical (and the user experience of swapping between the two applications may be unpleasant for many users).
There's an intentional design and usability model for designing a Windows App Store application that must be considered when developing a touch friendly application that does not lend itself to a typical Windows Forms application. Tree views for example might be replaced with a group/detail/detail type navigation.
I'd highly recommend you read through, if you haven't already, the UX guide for developing Windows Store apps. A transition between a modern UI application and a Windows Form application would be jarring to say the least, unless you spent an tremendous amount of effort trying to mimic the general UI principles established for a Windows Store application. While it's possible to do, and there are some 3rd parties that may provide reasonable components, it's never really going to be truly the same (and probably not worth the engineering effort to try to make it identical).
Some might suggest that you consider instead using WPF. Depending on the type of application and the current skill set of the developers, that might be a good fit for your needs. Again, there are 3rd party resources for mimicking the style of a modern Windows Store application that you could apply to your application if desired.
There can be a very steep learning curve for WPF if you have a reasonably complex data-entry/manipulation style application where you may need robust data validation, etc., typical of a line-of-business application. It's also hard to tell where Microsoft is going with technology these days -- WPF, while not deprecated, certainly isn't being enhanced like it once was. As Visual Studio 2012+ depend on it heavily, WPF isn't going away, but expect fewer new features. It's a robust platform generally speaking though, and it may meet your needs as is.
You may want to go through the exercise of modeling your application as a Windows Store application to see if the widgets and functionality you would need are present. Depending on your requirements, you may find that not everything is there yet (Windows 8.1 has some new goodies, so look at those too!).
Also, if you're familiar with JavaScript, you might also want to look at creating your application using WinJS. It's super powerful and can often use many existing JavaScript/HTML solutions, assuming they meet your UI and functional requirements.
WinRT UI components can only be used in windows store apps and Windows Forms only in desktop apps so you will not be able to mixed both.
If you are looking into making a desktop app for windows 8, maybe you should look into using WPF.
If you are looking into making a windows store app, there is plenty of third party control libraries which have a TreeView including the WinRT xaml toolkit .
I have a COM control that wraps a lot of client side functionality, i.e. using input devices to gather information, integration with different devices, report formation, etc... I would like to wrap this inside a .NET control of some sort and add it to an ASP.NET application. The wrapper will be responsible for speaking with our database located on a server and also contain a little business logic. Does anyone have a good general or even better a specific direction I should be heading in? I am using C# in .NET and the COM object is in C++.
BTW, I have tried to create a windows forms control Library and hosting it in a ASP web app but I have had no success with that.
You might host an ActiveX inside a webpage. ActiveX is COM - but there are limitations what an Active control can do when hosted inside a browser. Browsers are commonly developed with sandboxing in mind, so you might run into serious problems in regard to security settings. Another aspect is cross browser capabilities. WinForms is definitely another world, so even if you find a way to display some sort of a simple form, you're most surely ending up somewhere between mess and boom.
From what you told in your question, I think your best option is to stick with a classic desktop application. Apparently, this does work for you, and changing the way the application behaves isn't an option besides the fact, that a rewrite is too costly. Migrating a rather complex app to the web, with it's radical different programming approach compared to classic desktop applications, won't go along with limited amount of resources (money and/or human).
That said, if you're going to take the burden of mess and boom, you might want to look at that information:
http://codebetter.com/petervanooijen/2007/06/18/including-a-winforms-user-control-in-an-asp-net-web-page/
http://www.codeproject.com/Articles/4953/Simple-way-to-expose-a-NET-WinForm-control-as-an-A
Note, the articles are rather old and don't solve the problem, that the ActiveX / COM stuff used by the form has to be registered on the client machine (as well as issues like accessing servers that may or may not be in the same network anymore). And you can't be sure about security settings.
You appear to be confusing the difference between System.Windows.Forms (WinForms) which run on the desktop within the Windows OS, and System.Web.UI (WebForms) which run under IIS within a very different security environment in ASP.NET. Just because many of the form properties and such have been made to look similar, it does not mean they work anything alike internally - and in fact, they most certainly do not. You need to take a closer look at how WebForms work within ASP.NET to begin to understand why, as SLaks pointed out for you already, that what you are attempting to do cannot work in the manner in which you are suggesting.
This question is specifically related to a recommended architecture and people's previous experiences for cross-platform WP7, iOS, Android apps developed using C#, Monotouch and Monodroid respectively. I have researched previous questions here, here and here. They provide good answers but not quite what I'm looking for. I have also found this excellent question which does go into the cost benefit so there is some overlap.
I have a requirement to develop a cross-platform iPhone/iPad, WP7 and android app for a health & fitness company, which will integrate with their website. The app requires a small amount of local data storage for offline mode and synchronisation with the website when a network is available. I am a Windows (C#/C++) developer through and through and don't really want to go down the route of three Objective C, Java and C# apps, although I will if I have to. I will also be operating as tech lead and farming out some work to a team on this project.
I would like to know if anyone here has experience with cross-platform development using Monotouch, Monodroid and WP7 and to share their experience on application architecture to re-use as much code as possible. The architecture I am considering is as follows:
My question is as follows:
Has anyone here tried something like this?
Are these frameworks (Monotouch, monodroid) worth their salt for this sort of work?
Can I setup the entire project in Visual Studio 2010 with separate projects (dlls/exe) for the Monotouch, Monodroid and Wp7 target (but shared code using 'Add as Link')?
What sort of code-reuse can I realistically expect with this (or a similar) architecture? i.e. what strategies/patterns can I use to re-use local data access, webservices, and business logic?
You might want to look into the MonoCross project which is designed to help you reuse C# code with multiple presentation layers:
http://code.google.com/p/monocross/
The authors of MonoCross (ITR Mobility) have created multiple mobile cross platform solutions for a variety of customers and have written two books on the subject one is "iPad in the Enterprise" (http://amzn.to/zAhQK6) and the upcoming "Cross-Platform Mobile Development with C#" (http://amzn.to/wM6RsF).
In the meantime, you can watch Scott Olson's presentation that he did at Monospace 2011 that describes how to use MonoCross to target multiple mobile and desktop platforms at once reusing the business logic:
http://www.infoq.com/presentations/The-Rise-of-Mono-in-the-Enterprise
They enforce a strict MVC split in their code:
(source: tirania.org)
The biggest benefit of designing an application with this model is that you can run the same application with native user interfaces on each platform. You get native iOS, Android, Windows UI and they even have an ASP.NET front-end that allows you to publish Web versions of the same business logic.
This technology was used successfully by the Medtronic sample app that is showcased by Apple in their iPad business:
http://www.apple.com/ipad/business/profiles/medtronic/
I suggest you also check out Scott's blog where he posts regularly about his experiences with cross-platform architecture.
Based on your comments your requirements are for a cross-mobile platform that will integrate with their existing services, but also work offline. You are specifically interested in C# via Mono, however you have indicated that you are not discounting other approaches.
I feel that HTML / PhoneGap / JavaScript is a route that you should explore in some detail. The WP7 version of this framework has just been released, and I have had experience of releasing an application to the marketplace using this approach.
PhoneGap wraps your HTML / JavaScript code, in the case of WP7 this is loaded into local storage. This enables the application to work entirely offline. This is true for all versions (iOS, Android etc...)
Probably the biggest issue with PhoneGap / HTML5 is the same issue we have when developing complex web based applications for the browser. The tooling for JavaScript is not great and browser differences are a constant issue. However, it is a tried and tested solution.
Finally, it is possible to create an application UI that is entirely different for each platform. By using the MVVM pattern I have managed to share all my JavaScript business logic between WP7 and iOS applications whilst having a totally different UI:
Compare this to the WP7 screens:
NOTE: I plan to have the iOS version of Property Finder in the AppStore shortly, I just need to work out how to use PhoneGap Build!
Just adding another alternative to the mix - mvvmcross
This project was developed out of experiences with monocross, mvvmlight, and opennetcf.
It's quite an opinionated mvvm framework (with my opinions in it!), it includes data-binding support for Droid and Touch, and it really does encourage code reuse between the platforms.
The source is available from https://github.com/slodge/MvvmCross, it's been used in at least a couple of large projects already and it's still under active development.
There's an introductory presentation on it on slideshare: http://www.slideshare.net/cirrious/dev-evening-monotouch-monodroid-mvvm-mvvmcross-and-databinding
One of the more fully featured samples is a conference app:
The question is very hard to answer, yet I would like to share some thoughts.
The situation with the mobile development is very similar to the development at the first half of the 90s. Phone have limited resources as computers had, mobile OSes are making their baby steps, hence the ecosystem is relatively small. They have own philosophy, tools and even languages. And this is a good thing, but leads to a headache for cross-platform development. As a result, there are many attempts to clear this a bit. People build frameworks, wrappers etc. which is a kind of abstraction and abstractions are leaky. This is extremely important for mobile devices not only the performance as numbers of CPU cycles, but also the performance of the battery, which is far more important for the user.
If I were you I would build apps in a native environment especially if you have some performance considerations. Best support, tools, educational resources etc. pays for the duplicated business logic. All in all, it's not a OS or Database Management System, codebase won't be huge ;)
That being said. Regarding Monotouch and Monodroid I would be very careful since Apple blocks iPhone OS apps created by many third-party compilers and The King doesn't really care about developers. The case that mono will be flushed to the toiled by patent infringement or proprietary software vendors is very likely. This is sad for me cause C# is my favorite language.
PS. I don't believe that HTML5 for mobile will take over any time soon.
I have been doing ASP.NET / C# development for several years now. I have recently been offered a project that will need to be a winforms application (I am assuming .net 2.0).
Specs:
Winforms applicaton
Application will
have "testing for understanding
questions"
Must support flash and camtasia
files (these are "lessons")
I have done winforms development before, although nothing that is this involved. As there is a potential need for this application to be generic enough to apply to multiple different "disciplines", I would like to make the application generic enough to be easily configurable. The caveat here is that the application will need to be run from a CD-ROM and that I cannot rely explicitly on an internet connection. I was thinking of using something like SQL-Lite to support the configuration of the application. There will not be the need for updating the application as it will not be updated (at least I don't think, I guess there is the possibility of the application calling a webservice and configuring its-self based upon returned values).
With the requirements of supporting Flash and Camtasia, along with making this application generic enough to support different "disciplines", and my self being an ASP.NET developer, does anyone have an recommendations or tips/ tricks to look out for? Has anyone done something like this before?
Thanks in advance.
I'd start by writing a user control that can be used to either display a video file (presumably the output from Camtasia) or a Shockwave app. Once you have that user control, I'd then move on to look at the overall app.
If you're using Winforms, and the software is supposed to run from the CD (instead of merely be installed from CD) you'll need to have the DotNet framework already on the computer I think - but then I'm not an expert in deployment.
I find the application model in Winforms to be a lot easier than WebForms, but then I was "raised" in thick clients, so I suppose I would.
I would also, whilst agreeing to WinForms if needs really must, encourage the client to give consideration to using WPF instead - which opens up the idea that you could also provide access over the web using a simlar interface using Silverlight...
Just a few thoughts anyway - good luck with it...
I need to write a web app (that also works offline) for windows and mac (and linux as well perhaps).
I was wondering if I should use something like air/flash/java for this, the advantage being I will only need to write the app once.
However, I was wondering if there are any disadvantages of doing it that way as opposed to writing it in c# for windows specifically and then objective-C/cocoa/whatever for mac. Will the functionality of the app be limited if i do it in Air/Java? Are there any advantages to writing it in the language specific to the platform?
If possible it would be nice to know what the advantages/disadvantages of both methods are as it would help me (and hopefully others) come to a decision on the best way to create such an app according to ones needs.
Any help would be much appreciated! Thanks.
The first thing to realise is that writing cross platform applications that look and behave native on each target platform is a hard thing to do.
Using a cross platform kit (AIR/java):
Less work, in theory should be quicker to build
Common language and toolkit, only one thing to learn
Adding a new supported platform should be easy(ish), build installer, debug provide any native platform integration etc
There is a tendency towards only implementing the lowest common denominator feature. An example of this would be the java File api. It only supports the basic concepts of files where as Windows, OSX and linux all have addition
May still require platform specific integration code (maybe native) in order to get an acceptable level of integration.
Using the native toolkits:
A lot to learn, moving between Windows MFC (or .Net winforms) and Cococa is going to be quite jaring
Not only will you have different languages, you will also have different tooling
There is no limit or false ceiling to what can be achieved using the native toolkit gives you access to everything
Making your app look like it belongs on the platform (important for Macs) is pretty much out of the box
Personal recommendation: go with the language tool kit you know the best, depending on how thick your app is (you mentioned it's part online) you may be able to rewrite it in another language latter once you have a successful application.
Much depends on the kind of app you will be writing. I use Adobe AIR for a lot of in-house tools.
If you write for AIR what you'll get is something that looks like a web page. That's fine, because people feel at home operating a browser interface--maybe even more at home than with a native app.
But, yes, you'll absolutely have limitations.
So what's your app?