Epic Blog of Awesome

code.tech.sci.math.art.write

Tag Archives: silverlight

>Creating RIA Services Solutions

>

Default Solution Structure

In the default solution structure, RIA Services creates a single client project and a single server project. When you create a new project with the Silverlight Application template and select the Enable WCF RIA Services check box, you create a solution with the default structure. A RIA Services link exists between the two application projects. When you build the solution, client code is generated for domain services and shared code. The following illustration shows the default solution structure.

Default Project Structure

The default solution structure is convenient because all domain service types and shared code added to the server project are automatically available to the Silverlight client project after you build the solution. Also, the shared code you add to the server project is visible in the client project. This structure works well when you do not have many domain services in the server project and you do not need to reuse business logic across many different Silverlight applications.

In a solution with the default structure, you can add more Silverlight applications with a RIA Services link to the server project. However, there are limitations of the default structure. The generated code for each Silverlight client can access all of middle-tier code from the server project. For example, if you have three Silverlight applications linked to a single server project and you want to add a domain service that will be used by only one of the Silverlight applications, all three client applications will have a generated domain context for the domain service and will be able to access that domain service.

For more information, see Walkthrough: Creating a RIA Services Solution. For more information about the code generated for a client project, see Client Code Generation.

Silverlight Business Application template

RIA Services also provides a Silverlight Business Application template. This template provides a convenient starting point for building a business application that utilizes Silverlight for the client. The template builds on the Silverlight Navigation Application and uses RIA Services to support authentication and user registration. When you create a project by using the Silverlight Business Application template, RIA Services creates the solution with the default structure. The Silverlight Business Application automatically adds the following features:

  • Login window

  • Registration window

  • Silverlight Navigation

The default authentication mode for the Business Application is Forms Authentication. To use Windows Authentication, you simply change the value of the authentication element in the Web.config file, such as <authentication mode=”Windows”/>, and change the value of the Authentication property on the generated WebContext class. The Business Application template automatically contains code to support either FormsAuthentication or Windows Authentication. For more information, see Walkthrough: Using the Silverlight Business Application Template.

The Services folder of the server project contains the domain services that expose user registration and user authentication. The user registration service utilizes the ASP.NET membership provider to create new users. In the server project, a folder named Models contains classes for defining properties for user and registration data. You can add properties to these classes to customize the user data for your application.

In the client project, the Business Application contains code to simplify developing the presentation layer. The Libs folder and the Controls folder contain assemblies and controls that are used within the template. The Login folder (located within the Views folder) contains the authentication and user registration controls. These controls are automatically enabled in the project. The Resources folder (located in the Assets folder) contains resource strings for text within the project. As you add text to your application, you can add them to the file for application strings.

For more information, see Walkthrough: Using the Silverlight Business Application Template.

via msdn.microsoft.com

Posted via email from Mocha Brain Freeze

>Some Best Practices for Silverlight Application Development (XAML)

>

I was working with WPF/Silverlight since March 2008 and learnt lots of things. I wrote lots of Articles on Silverlight and published in my Blog. Today I decided to share you some of the best practices you should follow while doing development in WPF/Silverlight. Hope, this will help you guys while writing XAML codes. Read and try to strict with the guidelines whenever you are modifying your XAML.

 

Feedbacks are always appreciated. Hence, don’t forget to leave your comments at the end. If you have any more points, please share it here. I will review them and add those here.

 

Update [08-Aug-2010]: On popular demand, I updated this post with some explanation on “Why?”.

 

Some of the XAML coding best practices mentioned below:

  • Don’t use unnecessary “xmlns” namespaces in the XAML file. This overburdens the load time of the Silverlight page (If you are using Resharper, you can do this very easily as it will change the color of the unnecessary items to Grey).
  • Don’t add same namespaces multiple times in a single XAML page. It screws up the XAML code at the time of maintenance and also loads the assembly namespace multiple times causing various memory issues at runtime.
  • Use proper name for your “xmlns” namespace prefix. For example: xmlns:commonControls is more meaningful than xmlns:cctrl. This avoids multiple declarations of namespaces in future.
  • Try avoiding “xmlns” namespace prefix name as “local”. Instead use “localControls” or “localConverters” etc. as per your namespace name. Using “local” will not give you proper meaning. In the same assembly there may be two or more namespaces (e.g. Controls, Converters etc.). In such case, it will be helpful for you to use proper prefix name to distinguish between them in proper way.
  • When adding a control that has no elements inside it, better to close it by self-closing tag “/>” instead of the hard closing tag (</TAG>). This gives more cleaner XAML code. 
  • Remove all unnecessary resource keys if they are not in use. These increases the memory uses and you may sometime encounter some animation issues due to this. If you need it at later point of time, you are always welcome to add it.
  • Don’t use extra panels (e.g. Grid, StackPanel, Canvas etc.) unless it is required.
  • Always try to use Grid as your panel first and if you require other panels, use them. Grid has the flexible UI layout and thus resizing your application will have a great effect.
  • Never try to give a name to all of your controls inside your Silverlight page as it takes unnecessary object creation at the time of load. Name only those elements which you want to use from your code behind and/or from your xaml. If you are using MVVM pattern, you can remove the naming of your controls in almost all the cases.
  • Use the Visibility property of the controls instead of the Opacity property to hide the content. Opacity to zero makes the control to hide but takes space in both memory and the UI. Other side, the Visibility property collapses the control from the UI, thus making spaces for the other controls in the same place.
  • Use proper formatting of your XAML code. This gives better look of code and also easy to maintain in future.
  • Use comments in XAML whenever require. This is useful when you revisit the code after a long time or some other person comes to work with your XAML file.
  • Try to use StaticResource instead of DynamicResource as it increases the performance and also it throws exceptions at development time. Hence, easier to identify the root cause.
  • Remove unnecessary styles & storyboard animations if they are not require at all.
  • Try to add your styles in a separate file if you want to share them across your application. If they are specific to a single page then add them in the page resource.

Save and Share!

Share/Bookmark

via kunal-chowdhury.com

Posted via email from Mocha Brain Freeze

>Debugging Data Bindings in a WPF or Silverlight Application – WPF & Silverlight Designer – Site Home – MSDN Blogs

>

Debugging Data Bindings in a WPF or Silverlight Application

The WPF and Silverlight platforms use late bound data binding resolution for bindings in XAML files. This feature allows a DataContext to be set at run-time and the objects within that DataContext to resolve their property bindings then. This late binding enables cool features like DataTemplates, composable applications and run-time loading of loose XAML.

A side effect of late bound binding resolution that can cause developers some minor frustration is that their controls do not display the expected data at run-time.

This article will explain troubleshooting techniques that can help you locate and correct the problem.

Data Binding Overview

Data binding is fundamental to WPF and Silverlight. You will struggle with your application designs, coding and troubleshooting until you understand data binding in these platforms.

The best data binding resource available is the MSDN Data Binding Overview topic. If you have not read or don’t fully understand the material in this topic, please take the required amount of time to learn this material.

Ounce of Prevention is Worth a Pound of Cure

Visual Studio 2010 has great tooling to wire up data bindings and checked them at design-time. Please read this article: How to Enable Using the Binding Builder in WPF and Silverlight Applications.

Visual Studio 2010 has excellent design-time sample data support. If you use design-time sample data, you’ll immediately see controls that don’t have expected data values at design-time.

For a detailed examination of sample data in the WPF and Silverlight Designer for Visual Studio 2010, please read this article: Sample Data in the WPF and Silverlight Designer.

Troubleshooting List

  • Verify that DataContext is set in either XAML or code
  • Run the application and view the output in the Debug Output Window
    • For WPF applications you can increase or decrease the amount of information displayed in the Debug Output Window by changing the WPF Trace Settings, Data Binding value
  • Name the control that has DataContext assigned, set a break point in the code, and view the named control’s DataContext property in the debugger
  • If binding to a CLR object, put a breakpoint in the source property getter to see that its actually being queried
  • Add a converter to a binding, then put a breakpoint in the converter


Verify that DataContext is set in either XAML or Code

This tip is along the lines of, “if the TV won’t turn on, check that it’s plugged in.”

This is important for many reasons, but one is easily overlooked; if a DataContext is null, the Debug Output Window will not display any error messages in Silverlight or in WPF.

In WPF you can use the below PresentationTraceSources on a binding and set the TraceLevel to High to view errors related to a null DataContext.

View the Debug Output Window

If you have the DataContext set, any data bindings within that DataContext that can’t be resolved will be listed in the Debug Output Window at run-time.

Sample Debug Output Window Data Binding Error

Sample One

System.Windows.Data Error: 40 : BindingExpression path error: ‘FirstName‘ property not found on ‘object’ ”Object‘ (HashCode=62178992)’. BindingExpression:Path=FirstName; DataItem=’Object‘ (HashCode=62178992); target element is ‘TextBox‘ (Name=”); target property is ‘Text‘ (type ‘String’)

Sample Two

System.Windows.Data Error: 40 : BindingExpression path error: ‘FirstName‘ property not found on ‘object’ ”Customer‘ (HashCode=13640894)’. BindingExpression:Path=FirstName; DataItem=’Customer‘ (HashCode=13640894); target element is ‘TextBox‘ (Name=”); target property is ‘Tag‘ (type ‘Object’)

While the above messages look verbose and complex, you can glean several interesting points of information that will help you correct this data binding:

  • The Binding Path is FirstName. Search your XAML file for FirstName and see if you expect the DataContext to expose a FirstName property whose scope will allow this binding to resolve this property.
  • The Source object in Sample One is of Type Object. There is a good chance the Type Object does not have a FirstName property.
  • The Source object in Sample Two is of Type Customer. Check your Customer Type; does it have a FirstName property?
  • Notice in Sample Two, the target property is Tag. In all likelihood, the Text property was the desired target property and not Tag. Also the Type of Tag is Object; you would probably be expecting String when binding to the FirstName property.

Review

  • Verify the property name is spelled correctly
  • Verify the property name has the correct character casing. FirstName is not the same as firstName.
  • Verify the property is a member of the DataContext Type
  • Verify the target element is the correct Type
  • Verify the target property name and Type are correct
via blogs.msdn.com

Posted via email from Mocha Brain Freeze

>Silverlight 4 Training Kit – ScottGu’s Blog

>

free Silverlight 4 Training Kit that walks you through building business applications with Silverlight 4.  You can browse the training kit online or alternatively download an entire offline version of the training kit. 

The training material is structured on teaching how to use the new Silverlight 4 features to build an end to end business application. The training kit includes 8 modules, 25 videos, and several hands on labs.

via weblogs.asp.net

Posted via email from Mocha Brain Freeze

>Silverlight MVVM: An (Overly) Simplified Explanation

>

The Model

image

The Model is where the data for the application goes, The Model can contain:

  • Web Services – A Silverlight application typically needs to communicate with the web server to get the data, you can put your web service methods here.
  • Rest Services – The same as web services.
  • Generic Collections – Basically any data.

 

The View Model

image

The View Model consists of:

  • Properties – One of something. This could be a String or an Object. Implements INotifyPropertyChanged, so that any element bound to it, is automatically notified whenever it changes.
  • Collections – A collection of something. This is of type ObservableCollection, so that any element bound to it, is automatically notified whenever it changes.
  • Commands – An event that can be raised. Also, one parameter of type Object can be passed. This implements ICommand.

 

The View

image

This is the part that you can make with no code using Expression Blend.

An Outline

  • Model
    • Get your data any way you can. Usually calls to web services.
  • View Model
    • Consists of:
      • Properties – One of something. This could be a String or an Object. Implements INotifyPropertyChanged, so that any element bound to it, is automatically notified whenever it changes.
      • Collections – A collection of something. This is of type ObservableCollection, so that any element bound to it, is automatically notified whenever it changes.
      • Commands – An event that can be raised. Also, one parameter of type Object can be passed. This implements ICommand. 
        • Implemented using Behaviors. Mostly the InvokeCommandAction Behavior  
  • View
    • Properties
      • Bind to a text box, radio button, toggle button, MediaElement, trigger an animation or ViewState change
    • Collections
      • Bind to List box, TreeMenu
    • Commands
      • Implemented using InvokeCommandAction behavior
        • Bind to a ICommand in the ViewModel
        • Indicate the ICommand that you want to raise
        • Pass a parameter
via openlightgroup.net

Posted via email from Mocha Brain Freeze

>An attempt was made to load a program with an incorrect format

>

This message being spewed-forth by an asp.net application means that the DLL concerned has been compiled as a specific “bitness”, but one that doesn’t match that which IIS is running at. The most usual reason for this is an assembly marked as “x86″ deployed to an “x64″ server. If the assembly doesn’t P/Invoke out to any 32-bit DLLs, change the platform target to “AnyCpu”.

As far as the .net framework is concerned, the x86/x64 categorisation is only used as an indicator of requirements, thus if no P/Invoke is going on it’s not needed, as the JIT compiler takes the assembly and JIT compiles it to the relevant instruction set at runtime anyway.

via robertwray.co.uk

Posted via email from Mocha Brain Freeze