Is there any version problem in Silverlight 3 beta? - silverlight

I have deployed website using silverlight 3.0.40307.0. It is working perfectly in Local IIS. But when client will installs the newer version of silverlight like 3.0.40626 or higher, It wan't be able to view website.
How to get silverlight 3.0.40307 (old version of 3.0 beta)?
What is the possible solution to deploy silverlight website on IIS?
What silverlight component should be installed on server to view silverlight application on browser?
Can we install silverlight TOOL without VS2008+SP1? if yes, then how?

You need to upgrade your version of Silverlight to the released version. You can't expect users to run beta software because you would be forcing them to use software that is known to contain defects.
You need to download the latest version of the SDK and templates from here.

Clients need only the Silverlight runtime plugin for their browser. There's no way you can enforce the client to install the SL 3 Beta version of the plugin you want; and even if you do, there's no (easy) way to prevent it from self-updating to the RTM version. Not only that, but asking clients to install a Beta version of a released product is a security threat for them.
There's no official way to get the SL 3 Beta runtime installer.
An SL app is a client-side code; on the server side you only need standard IIS that serves HTML with an tag and the .xap file for the SL application.
There are no SL components required to be installed on the server for the client to run the SL app.
You can't install the Silverlight Visual Studio Tools without VS2008 SP1 - as their name suggests, the tools are intended to integrate with VS. However, you can install the SL SDK and build SL applications without having VS2008 SP1. (Alternatively, you could use MonoDevelop/Mono/Moonlight to develop SL applications)

If you have deployed your silverlight app that is compiled with Silverlight version 3.0.4.0307.0(i.e. Silverlight Beta), your app may work perfectly for the users with Silverlight 3(RTM).
However, if those visitors come across your silverlight app who doesn't have Silverlight installed at all(or maybe lower than Silverlight 3 Beta), they will be prompted to download Silverlight to view your app.
Once they wish to download Silverlight runtime by clicking on the "Get Silverlight" button, visitors will be redirected to Silverlight download location, and the most important part is
**They will get a message explaining that this app is made with Beta version of the Silverlight.
So this may hamper thier experience and impression about your silverlight app and because of this very few people can get to your app correctly **
It is my suggestion that you try to compile your project with Silverlight 3 as early as possible .
Regarding 2nd question What is the possible solution to deploy silverlight website on IIS?
Here is the Answer : You'll need to register the MIME types for xap on your server.

Related

Silverlight : Client requirements

I am new to Silverlight.
My questions are as follows
I know that Silverlight works with windows OS and Machintosh OS. But does it works with Linux/Unix?
If I run my Silverlight application on a server and access it through a client over the web, does the client need to have a Silverlight plug-in or its installer
With repect to the above point, what happens if I access the same Silverlight application through an Iframe from a normal HTML without having the Silverlight plug-in.
Links to your answers will be appreciated
Moonlight is an option in linux.. and yes you can run silverlight apps in linux http://www.go-mono.com/moonlight/
you will host you app on web server. and of course it will require silverlight plug-in to be installed on it in order to run the application on client.
no silverlight plugin means you can't run silverlight apps.. if you have plugin installed you can even run it in iframe.
Conclusion: in simple words silverlight app is nothing but follows the same requirements like Flash.
Regards.

Setup project for wpf application

I am trying to build a setup-msi using visual studio for my wpf application.
The issue i am facing is that i force primary output from wpf project to the setup project
and the dependencies are calcaluted automatically.
I run the msi locally (on the machine i built the wpf app) and everything works fine.
The problems start when i try to install it on different machines.
On other machines i run the installation process and it finishes justfine
but when i try to run the application i get exceptions about assemblies that could not be found.(e.g System.Web , Version=4,0,0,0 could not be found etc)
I really suck building setup projects but can anybody give a hand?
P.S.: I also tried installShield... same results.
I would guess that the target machine only had .NET Framework 4.0 Client Profile installed. System.Web is in .NET Framework 4.0 Extended, which is installed with the full 4.0 Framework but not with the Client Profile.
Are you bootstrapping .NET 4 in your setup?
Check for the presence of "Microsoft .NET Framework 4 Client Profile" and "Microsoft .NET Framework 4 Extended" in Add/Remove Programs (XP) or Programs and Features (Vista/7) on the machines where the application ran fine and those where it gave that error.
Edit: .NET Framework Deployment Guide for Developers. That should help you figure out how best to deploy it.

Does Microsoft LightSwitch require Silverlight on the client?

Microsoft Lightswitch is a Rapid Application Development environment currently in beta 2. It will be part of the Visual Studio family. There seem to be several different ways to deploy LightSwitch applications. I would like a web only application that clients would access on tablets, and by tablets I mean the iPad. If LightSwitch requires Silverlight that would rule out LightSwitch.
The client layer of a LightSwitch application is a Silverlight application. Thus, you need on Silverlight on the client to run a LightSwitch application.
Currently Silverlight is not available on the iPad and you will not be able to run a LightSwitch application on the iPad. Perhaps in the future the Mono team will make it possible given that Monotouch and Moonlight already exists, but I wouldn't count on it.
Fast forward to 2013 the LightSwitch HTML client is now available as part of Visual Studio 2012 Update 2.
You can create HTML pages. See:
LightSwitch and HTML
http://www.codeproject.com/KB/silverlight/LSHTMLAPP.aspx
The only "official" client technology for LightSwitch V1 is currently Silverlight.
I'd love to see a WPF "option" along side the ability to generate a Silverlight client, but we'll just have to wait & see.
You can easly check it by your self... just 'temporary' turn off Silverlight ( http://geekswithblogs.net/dlussier/archive/2009/04/09/130860.aspx ) and then try to launch your web app in Browser with 'disabled' Silverlight, if it works, then Lightspeed dosn't need Silverlight..
PS: do not forget to 'enable' Silverlight later :)

SL 4 Version Hell? The silverlight developer runtime is not installed please install a matching version

I've been developing for and running Silverlight 4 for about a week. A week ago I installed the Silverlight 4 design time components to develop and debug silverlight for VS 2010 - I posted some of these apps and they were used by users running SL4. Today, I went to a website that told me to upgrade my SL (I think it was the MS expression site) - so I did that and all the sudden I get this error when running SL 4 apps within VS 2010.
The silverlight developer runtime is not installed please install a matching version
Installing the latest version of the Silverlight SDK does not correct this. Basically I am stuck and unable to run Silverlight apps from VS2010.
Are versioning problems like this a common theme in SilverLight? The only thing I can think of is that there is a minor version difference between the versions used on the the MS Expression web site and the version (SL4) I installed from MS site a few days ago? However re-installing the latest version of SL4 does not correct this.
Any help?
The developer runtime is a different download than the normal "end user" runtime.
Again quoting from Tim Heur's Blog, you need to look for the link under "getting the updates" that points to the developer runtime. This will allow you to debug etc.

Is this list a correct understanding of Microsoft's current application deployment options?

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

Resources