Open Menu

Synergex Blog


Synergy and XAML in Harmony

By Richard Morris, Posted on October 17, 2013 at 2:23 am

The Symphony Framework is a set of assemblies that aid the development of Synergy .NET applications.  Together with CodeGen they provide a powerful, flexible environment within Microsoft Visual Studio to build great looking windows applications utilising your existing Synergy data and logic.

Windows Presentation Foundation (WPF) is the tool of choice.  The user interface is written in XAML and data bound to your Synergy data exposed through Symphony Framework Data Objects.  It all sounds simple, and it is.  The biggest problem with XAML is that the data binding is performed at runtime, using “magic” strings.  They are “magic” because at runtime they miraculously find the data source you named in the binding “string” and all is well.  However, if you mistype the string then the bindings don’t work, but your application continues to execute – no errors reported, but no data.

To alleviate this problem the Symphony Framework uses CodeGen to build Synergy Repository based Styles.  Styles allow you to define the “style” of a control, for example the type of input control, it’s size, field entry limitations, drop-down list bindings, error information, etc.  Once defined you can reference these styles in your XAML UI code and utilise them.

In Visual Studio 2010 this worked nicely: referencing your styles worked and you could apply styles to the input controls, but there was no editor assistance – you needed to remember the style names for things to build and run correctly.

And then came along Visual Studio 2012 and things really didn’t work at all.  The XAML referencing syntax was changed and broken in a big way.  Some referencing worked in the XAML designer and failed at runtime, and others the reverse – meaning you couldn’t design your UI at all.  Big problems!

But now Visual Studio and the Symphony Framework are back in harmony.  The upcoming release of Visual Studio 2013 is a must for anyone doing any .NET development, it’s a triumph over VS2012!  As well as the XAML referencing being fixed there are some cool new features that really make Symphony Framework development even easier.  One such feature is that the XAML editor is now aware of all your referenced style, making the selection of the right style easier than learning your scales.

XAML

 

 

 

 

And using the right style ensures you have the right binding: hey-presto no more binding issues!

Synergy 10.1.1b is going to be release to coincide with the release of VS2013 so bookmark your diary and ensure you upgrade to the latest versions of both.

If you would like to see examples of Styles in action you check out my video at http://youtu.be/FqWpMRrSb4w.


Using Synergy .NET in Multi-Threaded Applications

By Steve Ives, Posted on October 10, 2013 at 12:28 pm

There are special considerations that must be taken into account when implementing non thread-aware Synergy .NET code that will execute in a multi-threaded environment. As will be explained later, one such environment is when code executes within an ASP.NET / Internet Information Server (IIS) environment.

The Microsoft .NET environment provides a mechanism to allow the isolation of multiple instances of an application from one another. This mechanism is called Application Domains, and is often referred to as AppDomains. Essentially an AppDomain entirely isolates an instance of some piece of executing code from all other executing instances of that, and any other code, so that these instances cannot interfere with one another in any way. AppDomains also ensure that the failure of any code executing within an AppDomain cannot adversely affect any other executing code.

AppDomains are specifically useful in situations where there may be multiple instances of a piece of code executing within the context of a single process, for example where different execution threads are used to perform multiple concurrent streams of processing (perhaps on behalf of different users) all within a single host process. An example of such an environment is ASP.NET Web applications executing on an IIS Web Server.

Synergy .NET provides specific support for isolating non thread-aware code in AppDomains, and in some situations it can be critical that AppDomains are used in order to have your Synergy .NET code behave as expected in several key areas. Those key areas are channels, static data, common data and global data.

If any of the above items are used in a multi-threaded environment without the use of AppDomains, then they are SHARED between all instances of the code running in the multiple threads. By using an AppDomain, code executing within a given thread can isolate itself from code running in other threads, thus returning to the normal or expected behavior in Synergy environments.

If you are implementing Synergy .NET code that does not make use of multi-threading, and will not execute in a multi-threaded application host then you don’t need to worry about any of this.

If you are implementing multi-threaded Synergy .NET code then you have the option of using AppDomains to isolate parts of your code from other instances if you chose or need to do so.

However if you are implementing non thread-aware Synergy .NET code that will execute in an ASP.NET / IIS environment then you are automatically in a multi-threaded environment and it is critical that you use AppDomains to isolate instances of your application code from each other.

The basic problem is this: ASP.NET and IIS isolate different APPLICATIONS within their own AppDomains, but within an ASP.NET application, multiple (potentially lots of) user “sessions” all execute within the SAME AppDomain. This means that by default there is no isolation of executing code between multiple ASP.NET user sessions, and with Synergy .NET that in turn means that channels, and static, common and global data is shared between those multiple user sessions. As an ASP.NET user session is often considered to correlate to a user process in a regular application, the problem becomes apparent. If one “user” opens a new channel and reads and locks a record, that same channel and record lock are shared with all other users. If one user places a certain value in a common field for use by a routine that is going to be called, that value could be changed by code running for a different user before the first users routine gets called.

Clearly it would be very difficult, if not impossible to build and execute reliable code in this kind of environment. Without support for AppDomains in a multi-threaded environment a Synergy developer would need to:

  • Always use automatic channel number selection.
  • Always close any channels before returning from the routine that opened the channel (no persistent open files)
  • Not use static, common or global data unless the nature of that data is that it contains application wide information that does not change during execution.

While it is possible to write code which adheres to these rules, it would be at the least inconvenient to do so, and because of the way that Synergy code has typically been written in the past, existing code would likely require significant reworking.

The solution to this problem is to have each “users” code isolate its self from other “users” code by loading its self into an AppDomain, and this is relatively easy to do. Specifically in the case of an ASP.NET Web application, code can be written to hook the Session_Start event that signals the beginning of a new user session and create a new AppDomain in which to execute, and hook the Session_End event and execute code to clean up by deleting the AppDomain. There are other possible approaches that may be more appropriate, but the principal is basically the same; have the code isolate its self in an AppDomain before any non-thread aware Synergy .NET code executes.

By isolating non thread-aware Synergy .NET code in an AppDomain in a multi-threaded environment you have essentially the same operating environment that you would expect for any other Synergy code executing in a process, with one notable exception. That exception is that environment variables created with XCALL SETLOG are always applied at the PROCESS level. This means that Synergy .NET code executing in any multi-threaded environment should never rely on the use of XCALL SETLOG unless the value being set is applicable to code executing in all other threads. An example of this might be an environment variable that identifies the fixed path to a data file.

Synergex Professional Services Group is in the process of developing code for a sample ASP.NET Web Application that will demonstrate how to use AppDomains to ensure that code executing in one ASP.NET Session is isolated from other ASP.NET Sessions. We will publish this code in the Synergy/DE CodeExchange soon. I will post another article on this BLOG once the code has been published.


Don't miss a post!

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Recent Posts Tag Cloud Archives