What is the difference between Visual Studio LightSwitch and WinForms?
Why we should choose one over the other?
Update: I understand that LightSwitch is an application framework. May be the better question is, how a LighSwitch application compares to a windows forms application built with Composite Application Block (CAB)
Lightswitch is a template driven application development environment for Visual Studio. It creates Silverlight applications that use a View-Model architecture, using Entity Framework and RIA services for data access.
The applications can be run locally on the desktop with a local data store, or with a data store on a server, or run in a browser with a data store on a server.
The Lightswitch framework includes designers to create and manage most aspects of an business application such as:
Data model with validation and relationships
Screens
Menus
Queries
As of Beta 1, there is no built-in reporting engine
It's scope remains to be seen, but I believe it's targeted for development of corporate in-house applications, such as CMS systems, billing systems, etc. and also line-of-business applications, small and large scale.
WinForms or Windows Forms is the graphical API for .NET that lets you create user interfaces with forms and controls, etc. It's not a complete application development framework.
This thread compares LightSwitch to building line-of-business applications in Silverlight today:
http://social.msdn.microsoft.com/Forums/en-US/lightswitchgeneral/thread/3f6161b6-33a3-4b6a-a4d8-ea693d6ba273
This video gives a high-level overview of LightSwitch
http://www.microsoft.com/showcase/en/us/details/74ed35cb-709b-46f7-8b21-2f681965ed0b
Sorry Carlos, but LightSwitch does not generate either WinForms, or WebForms projects. The only official client technology is a Silverlight client, whether it is a web application, or a desktop (OOB) application.
In the very early days, I believe the client was originally WPF, but that was changed to SilverLight some time ago.
While LS does "generate" code, it does so for its own use, not for consumption external to LS.
One imortant distinction between Lightswitch and Composite Application Block UI, is that CAB has been retired and is no longer developed.
Reference: http://msdn.microsoft.com/en-us/library/aa480450.aspx
Related
I know that it's possible to use WPF for web development but are there any circumstances in which it would be better to use WPF? Or is it more common practice to ASP.NET Forms/MVC?
I know that it's possible to use WPF for web development
Wrong. WPF is part of the .Net Framework. It is a Windows Client technology that requires the target computer to have the .Net Framework installed in order to run.
Web applications consist of a Web Server delivering Web Content (HTML [+Javascript+CSS]) to a Web Client (Browser).
WPF has nothing to do with that. It does not produce HTML or any other Web content and it is not a Server Side technology.
Bottom line:
Use Web technologies (A server side technology that outputs HTML (such as ASP.Net MVC)) if you need to create a Web Application.
Use WPF if you need to create a rich, highly interactive Windows Desktop application.
Use WinRT XAML (similar to WPF) if you need to create a rich, highly interactive Windows "Metro Style" application.
In addition to what #HighCore said, it's possible to use technology similar to WPF in a web environment. For example, Silverlight uses XAML markup. It's kind of similar to a Java applet if you're familiar with those. Silverlight is particularly handy for doing something that requires a lot of graphics or media in the browser, but it's not as full featured as WPF. In addition, you have to hope that the user has a Silverlight plugin which isn't available on all platforms. For example, Linux and mobile have limited or no Silverlight capability.
You could develop a WPF application and deliver it as a ClickOnce application. You're pretty much limited to Windows targets.
If you're trying to develop a website, then stick to ASP.NET Web Forms or MVC or some other server side technology that serves HTML to browsers, as HighCore said.
I am developing small institute management system as an academic project in my college.
I am going to develop the project in silverlight 4 or 5. In this project I want to provide attendance facility; i.e students will able to log in application from their respective machine which will be connected to LAN. There will be no internet connection available.
Can I develop this application which will not required internet connection once it is installed but can still accessible to different machine which are connected in a network over a LAN
1.How can I achive this?
2. should I use silverlight out of browser app or simple silverlight app
3. Is there any way to achive this using WPF?
After some research I found out the concept called Intranet which should solve my problem of sharing of source code and database.
About what technology should be used:
its better to develop this application in Silverlight as it is nothing but a subset of WPF.
Even better to develop the app in both technology to start with as I can use same XAML for both technology with few or no changes at all.
Connecting to database will be simpler in WPF than in Silverlight, as the later does not connect to the database directly and needs a service to achieve this. This service can be written using WCF or Ria service even in a php.
#Ash,
Silverlight can be desktop oriented, same as WPF. Caveat in some respects is that Silverlight is simplified to utilize Web Services communication, just like Adobe Flash is.
WPF is more oriented to non-Internat (ie Intranet/LAN) connections but pretty much utilizes the same .Net framework as Silverlight.
Although Silverlight is more platform independent than WPF, they operate the same.
You can take a Silverlight application and transition it to WPF with little to no changes (pending on the complexity of your application) to the code-base.
One benefit for WPF over Silverlight is the ability to utilize Click-Once deployment and Version control. Although you can implement a Click-Once styled Silverlight deployment it doesnt work the same as the majority of the Click-Once deployment models out there for the Desktop applications.
I hope this helps you.
I'm in the early planning stages of an internal application and I'm considering ASP.NET MVC and Silverlight 4 as my possible platforms.
The Environment
We're a Microsoft shop and we're in the process of migrating desktops to Win7 (from XP) and servers to W2k8, I'll be able to get Silverlight 4 installed as part of our baseline Win7 build
The Application
Provide a dashboard to monitor system status
Monitoring third party connections
Monitoring database tables for particular events
Monitoring SQL Server Log Shipping
...
Provide portal like access to system tasks to end users
Bulk updates to databse rows
Running SSRS Reports
Re-running automated tasks that have failed
...
The Team
We're a small team of 2 and neither of us have production exeprience in Silverlight or ASP.NET MVC so we'll be learning whichever we go for.
What would you pick and why?
The answer really depends on your experience. If you are an experienced web developer and have a lot of practice with ASP.NET then use that for sure. If your background is WPF and WinForms then use Silverlight.
My experience is that the ramp up time to use Silverlight for an ASP.NET developer is significantly longer than it is for a straight .NET application developer. The ASP.NET developer has to unlearn a great deal before they begin because the development paradigm for Silverlight is more akin to app development.
The other alternative is to use both. ASP.NET for the navigation, authentication, general layout and Silverlight for the data realisation (graphs etc).
I would pick ASP.NET MVC. I have experience in both Silverlight and ASP.NET MVC and Silverlight undoubtedly has a steeper learning curve. While it will definitely enable you to develop rich user interfaces (it enables amazing composition) it may be overkill for an internal application.
ASP.NET MVC on the other hand will enable you to do what you are aiming to achieve but I believe (due to the learning curve) you'll be able to do so MUCH more quickly. It is also much easier in my experience to enable dependency injection and write unit tests for ASP.NET MVC than it is for silverlight which may or may not be a consideration..
Silverlight. I think ASP.NET MVC more for public websites, whereas internal applications - Webforms or Silverlight in your case.
Silverlight - Desktop > Web for applications (not for simple data presentations though) whenever possible. The bad news is that desktop is not always possible. The good news is that it is possible for you. You can even use the out of browser features which is even cooler.
Use Silverlight with the MVVM pattern.
With the new Silverlight 3.0 feature that allows the components to be hosted outside of the browser, our company is looking for details on the differences between this new feature and WPF Windows applications (since Silverlight is partly a subset of WPF).
Is there a good resource that lists the differences between Silverlight 3 outside of the browser and WPF applications? Areas like permissions, functionality, etc.
If there is no web resources, what are some of the key differences?
Silverlight OOB applications have the exact same capabilities as an in-browser Silverlight application, except they lose their ability to communicate with the DOM (via the System.Windows.Browser API).
Here is a brief list of some common things that you don't have access to with Silverlight that you might be planning on using in a WPF application:
Client File System
Client Windows registry
Client Event Log
Client OLEDB
Client SQL Client
This may seem like a long list but it should look fairly familiar to the no-can-do list for any web application platform (a la ASP.NET, JSP, PHP)
Jaime Rodriguez has a very good post covering the key differences and features of both Silverlight and WPF: Here. It's very high level and meant to differentiate between features that a WPF and Silverlight Out-of-Browser application bring to the table.
markti is correct.
Scott Barnes - Rich Platforms Product Manager - Microsoft.
I'm trying to get my head around the many application deployment options which Microsoft currently offers.
Doing a little research turned up dozens of confusing terms:
"WPF App"
"ClickOnce App"
"WPF ClickOnce App"
"MSI App"
"XBAP App"
"XBAP App deployed with ClickOnce"
"Installed ClickOnce App"
"WPF Web App"
"ASP.NET Web App"
"ASP.NET MVC Web App"
"Silverlight App"
"Full WPF App"
"ClickOnce with sync framework support"
I cleaned up my findings into seven separate approaches below. Would appreciate feedback:
"WPF App deployed with MSI" (allows lots of installation options)
MSI runtime required on target computer
wizard with options
can specify per-user or per-machine
can modify files and registry on target computer, limited only by access permission set by administrator
can place shortcut on desktop
replacing system files, etc. makes it easy to get into DLL hell on the target computer
updating is a big negative: detecting available updates requires additional tools / custom programming, not built in
user does not have to be online to use application
"WPF App deployed with ClickOnce": (good if you want automatic update but runs in sandbox)
requires two clicks (click hyperlink, click yes), no user input
only for current user, no per-machine installations
no shortcuts on desktop
appears in program list like normal applications
applications files are always copied to ../My Documents/My Applications
a shortcut to your application will be put in Start menu / your company name
cannot modify the target computer, isolated from operating system
automatically detects and updates a newer version
published simply by putting them on a webserver (where clients detect and get them)
requires .NET 2.0 or later
comparable to Java Web Start
solves four problems: (1) easy deployment, (2) easy updating, (3) low-impact on target computer, (4) no need for administrator permissions.
considered "low impact"
if two users have the same ClickOnce application installed on the same machine, they will not break each other
employs CAS for security
user does not have to be online to use application
standalone ClickOnce apps do not work on Firefox and Mac with Firefox now since it needs the .NET runtime
restricted to single-window apps since they run in the browser
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).
"XBAP App": xcopy deployment of .xbap file, IE and Firefox display it instantly like a web page
the real goal of the XBAP model is to create a WPF equivalent to the traditional HTML-and-JavaScript website (or Flash applet)
the target computer simply runs the application without installation over the web in their web browser (IE or Firefox)
They're good for Intranet applications where you want really easy deployment, the complete .NET Framework (as opposed to Silverlight) and a browser's navigational model.
99% WPF features (as opposed to Silverlight's subset of WPF features)
CAN be automatically deployed via ClickOnce as well but XCOPY is more common
YourApp.xbap is really a ClickOnce deployment manifest
run in sandbox
user must be online to use application
these must be "page-based" applications as opposed to "windows-based" applications
"An XBAP appears to run inside the brwoser simply because it displays all its content in the browser window. This is different from the model used by ActiveX controls (and Silverlight), which are loaded inside the browser process."
XBAPs offers a "prompt-free" experience, as long as .NET 3.5 is installed, it just shows up in the browser like a web page.s
XBAPs are not allowed to use WinForm controls via Interop
not allow to use windows drag and drop
most advanced WCF features are NOT allowed and XBAP can't communicate with any server other than the one where the XBAP is hosted
"if your application requires full trust, you should consider building a stand-alone WPF app and deploying it using ClickOnce" (Pro WPF in C# 2008)
trick: you can embed multiple xbap applications into multiple iframes on one HTML page.
"Silverlight App": runs in client's browser and uses downloaded 4MB subset of .NET framework, i.e. no 3D)
cross browser (applications can be used by Opera and Safari as well)
updating application is as easy as with ClickOnce or XBAP
single window apps
application is in the sandbox of course
async only
"ASP.NET MVC with JQuery/AJAX": a new development platform equal to development in WPF in terms of RAD and TDD
this approach is worth considering along with the WPF/Silverlight approaches
"ASP.NET App": classic web application with ViewState, etc. probably will be used less and less as ASP.NET MVC gains acceptance
"WinForm App": classic windows application, will be used less and less as WPF gains acceptance
I would particularly appreciate feedback on:
how reusable are controls (e.g. if we develop in Silverlight, can we reuse our code/controls in XBAP?)
what is the best approach to clients which are sometimes offline, sometimes online AND need access to WCF (probably clickOnce apps I would think)
Great Summary, Edward.
Much of the code in Silverlight can be directly used in WPF & WPF XBAP apps because Silverlight is a subset of WPF. For XAML, you will have to change the namespace URI and probably have to do some slight manual tweaking.
For XAML to Silverlight conversions, you will have to do change the namespace URI as well but refactoring might be necessary if WPF elements are used that are not in Silverlight.
WPF and the Sync Framework are great options for online/offline applications. See the Syndicated Client Experience Starter Kit for an example of a WPF/Sync Framework app. Also Silverlight + Windows Live Mesh will provide online/offline capabilities.
AppStart experience:
MSI =
Only Windows. Many clicks. Install before use. Good for very huge and resource intensive apps. App can be distributed on dvd. App can do everything. No technology restrictions.
ClickOnce =
Only Windows. Can be activated from webpage. Is downloaded once. Keeps info abouts it origin (Server) and can automatically update. App is restricted. Needs .NET
Silverlight =
Runs on Windows/Max/Linux(soon) and future Mobiles(planned). Is a webpage or can be embedded into html. Code is on Server and will never be installed. Needs Silverligth-Runtime. Provides subset of WPF
XBAP = Like silverlight but only for windows. Nobody will need that. Silverlight is better
Programming technology:
Silverlight =
Runs on client maschine. Uses WPF*
ASP.NET =
Runs on server maschine in .NET but Javascript/html on client maschine.
WinForms = old technology
WCF = won't work for browser based apps. Is for distributed apps. One could open up all doors into client mashine. Using WCF = needs MSI.
WCF provides a good framework for server. You will never need WCF on client when you use REST for interfacing. The client can be connected/disconnected in ClickOnce and MSI installed apps. You have to connect to a webpage for appstart in silverlight and ASP.
XAML can be reused for silverlight/wpf/xbap. Minor changes in wpf/silverlight. No changes in wpf/xbap as I know.
The deployment options MS supports for client applications are
MSI (Any Windows app)
Clickonce (only for .Net client apps)
Clickonce is not WPF specific.
XBAPS are clickonce deployed, browser hosted WPF apps in a trusted security sandbox.
WinForms apps can be clickonce deployed and can be browser hosted.
Silverlight is (mostly) source compatible with WPF. You can recompile SL controls as WPF controls.
Non browser hosted clickonce is probably a good fit for you.
I wouldn't be so quick to dismiss XBAP as "Silverlight for Windows only". Because it uses the complete WPF set, it is possible to use the same codebase for both a WPF App and an XBAP, as long as you work within the Partial Trust restrictions imposed on XBAPs.
Also, as of .NET 3.5, WCF does work in XBAPs under Partial Trust. You can't do as much as in a full trust WPF App, but it is still useful.
You listed "MSI App". Windows Installer is Microsoft's technology for installing and upgrading programs on Windows. The installation packages it creates have the ".msi" extension. (It was originally going to be called "Microsoft Installer". They changed it to "Windows Installer", but keep the extension.) It defines a standard way to create install packages. Packages can be created by many different tools (InstallShield, WiX, Visual Studio, etc). It's not limited to WPF apps. You can use it to install almost any kind of application.
Another deployment option made available by the Live Framework (Live Mesh vNext) is the Mesh-Enabled Web Application (MEWA). This lets you package up Silverlight, DHTML, and Flash apps to run online in the Live Desktop or online/offline on the Windows desktop. You can install a MEWA into your Mesh and have it automatically deployed to all the devices in your Mesh. If a new version of an app is released, the update can be synchronized to all devices as well.
There are hints that in addition to Silverlight/DHTML/Flash, future versions of Live Framework will support MSI and CAB packaged apps, presumably with similar deployment features.
Documentation for Mesh-Enabled Web Apps:
http://msdn.microsoft.com/en-us/library/dd199554.aspx