Steve Ives, Author at Synergex | Page 6 of 7
Phone800.366.3472 SupportGet Support DocumentationDocumentation Resource CenterResource Center
search
close
Open Menu

Synergex Blog


CodeGen Goes Open Source

By Steve Ives, Posted on May 22, 2012 at 9:45 am

Steve Ives

For several years now I have been developing a tool called CodeGen. As you may have already guessed from the name, it’s a code generator! What’s a code generator? It’s a tool that generates code … sounds useful, right?

Well it is useful, in many different situations. Not all situations of course. If a code generator could generate ANY piece of source code that you might need then we wouldn’t need programmers any more … so why would a programmer write such a tool?

OK I jest a little. Believe me, if it were possible to write such a tool then I would have done it, and I’d have made a lot of money from it, and I probably wouldn’t be sitting here writing this BLOG right now 🙂 No, of course it’s not possible to write a tool that can generate ANY piece of source code, but it absolutely is possible to create a tool that can generate useful code to address a wide variety of different requirements, and that’s what CodeGen does.

So just what is CodeGen? Well, I generally describe it as a “template-driven” code generator. What that means is that you start with a template file that defines the general “rules” for the code that is to be created, and you combine the information from that template file with some meta-data in order to produce the final code. So now the question is where does the meta-data come from? Well, when using CodeGen, in most cases it comes from a Synergy repository.

A repository database is an extremely rich source of meta-data relating to the data structures that are used within your applications. The applications that we write totally revolve around data, they create data, update data, and analyze and present data. So having a repository which completely describes not only the data structures that your application uses, but also a huge amount of additional information about HOW that data is represented and to processed, and armed with an API (ddlib) which allows programmatic access to that meta-data, a programmer can create software that “does things” based on that information. That’s what CodeGen does.

By the way, don’t fret it if you don’t already use Repository … that’s easy to address.

I have no intention of “rambling on” about what CodeGen is and how it works, because that information is all available elsewhere. CodeGen has been in use for several years, I use it extensively, and I have used it to deliver real value to several customers also. In fact in the past, that was the model. CodeGen was a tool developed by Synergex Professional Services Group, and it was available for us to use during consulting engagements. If we used it during such an engagement then that customer got to continue to use the tool, and many have done so.

The real point of writing this post is to announce, with great delight, “that times are a changing”. We’ve decided to take a different tack, and make CodeGen available to a wider audience; a MUCH wider audience. I am delighted to announce that CodeGen is now an Open Source product, and is published for the world to download and use. The project is hosted on CodePlex (Microsoft’s Open Source hosting platform) and you can view the CodeGen project home page at https://codegen.codeplex.com.

So just what does this mean? Well, it means that CodeGen is now available for you to download and use, and I hope that lots of you do just that. CodeGen is now primarily developed with Synergy .NET in Visual Studio, and if you want to use it you have two choices:

  1. Download the pre-built distribution (a Windows Installer setup program).
  2. Download the source code package and build it yourself.

The binary distribution is built with the latest version of Synergy.NET (9.5.3b), so you’ll need that version of Synergy to use it. If you’re working with an older version of Synergy then you’ll need to build CodeGen from source code, but you’ll still need a pretty recent version of Synergy/DE.

Even though the main development environment for CodeGen is now Synergy .NET, it wasn’t always that way. CodeGen started out life as a regular “Traditional Synergy” application, and it still works just fine that way. What that means is that CodeGen is equally at home under Synergy .NET or Traditional Synergy on Windows, Unix, Linux or OpenVMS, and the source code download includes scripts to build CodeGen on all of these platforms.

If you are currently attending the Synergex DevPartner Conference in Chicago, IL then you’re going to hear more about CodeGen during the conference today, and on Tuesday afternoon there will be a hands-on tutorial available to help you get real experience working with it. And if you’re attending the conference in York, England in June then don’t fret, you’ll get the same opportunity. But if you’re not attending either conference (it’s not too late to sign up for York) then you’re definitely missing out on some great information about CodeGen, and a BUNCH of other cool stuff!

But just because you’re not attending the conference doesn’t mean that you can’t use CodeGen. Head on over to https://codegen.codeplex.com to get started right now. And please, even if you don’t use CodeGen right now, at least “follow” the CodePlex project so that you’ll be kept up to date with news about the product.

By the way, to my best of my knowledge this is the first time that a “DIBOL” (Synergy) application has been published as an open source project, and I’m pretty stoked about that. BUT … there’s more! There’s another open source Synergy project about to “hit the streets” … and it utilizes CodeGen … but I’ll leave it up to my friend and colleague Richard Morris to tell you all about that!


Are you ready for Windows 8 and Visual Studio “11”?

By Steve Ives, Posted on May 15, 2012 at 10:59 pm

Steve Ives

Microsoft has recently announced that the Release Candidates of both Windows 8 and Visual Studio “11” will be made available during the first week of June, 2012. Are your applications ready?

The annual Synergex DevPartner Conferences are just around the corner, and will present a wealth of valuable information that Synergy developers need to be aware of in order to deploy apps on these new platforms. It’s not too late to sign up, so don’t miss the opportunity.


Using WCF Services in Synergy .NET Applications

By Steve Ives, Posted on January 11, 2012 at 2:37 pm

Steve Ives

Apparently there are some people actually reading this BLOG!!! And … it turns out that quite a few of them have been working through my earlier series of posts related to using WCF. Excellent!

It occurred to me that since I wrote the last of those articles we have had a release of a new version, namely Synergy/DE 9.5.3. And that new version included some important new functionality related to consuming WCF services in Synergy .NET applications.

In previous posts I had to talk about the fact that “Add Service Reference” was not implemented in Synergy .NET, and I demonstrated how you could use the svcutil.exe command line utility to generate client proxy code and configuration information, both of which could then be manually added to a Synergy .NET project.

Good news … in 9.5.3 the Add Service Reference wizard has been implemented in all Synergy project types. I’m not going to go into great detail about how to use this new functionality … because it’s exactly the same as in C# and VB projects, and pretty well documented elsewhere. But briefly, in a Synergy .NET project:

1. Right-click on the project in solution explorer and select “Add Service Reference”.

image

2. Enter the URI of your service and click the “Go” button … or … if the service is in the same solution, click the “Discover” button.

3. Enter the name of the namespace that you wish the generated proxy classes to be placed in.

4. Optionally click the “Advanced…” button and select advanced options. For example, it is common to set “Collection Type” to something a little nicer than System.Array, and very often you’ll want to enable “Generate asynchronous operations” in order to help you build responsive and flexible applications.

image

5. Finally click the “OK” button in the first dialog to generate the service reference within your project.

imageWhen you add a service reference to a project, several things happen:

  • The svcutil.exe utility is used to download the WSDL information from the service, and to generate client proxy classes for the service based on the content of the WSDL.
  • The resulting generated files are added into the project. By default these files are hidden beneath a single node in Solution explorer which represents the service reference, but you can look at all of the files by enabling the “Show All Files” option in solution explorer.
  • Depending on the type of project you are working in, references to several additional assemblies may be added. These referenced assemblies can include System.Runtime.Serialization, System.ServiceModel, and System.Xml.

So … finally … no more manual use of svcutil.exe is required in order to consume WCF services Synergy .NET applications. Thanks development Smile.


De-Serializing Classes containing Synergy Types

By Steve Ives, Posted on at 2:10 pm

Steve Ives

A customer recently reported a strange problem that they were seeing when attempting to use WCF. The problem seemed to occur when they attempted to call a method in their WCF service, where that method had a parameter used to send a class TO the service, and where that class included the use of Synergy types (a struct field containing alpha data in this case). By the way, these Synergy types were internal within the class; the external interface of the class was totally CLS compliant … but that didn’t seem to matter.

The actual problem was that the customer was seeing was “null reference” exceptions at runtime. The error seemed to occur when the setter methods of the servers data class were being called. Now, in order to understand the cause of the problem, it might help to take a step back and thing about what is happening under the hood in this type of scenario.

When you add a “Service Reference” in a client application, Visual Studio (or the svcutil.exe utility) downloads the WSDL information that defines the service, analyzes it, and then creates local “proxy” classes for the various classes that are required in order to interact with the service. When a client application needs to call a method that accepts an object as a parameter, it instantiates a copy of the local proxy class and passes that object as a parameter to the method. WCF then serializes that data (to XML or some other format suitable for transmission over the wire) and calls the method. On the server, the data is received and then de-serialized back into an instance of the original server-based data class; all of the properties being set to the various values that were received over the wire.

As it turns out, when WCF performs this de-serialization and creates an instance of a server data object to pass to a method, it does so in such a way that the default constructor of the data class is not called. And herein lies the problem.

In Synergy .NET all classes contain an implicit default constructor. This constructor, amongst other things, is responsible for the instantiation of any Synergy types present in the class. But because WCF circumvents this mechanism, the Synergy types are never instantiated, and hence the null reference errors.

Right now a little bit of head-scratching is taking place in development, and I’m sure that at some point soon a proper resolution to this problem will emerge … but in the meantime we need a workaround, which thankfully (thanks Jeff) turns out to be relatively straight forward:

Code Snippet
.region "De-serialization workaround"

private static myConstructor, @System.Reflection.ConstructorInfo
        
{OnDeserializing}
public method OnDeserializing, void
    context, StreamingContext
proc
    if (myConstructor==^null)
        myConstructor = this.GetType().GetConstructor(new Type[0])
    myConstructor.Invoke(this, new Object[0])
endmethod

.endregion

 

This is the code for a method named OnDeserializing, and you will notice that the method is preceded by an attribute named {OnDeserializing}. This attribute will cause the method to be called whenever an instance of the class is created during a de-serialization operation. Within the method, reflection is used to get a handle on the default constructor for the class, which is then explicitly called. The handle to the constructor is stored in a static variable, so that the code that obtains the handle will only execute once, the first time the method executes. The method then explicitly calls the constructor, which in turn instantiates any Synergy types which may be present in the object.

So … for now … if you want to use a Synergy data class as part of a WCF service, and that class will be used for IN or INOUT method parameters, you need to include this section of code in the class.


Microsoft Announce Windows Store Details

By Steve Ives, Posted on December 9, 2011 at 12:49 pm

Steve Ives

Since the //BUILD conference in September many developers have been eagerly awaiting the details of how the new “Windows Store” will operate. The Windows Store will be the primary mechanism by which Windows 8 users will find and acquire Windows Metro-Style Apps.

In addition to the information provided during the event, a new BLOG called Windows Store for Developers was also launched. The BLOG will be worth watching if you’re interested in building and deploying Metro apps.

By the way, if you’re wondering what the time-line looks like on the Windows Store, and on Windows 8 generally, at the end of the video Microsoft confirmed that the Windows Store will open at the same time as the Windows 8 Beta is released, which will be in Late February of 2012.


Windows Reimagined

By Steve Ives, Posted on September 14, 2011 at 12:18 am

Steve Ives

Well, all I can say is “WOW”! The first day of the Microsoft BUILD conference is over, and it’s been a LONG day, and it’s been a BUSY day, and it’s been an EXCITING day. Wow!

I’m buzzed … and I’m really quite surprised by that statement. I arrived in Anaheim a little over 24 hours ago, and to be quite honest I was a little skeptical about the whole thing. As you may know from a couple of recent posts, I had started to do some research about what Windows 8 might mean to Synergex, and to our customers, and to our customers customers … and to be quite honest I had more questions than answers. I was more than a little concerned that Microsoft were all set to try to change the Windows world … which they are … but perhaps with less than the amount of (in my opinion) required consideration for existing customers, and applications, and technologies, and tools.

Specifically, I was concerned that there was a lot of talk about HTML5, and of CSS, and of JavaScript … but very little talk about XAML, and C#, and third-party languages like Synergy .NET, and so on. I was concerned that Microsoft were set to not only reimagine Windows, but also reimagine all of the development tools that are used to build Windows applications.

But … big sigh of relief … from me and several thousand other people in the room … although there is a definite emphasis on new development tools which will soon be available within the Microsoft development toolset, i.e. extended support for tools like HTML5, CSS and JavaScript,  there is also a consistent message that existing .NET toolsets are still completely valid and will continue to be so.

On the platform side … WOW! Most of the information to date has centered around videos of demos dating back to early June, and those demos were pretty impressive, Well, I can tell you that things have moved on quite significantly since then, and although Windows 8 is still only in a “Developer Preview” (i.e. pre-beta) state … it’s looking REALLY GOOD!

Of course there are bugs, of course there are glitches, but on the whole people at this conference are pretty excited about what is coming. And that includes the four Synergex employees that are here … after a long day at the conference, and a pretty good stint in the bar afterwards, we’re bouncing ideas around, and coming up with all of these “what if’s”, and seeing the real possibility of Synergy developers being able to fully participate in these exciting new technologies.

Of course some of the reason for this is as a direct consequence of the tens of thousands of man hours of work that have been invested in the various Synergy products in recent years. But also it is with the realization that there is more work still to be done, because the goal posts just got moved in a fairly significant way. But … because of where we know we are now, where we now know we need to be actually doesn’t seem that far away … WOW!

There are exciting times ahead … there are challenges also, but I firmly believe that we’re on the right track.

If you’re interested in the future of Windows then I would strongly recommend that you watch the keynote speech from todays conference, you can find it and many other interesting videos here:

https://www.buildwindows.com

By the way, I am writing this post on my new Samsung Windows 8 “Slate” PC. Those who know me would tell you that I develop on Windows, and Unix, and Linux, and OpenVMS … but I’m an Apple guy at heart. I have an iPhone, and an iPad, and a couple of Macs … and I LOVE those things. But … I think that Microsoft Windows 8 might just change the world. It’s an operating system for the PC, and that PC might just be a Slate (tablet). The point is that today I was convinced that the best of both worlds really can be built into one operating system that can run equally well on different types of devices. I LOVE my iPad but I can’t run hundreds of thousands of existing desktop apps on it, and despite good intentions iOS is jus WAY too restrictive. What Microsoft showed us and gave us today is really cool … it’s a tablet, but it’s also a PC … WOW!


Windows 8 and Screen Resolution

By Steve Ives, Posted on September 8, 2011 at 4:10 pm

Steve Ives

If you’re thinking of purchasing a new laptop, or a new flat-panel monitor for your desktop PC, you might want to think a carefully about the resolution of the screen that you select. Because if you’re purchasing new hardware now, you’re likely to want to run Windows 8 on that hardware before the end of its useful life.

According to early information from Microsoft, both the resolution and aspect ratio of the screen will become more important if you want to be able to take advantage of all of the new features available in the new Metro UI.

For the best experience with Windows 8, and in order to be able to take advantage of all of the new Metro UI features, you need a wide-screen with a 16 x 9 aspect ratio and a minimum pixel resolution of 1366 x 768. If your system meets or exceeds these specifications then you should be in good shape, and most will.

However, if your display does not have a wide-screen aspect ratio then you won’t be able to use all of the features of the Windows 8 Metro UI. Specifically the “Snap” feature which allows two “tailored” metro applications (or one tailored application and the traditional Windows Aero desktop) to be docked side-by-side will not be available. By the way, the term tailored application seems to be what Microsoft are using to refer to apps designed to take advantage of the Metro UI under Windows 8. I can’t help wondering if the choice of this term is to make us lowly software developers think that we just need to do a little “tailoring” here and there to support the new UI … in the same way that cell-based applications had to be “tailored a little” to move to Windows under UI Toolkit! Time will tell I guess.

By the way … don’t confuse the windows 8 “Snap” feature with another feature that they introduced in Windows 7 called … “Snap”!!! Although similar, they are not the same thing. Note that the Windows 7 desktop snap feature will still work on the traditional desktop, even if your system doesn’t support the Windows 8 Snap feature. All very confusing!

Finally, although uncommon some netbook PC’s are equipped with displays with less than 768 vertical pixels (e.g. 1024 x 600). Apparently displays this small will not support the new Metro UI at all, although the traditional Windows Aero UI will still work on these systems.

This information was taken from a video of a Microsoft event for various hardware partners which was held during the Computex 2011 in Taipei during early June 2011. If you’re interested in the full video, I’ve embedded it below.


Exposing WCF Services using Synergy .NET

By Steve Ives, Posted on at 12:54 pm

Steve Ives

In this post I will explain how you can use Synergy .NET to expose a WCF service. I’ll be showing you how to create WCF service and data contracts totally from scratch, using Synergy .NET. We’ll be defining new classes, not working with existing routines and records. That’s not to say that you can’t work with existing routines and records, in fact you may well chose to do so WITHIN a service that you create, but the focus of this post is on writing new code for the future.

This is the sixth in a series of posts relating to the various ways in which Synergy developers can use of Windows Communication Foundation (WCF) when building their applications. The posts in the series are:

  1. Building Distributed Apps with Synergy/DE and WCF
  2. Exposing WCF Services using xfNetLink .NET
  3. Hosting WCF Services in an ASP.NET Web Application
  4. Exposing WCF services using Synergy .NET Interop
  5. Self-Hosting WCF Services
  6. Exposing WCF services using Synergy .NET (this post)

 

In earlier posts I demonstrated how it was possible to expose WCF services using existing source code, either by transforming an xfNetLink .NET assembly into a WCF service, or by adding the traditional Synergy subroutines and functions that existed “underneath” an xfNetLink .NET assembly to a new Synergy .NET Interop project. There are valid use cases for both of these strategies, depending on what you’re starting with, however there are also some disadvantages to both approaches.

Perhaps the most significant disadvantage is that the external interface of the WCF service contracts that get exposed are defined by the parameters and return values of one or more traditional Synergy routines. And the data contracts are defined by Synergy record layouts defined in a repository. Also the actual WCF contracts that are exposed are under the control of the code generators that create the contracts, either GENCS, or the logic within the Interop project. This means that as a developer you’re kind of stuck with the defaults that those tools provide.

WCF has diverse capabilities which are defined and controlled through a large number of code and configuration options, and many of these are controlled via in-code attributes which are applied to the service and data contracts that make up a service. But when you work with services that are generated for you you don’t get to determine what options are used. So in some cases you might find that working with generated services is a little too restrictive.

This post will show how to create your own WCF services from scratch, in a way that makes all of the capabilities of WCF available to you.

The WCF Service Library Template

Although it has been possible to create WCF services with Synergy .NET since the product was introduced in version 9.5.1, the process became a lot easier in 9.5.1a. This was because we added a new project template called WCF Service Library. To create a new WCF service we simply start Visual Studio and create a new project based on the WCF Service Library template:

image

When you use the project template you create a new class library which is pre-configured appropriately for the development of WCF service and data contract classes.

imageOver and above a regular class library, a WCF Service Library development project will include:

  • References to the following .NET Framework assembles
    • System.Core
    • System.Runtime.Serialization
    • System.ServiceModel
    • System.Xml
  • An example of how to define WCF service and data contracts.
    • IService1.dbl
  • An example of how to implement the service defined by a service contract.
    • Service1.dbl

 

Before we go too much further let me make it clear that I don’t particularly like the example code that is provided by the project template, despite being the one who actually provided it for the distribution! But there is a good reason why the example code is the way that it is. That reason is that the example implements in Synergy the the exact same example that Microsoft provide when you create a new WCF Service Library using either C# or Visual Basic.

Service Contracts

So what do we have in the example? Most developers agree that it is good practice to separate the definition of a service contract from the actual implementation of the contract, and for service contracts this is achieved using an interface. In the example file called IService1.dbl you will find code like this:

WCF Service Contract
  1. import System
  2. import System.Collections.Generic
  3. import System.Runtime.Serialization
  4. import System.ServiceModel
  5. import System.Text
  6.  
  7. namespace MyWcfServices
  8.  
  9.     {ServiceContract}
  10.     public interface IService1
  11.         
  12.         {OperationContract}
  13.         method GetData, string
  14.             required in val, int
  15.         endmethod
  16.         
  17.         {OperationContract}
  18.         method GetDataUsingDataContract, @CompositeType
  19.             composite, @CompositeType
  20.         endmethod
  21.         
  22.         ;;TODO: Add your service operations here
  23.         
  24.     endinterface
  25.     
  26. endnamespace

 

The example defines a WCF service in a class named Service1 and therefore, following accepted best practices, the name of the interface that defines the external view of the class is prefixed with a capital I. You will notice that the {ServiceContract} attribute is applied to the interface, which essentially means that any class which implements the interface will expose a WCF service contract.

Within the interface you will see that the example code defined two methods, named GetData and GetDataUsingDataContract. Both of these methods have the {OperationContract} attribute applied, which means that the methods will be exposed as operations of the WCF service … or in other words they are methods that a remote client accessing the service may call.

The GetData method accepts a single parameter which is an integer number, and has a return type of string.

The GetDataUsingDataContract method on the other hand has a single single parameter which is an object of type “CompositeType” and also returns an object of the same type. CompositeType is a class representing a complex data type (think OO version of a record) and is defined a little further down in the code:

By the way, you will notice that the methods that are described in the interface do not have accessibility specified. This is because by convention, all members of an interface are considered public. You will also notice that there is no procedure division specified … there is no PROC statement. This is because the role of an interface is simply to DEFINE requirements for a class, or rather for the external interface of a class. Interfaces do not include any logic … that will be added in a class which IMPLEMENTS the interface.

Data Contracts

Data contracts define complex data types (data classes) that can be passed from a client to a service or returned from a service back to a client, and are simply defined via a class with public properties of the appropriate types.

In the example the class named CompositeType has two public properties, one of type boolean named BoolValue, and one of type string named StringValue. As is often the case, the value of the public properties is propagated within the class by storing the actual value of the property in private variables, in this case the mBoolValue and mStringValue fields.

WCF Data Contract
  1. import System
  2. import System.Collections.Generic
  3. import System.Runtime.Serialization
  4. import System.ServiceModel
  5. import System.Text
  6.  
  7. namespace MyWcfServices
  8.  
  9.     ;;Use a data contract as illustrated in the sample below to
  10.     ;;add composite types to service operations
  11.     {DataContract}
  12.     public class CompositeType
  13.  
  14.         private mBoolValue, Boolean, true
  15.         private mStringValue, String, "Hello "
  16.         
  17.         {DataMember}
  18.         public property BoolValue, Boolean
  19.             method get
  20.             proc
  21.                 mreturn mBoolValue
  22.             endmethod
  23.             method set
  24.             proc
  25.                 mBoolValue = value
  26.             endmethod
  27.         endproperty
  28.         
  29.         {DataMember}
  30.         public property StringValue, String
  31.             method get
  32.             proc
  33.                 mreturn mStringValue
  34.             endmethod
  35.             method set
  36.             proc
  37.                 mStringValue = value
  38.             endmethod
  39.         endproperty
  40.  
  41.     endclass        
  42.  
  43. endnamespace

 

What makes the CompositeType class a WCF data contract is the presence of the {DataContract} attribute immediately before the class declaration, and the {DataMember} attributes immediately before the declaration of each of the public properties. The {DataContract} attribute is used to ensure that it is possible to serialize an instance of the class for transmission over the wire between a client and a server, and the {DataMember} attributes define which members of the class will be included in that serialization, or in simpler terms, which members will be visible to client applications.

It should be noted that, despite being the case in the simple example provided by the project template, it is somewhat unusual to define multiple types within a single source file as is the case here. In a real application it is likely that each interface would be defined in its own source file, as would each data class. There is nothing technically wrong with the approach used in the example, and it does keep the definition of all of the contracts for a service together in one place, but you don’t have to do it that way.

Implementing a WCF Service

So in the simple example provided by the WCF Service Library project template we have looked at the definition of the service and data contracts for Service1 in the source file IService1.dbl. Now it’s time to look at the code that actually implements the service itself. That code is found in Service1.dbl.

WCF Service Implementation
  1. import System
  2. import System.Collections.Generic
  3. import System.Runtime.Serialization
  4. import System.ServiceModel
  5. import System.Text
  6.  
  7. namespace MyWcfServices
  8.     
  9.     public class Service1 implements IService1
  10.         
  11.         public method GetData, String
  12.             required in val, int
  13.             endparams
  14.         proc
  15.             mreturn String.Format("You entered: {0}", val)
  16.         endmethod
  17.         
  18.         public method GetDataUsingDataContract, @CompositeType
  19.             composite, @CompositeType
  20.             endparams
  21.         proc
  22.             
  23.             if (composite==^null)
  24.                 throw new ArgumentNullException("composite")
  25.             
  26.             if (composite.BoolValue)
  27.                 composite.StringValue = composite.StringValue + "Suffix"
  28.             
  29.             mreturn composite
  30.             
  31.         endmethod
  32.         
  33.     endclass
  34.     
  35. endnamespace

    

The code above is the code that implements Service1. You will notice that this is achieved by writing a class which implements the interface that describes the service contract that we talked about earlier.

Writing a class which implements an interface is simply a matter of ensuring that the class includes at least the members that are described by the interface … in this case the GetData and GetDataUsingDataContract methods. The class may also include other members not described in the interface, but MUST at least contain the members described by the interface.

You will also notice that both of the methods required by the interface are declared with PUBLIC accessibility. As mentioned earlier this is a requirement when implementing an interface. When we implement an interface we include the code that each method in the interface will execute, so here is where the actual functionality of the service is defined.

In the example code the GetData method simply takes the integer value that was received from the client and uses that value in a string which is returned to the client. So if a client application connects to an instance of this service and calls the GetData method passing a value of 5, the return value of the method call will be the string You Entered: 5.

The GetDataUsingDataContract method checks to ensure that an instance of the CompositeType class was received, than if the objects BoolValue property is set to true it appends the string Suffix to whatever is the current value of the objects StringValue property. The object is then returned via the method return value. Yea, I know, the dev at Microsoft must have been smoking something pretty questionable when they wrote this example. Something more meaningful would have been nice, but it is what it is!

Writing a WCF Service

So, there you have it. Writing a WCF service in Synergy .NET is pretty straight forward. You basically need to:

  1. Create a new assembly using the WCF Service Library project template.
  2. Define the external interface of your service via an interface that describes the service and operation contracts, and any data classes that may be required to define the data contracts that you need.
  3. Create a class which implements the service contract and includes the necessary functionality.

And remember we’re working in Synergy .NET here, so we have the full power of Synergy at out fingertips. If we need to access Synergy data that’s local to where the service will be hosted then we can go ahead and access that data directly, but if the data is remote then we can use xfServer to get to it – regardless of the system it resides on. We could also use an xfNetLink .NET assembly to allow us to get back into our traditional Synergy business logic, for all or part of the logic for the service. And of course we still have access to the SQL Connection API in order to access any relational databases that we may need to use. Of course we could also use other mechanisms in the .NET Framework to access a wide variety of data sources too.

Hosting the Service

If you’ve read the earlier posts in this series then you will already know that creating a WCF service is only part of the story, it also needs to be hosted somewhere. This has already been discussed in two earlier posts, so I don’t intend to repeat the information here.


Self-Hosting WCF Services

By Steve Ives, Posted on September 2, 2011 at 4:17 pm

Steve Ives

Having defined a WCF service in code, and built that code into an assembly, a runtime instance of the service must be “hosted” somewhere in order for other application to be able to connect to and interact with the service. There are several ways to host WCF services. In an earlier post I described how to Host a WCF Service in an ASP.NET Web Application, which is a commonly used approach. But in some situations, for example if the only requirement for an IIS web server is to host a WCF service, it is preferable to host a service in a different way. In this post I will describe how to do just that, by leveraging capabilities of the .NET Framework which allow WCF services to be “self hosted”.

This is the fifth in a series of posts relating to the various ways in which Synergy developers can use of Windows Communication Foundation (WCF) when building their applications. The posts in the series are:

  1. Building Distributed Apps with Synergy/DE and WCF
  2. Exposing WCF Services using xfNetLink .NET
  3. Hosting WCF Services in an ASP.NET Web Application
  4. Exposing WCF services using Synergy .NET Interop
  5. Self-Hosting WCF Services (this post)
  6. Exposing WCF services using Synergy .NET

What is Self Hosting?

As its name suggests, self hosting a WCF service refers to the ability to host a WCF service within another application that you write, rather than hosting the service in a container such as that provided by Internet Information Services (IIS), or Windows Process Activation Services (WAS).

The .NET Framework provides various classes that can be used to host WCF Services within the context of a .NET application. This could be any type of .NET application, including console applications and desktop applications. However, in most cases WCF services need to be continually available, and it is often not convenient to host a service in a console or desktop application, because those applications typically execute in the context of a logged in user session.

A Windows Service application on the other hand can provide an excellent mechanism for hosting a WCF service. Windows Services are generally designed to automatically start when a system boots, stopped when the system is closed down, be continually available while the system is running, and are not associated with the desktop of any logged in user.

Since 9.5.1a Synergy .NET has included a project template which makes creating a Windows Service very easy, and as you are about to see, adding the code necessary to instantiate and host a WCF service is relatively straight forward.

Creating a WCF Service

In this post I’m assuming that you have already created a WCF service that you wish to host. If you have read the earlier posts in this series you will already know of two ways to create a WCF service, and in a later post I’ll show you another way.

Creating a Windows Service

Using Synergy .NET it is very easy to create a Windows Service. We provide a project template called “Windows Service”, and when you create a new project from the template you essentially have all of the code that you need to implement the service. Of course, apart from starting and stopping a service the default code that you get from the template doesn’t actually do anything … that’s where you come in!

You’ll need a Windows development system with the following products installed

  • Visual Studio 2010 Professional (or higher / later)
  • Synergy/DE 9.5.1a (or later)
  • Synergy Language Integration for Visual Studio 9.5.1a (or later)

 

Follow these steps to create a new Windows Service:

  • Start Visual Studio
  • From the menu, select File > New > Project.
  • From the installed templates list, select Synergy/DE.
  • From the project templates list select Windows Service.
  • Provide a name for the project and set its location.
  • Click the OK button to create the new project.

 

image

As you can see, in my example I have named my service MyWcfHostService and have created the project below my c:temp folder.

imageOnce the Windows Service project has been created, if you look in Solution Explorer you should see something like this:

You will notice that three source files were added to the project. In my example the file MyWcfHostService.dbl contains the code for the service itself, MyWcfHostServiceInstaller.dbl contains code used when the service is registered (installed), and Program.dbl is simply the main-line program that actually launches the service when the process starts.

Take a look at the main service source file (the one that ends …Service.dbl) and you will see that the code is relatively self explanatory. The class defined in the source file extends a parent class called ServiceBase. This means that our class has inherited a lot of functionality which essentially makes it a Windows Service.

You’ll also see that the class has a constructor method with the same name as the class itself, and the constructor calls a method called InitializeComponent, which sets various properties in order to configure various capabilities of the service.

private method InitializeComponent, void
    endparams
proc
    this.ServiceName = "MyWcfHostService"
    this.AutoLog = true
    this.CanPauseAndContinue = false
    this.CanHandlePowerEvent = false
    this.CanShutdown = false
    this.CanStop = true
endmethod

All Windows services have the ability to be started, and as you can likely derive from the code, by default a new service has the ability to be stopped, but not to be paused and continued, or to respond to changes in the systems power state (mains vs. battery).

So, our new service can start, and it can be stopped. All we need to do is define what code should be executed when the service starts, and when the service stops. And if you scroll down a little you will notice that the code already contains place-holder event handlers where we can add whatever code we need:

protected override method OnStart, void
    byval args, [#]String
    endparams
proc
    ;;TODO: Add code to execute when the service is instructed to start
endmethod
		
protected override method OnStop, void
    endparams
proc
    ;;TODO: Add code to execute when the service is instructed to stop
endmethod

Our task is relatively straight forward. All we need to do is add whatever code is necessary to create and expose an instance of a WCF service in the OnStart method, and to stop the service in the OnStop method.

Referencing a WCF Service

The WCF service that we will be hosting has already been created in a separate assembly, so to get access to it we need to add a reference to that assembly in our Windows Service project.

  • In Solution Explorer, right-click on the References folder and from the context menu select Add Reference.
  • Wait for the Add Reference dialog to be displayed and load it’s data, which usually takes a few seconds.
  • Click on the Browse tab, then browse to the location of the assembly that contains your WCF service.
    • If your WCF service is defined in an xfNetLink .NET assembly then this is whatever folder you created the assembly in.
    • If your WCF service is defined in a Synergy .NET Interop project, or some other Visual Studio project, then you will generally find the assembly below that projects “bin” folder.
  • Select the assembly and click the OK button to add the reference to the assembly containing the WCF service.

Additional Steps for xfNetLink .NET WCF Services Only

If your WCF service is defined in an xfNetLink .NET assembly then there are two additional steps that you will need to complete.

Add a reference to xfNetLink .NET

Because your WCF service is defined in an xfNetLink .NET assembly, that assembly will require that your project also has a reference to the xfNetLink .NET assembly.

  • In Solution Explorer, right-click on the References folder and from the context menu select Add Reference.
  • Wait for the Add Reference dialog to be displayed and load it’s data, which usually takes a few seconds.
  • Click on the Browse tab, then browse to the location of the xfNetLink .NET assembly (xfnlnet.dll).
    • The assembly will normally be found under your Program FilesSynergexxfNLNet folder.
  • Select the assembly and click the OK button to add the reference.

Supply xfNetLink .NET Connection Information

Because your WCF service uses xfNetLink (to connect to xfServerPlus in order to execute your Synergy methods), you must tell xfNetLink where the instance of xfServerPlus is listening (host name or IP address, and port number). The best way to do this is via an application configuration (app.config) file.

  • In Solution Explorer, right click on your Windows Service project and from the context menu, select Add > New Item.
  • Select Application Configuration File and click the Add button.

Having added the configuration file to the project you need to specify the required configuration information, something like this:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <configSections>
    <sectionGroup name="xfnlnet">
      <section name="default" type="System.Configuration.NameValueSectionHandler, System, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
    </sectionGroup>
  </configSections>
  <xfnlnet>
    <default>
      <add key="host" value="192.168.1.10" />
      <add key="port" value="2356" />
    </default>
  </xfnlnet>
</configuration>

Note: You can also use the Synergy .NET Configuration Utility to add this information to the file. Clearly you should replace the IP address and port number with the correct values for your own instance of xfServerPlus.

Hosting an Instance of the WCF Service

In the most basic form, self-hosting a WCF service in another application essentially turns that application into a web server. The web server capabilities are provided by a class in the .NET Framework called ServiceHost. This class is found in a namespace called System.ServiceModel, and is provided the System.ServiceModel.dll assembly.

The code that we’ll be adding will use these web server capabilities to expose a “WCF Endpoint” at a specified HTTP address.

In addition to exposing an endpoint which is an instance of your WCF service, you will usually also want to expose a second “metadata endpoint”. This allows other applications that may need to interact with your WCF service to download the metadata for your service. The metadata fully describes the service and its capabilities, and is made available automatically by WCF. Clients applications can use a standard protocol called Metadata Exchange (often referred to as MEX) in order to download a WCF services metadata from a metadata endpoint. In code, we use a second class called ServiceMetaDataBehavior to expose our services metadata. This class is in the System.ServiceModel.Description namespace, and is also in the System.ServiceModel.dll assembly.

If all of this is starting to sound really complicated, well it is! Luckily the .NET Framework hides most of these requirements from us, and does most of the work. Despite sounding really complicated, the code that we need to write is remarkably simple.

To self host a WCF service there are generally three main things you will need:

  • The URI for the endpoint for the service.
  • An instance of the ServiceHost class to expose your service at that URI
  • An instance of the ServiceMetaDataBehavior class to expose a metadata (MEX) endpoint.

 

So, lets write this thing:

  • Use the Add Reference dialog that you used earlier to add a reference to the Frameworks System.ServiceModel assembly.
  • At the top of the code in your …Service.dbl file, add the following two import statements:
import System.ServiceModel
import System.ServiceModel.Description
  • Somewhere inside the class, but NOT inside any method, add the following data declarations:
private baseAddress ,String
private host        ,@ServiceHost
private smb         ,@ServiceMetadataBehavior

In the procedure division of the OnStart method, add code like this:

protected override method OnStart, void
    byval args, [#]String
    endparams
proc
    ;;Define the URI for the service endpoint
    baseAddress = "http://" + Environment.MachineName + ":8080"

    ;;Create a ServiceHost instance for the WCF service
    host = new ServiceHost(
    &       ^typeof(spc2011.SynergyServer),
    &       new Uri(baseAddress))

    ;;Add a BasicHttp endpoint
    host.AddServiceEndpoint(
    &       ^typeof(spc2011.ISynergyServer),
    &       new BasicHttpBinding(),
    &       "SynergyServer")

    ;;Create a ServiceMetaDataBehavior instance
    smb = new ServiceMetadataBehavior()
    smb.HttpGetEnabled = true
    smb.MetadataExporter.PolicyVersion = PolicyVersion.Policy15

    ;;Add a MEX endpoint
    host.Description.Behaviors.Add(smb)

    ;;Start the listener
    host.Open()

endmethod

In my example, the namespace in which my WCF service is defined is “spc2011” and the name of the WCF service class is “SynergyServer”. You would need to:

  • Replace the reference to spc2011.SynergyServer with the namespace and class of your WCF service.
  • Replace the reference to spc2011.ISynergyServer with the namespace and interface of your WCF service.

IMPORTANT: When GENCS –W is used to create a WCF service, it applies the ServiceContract attribute to the CLASS that is created, rather than to the INTERFACE. So for xfNetLink .NET WCF services both of the above references should point to the CLASS.

Other than that, the code should work for any WCF service.

Now all that remains it to add the code to stop the WCF service when the Windows service stops. In the procedure division of the OnStop method, add this code:

protected override method OnStop, void
    endparams
proc
    host.Close()
    host.Finalize()
endmethod

Build the Windows Service

It’s time to build the application and see how good your typing is!

  • In Solution Explorer, right-click on your Windows Service project and select Build.
  • Check the output window to make sure your application built correctly. You’re looking for something like this:

 

------ Build started: Project: MyWcfHostService, Configuration: Debug Any CPU ------
========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========

If your application does not build correctly then you’ll need to review the instructions above and make sure that you completed the required steps.

Registering and Starting the Windows Service

Now that you have a Windows service there are only two more steps that you’ll need to complete before the service can be tested. Those steps are:

  • Register the service with Windows.
  • Start the service.

To register the service you’ll need to open a Visual Studio command prompt window and then go the the folder that contains your applications executable. This will generally be the binDebug or binRelease folder below your project. Once you’re there you should be able to register your service like this:

..binDebug> INSTALLUTIL MyWcfHostService.exe

Look for messages that indicate that the service was successfully installed, then start your service like this:

..binDebug> NET START MyWcfHostService

Look for messages indicating that the service was started correctly.

Testing the WCF Service

If your Windows service started correctly then your WCF service should now be running. To verify that it is, open a browser and navigate to the URI that was specified in the code.

http://localhost:8080

You should see a WCF service home page similar to this:

image

 

If you see a service page like this then you should be able to start using the service. Of course we haven’t talked about how to do that yet … that’s for another day!

Remember to Stop The Service

You probably want to stop and unregister your Windows Service before you forget that it’s running. To do do, return to the Visual Studio command prompt and use commands like these:

..binDebug> NET STOP MyWcfHostService
..binDebug> INSTALLUTIL /u MyWcfHostService.exe

Exposing WCF services using Synergy .NET Interop

By Steve Ives, Posted on at 11:20 am

Steve Ives

In this post I will explain how a WCF service can be created using a Synergy .NET Interop project. In my earlier post I explained how to use xfNetLink .NET to create a WCF service, which provided an easy way to create a WCF service for developers who were already using xfNetLink .NET and xfServerPlus. Now I want to show you an alternate approach that is somewhat similar in nature, but which does not require the continued use of xfNetLink .NET and xfServerPlus in final solution. Of course this might not be what you want if your Synergy server is a non-Windows system.

This is the fourth in a series of posts relating to the various ways in which Synergy developers can use of Windows Communication Foundation (WCF) when building their applications. The posts in the series are:

  1. Building Distributed Apps with Synergy/DE and WCF
  2. Exposing WCF Services using xfNetLink .NET
  3. Hosting WCF Services in an ASP.NET Web Application
  4. Exposing WCF services using Synergy .NET Interop (this post)
  5. Self-Hosting WCF Services
  6. Exposing WCF services using Synergy .NET

What is Synergy .NET Interop

Before we get started we better make sure you know what a Synergy .NET Interop project is. In a nutshell an Interop project is a way of creating a .NET assembly containing various classes, where the external interface of those classes is defined by a collection of Traditional Synergy xfServerPlus methods, and the Synergy records that are referenced by the parameters of those methods. The idea is that the classes exposed by the assembly created by an Interop project have the exact same external interface that would be created if those same methods were defined in a Method Catalog and exposed via xfServerPlus and xfNetLink .NET. So the primary use case for an Interop assembly is to allow developers with existing applications which use xfNetLink .NET and xfServerPlus to factor those tools out of their solution, resulting in a pure .NET application.

In the same way that GENCS has an optional –W command line switch which essentially transforms the resulting .NET assembly into a WCF service, the Synergy .NET Interop project has a project option which does the exact same thing.

So let’s get started. Here’s how to do it. Remember, an Interop project allows you to expose a Synergy .NET assembly based on one or more traditional Synergy methods and records, but there are some prerequisites:

  1. The Synergy methods must make use of the recently introduced attributes and documentation comments, so that the external interface of the method is entirely defined within the code. The Interop project does not use a Synergy Method Catalog. For more information on this you can refer to a blog post that I wrote back in 2009 called Wave Goodbye to the MDU.
  2. The records that are referenced by the parameters of the methods must be defined in a repository, but this would always have been the case if you were using xfServerPlus.
  3. Generally the data files that are accessed by your methods should be moved to the Windows server where the WCF service will be hosted, so that the files can be accessed locally. If your data files need to stay on a non-Windows server then of course you could use xfServer to access the files remotely.
  4. You’ll need to have a copy of the source code for the Synergy methods available on the Windows development system where you are using Synergy .NET.

These are the steps that you’ll need to complete in order to create a Synergy .NET Interop assembly from your existing Synergy methods and repository structure definitions:

Create an Interop Project

The first step in the process is to create a new Synergy .NET Interop Assembly project:

  • Open Visual Studio and create a new Synergy .NET Interop Project.
  • From the menu, select File > New > Project.
  • In the Installed Templates list select Synergy/DE > Interop.
  • Set the name and location of the new project as required (here I’m naming the project MyInteropAssembly and setting the location to my c:temp folder).
  • Click the OK button to create the new project.

 

image

When you create an Interop project a new source file called SynergyRoutines.dbl is automatically included in the project. This file contains various utility routines that are used by the interop project in order to expose the same interface that xfNetLink .NET does. You shouldn’t need to be concerned with this code, and shouldn’t modify it. Simply close the file.

Add Synergy Method Source Files

Having created the Interop project the next step is to add the source code for your Synergy methods to the project. Remember that the methods that you include in an Interop project are Traditional Synergy subroutines and functions that include whatever {xfMethod} and {xfParameter} attributes are required in order to completely document the external interface of the methods within the source files.

imageFor clarity when creating an Interop project I also like to include my method source files in a folder within the project, and I generally name the folder “Methods”. This is entirely optional though.

  • In solution Explorer, right-click on your Interop project and from the context menu select Add > New Folder.
  • Change the name of the folder to Methods and press enter.
  • Right-click on your new Methods folder and from the context menu select Add > Existing Item….
  • Use the resulting open file dialog to browse to the location of your Synergy method routines, select them all, and then click the Add button to add the routines to your project.

In Solution Explorer your project should now look something like the image on the right.

Before we move on let me make a couple of things clear. Firstly it is important that you know that when you add existing files to a project using Add > Existing Item, those files are COPIED into your project folders. If you prefer to leave the source files in their existing location then you can use Add > Reference Existing Item.

The second thing that you need to understand is that in the example I am using here the nature of the methods that I am using is relatively simple, and the methods don’t have external dependencies on other routines in libraries, don’t use include files, etc. If your methods do have such dependencies then you will need to decide how best to resolve those dependencies.

Set Environment Variables

It is likely that you will need to set some environment variables in order for your code to be able to compile and run. It is almost certain that you will need to at least set the environment variables that allow your repository to be located and accessed, and in the case of the code that I am using, at runtime an environment variable named DAT is used to specify the location of the data files that are accessed by the code.

Synergy .NET development projects include the ability to set environment variables in the development environment via properties of the project:

  • In Solution Explorer, right click on your project and from the context menu select Properties.
  • In the project properties dialog, to the left side, select the tab named Environment Variables.
  • Set whatever environment variables are required in order for your code to compile and run.
  • Save your changes by selecting File > Save from the menu.
  • Close the project properties dialog.

In the case of the code I am using for this example I needed to set the following environment variables:

image

By the way, the tools in Synergy .NET also honor the same mechanisms for setting environment variables as Traditional Synergy on the Windows platform. So if the environment variables that you need are already present in your system environment, or are provided by the synergy.ini or synuser.ini files then you won’t need to set them here.

Build an Interop Assembly

You should now be able to build your interop assembly.

  • In Solution Explorer, right-click on your project and from the context menu select Build.
  • Check the output window, you should see something like this:
------ Build started: Project: MyInteropAssembly, Configuration: Debug Any CPU ------
========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========

 

imageIf your assembly did not build then you’ll need to resolve any errors that you may have before you proceed. The most likely cause for errors at this point will be external dependencies that are not catered for.

Check out what happened in your project. If you look in Solution Explorer you will notice that a new folder called GeneratedCode was created, and some new source files were added to the folder. These new files are at the center of how Interop projects work.

The method source files that you added to the project, in the Methods folder, were Traditional Synergy subroutines and functions. The job of an Interop project is to expose the functionality of those methods in the same way that xfNetLink .NET’s GENCS utility does, and GENCS creates .NET classes that represent the Synergy methods, and the data structures exposed by those Synergy methods.

The Interop project essentially does the same thing, except that where GENCS created C# code which uses xfNetLink .NET and xfServerPlus to call the Synergy methods, the Interop project creates Synergy .NET code which calls the Synergy methods directly.

In the code used in my example the Synergy methods that I added to the project were all part of an interface named “SynergyServer”. This was defined by the {xfMethod} attributes that were present in each of the source files that I included into the project. You will notice that the GeneratedCode folder now includes a source file named SynergyServer.dbl, and if you were to look in the source file you would see that it contains a class named SynergyServer, which in turn contains methods named GetAddressForUpdate, GetAllCustomers and so on. These methods correspond to the Synergy methods that I originally included in the project.

Additionally you will notice that the GeneratedCode folder also contains several source files which represent the record definitions which are exposed by the parameters of my methods. For each record that is exposed the interop project has created a class to represent that data structure. These classes are named Address, Address_type, Contact and so on.

However, if you were to look in the source files that have been generated into the GeneratedCode folder you might notice that these generated classes do not contain any ServiceContract, OperationContract, DataContract or DataMember attributes. In other words, the classes can’t currently be exposed via WCF.

Note: You should not make changes to any of the code in the GeneratedCode folder, because this code will be recreated each time you build the project. 

Expose a WCF Service

As I briefly discussed in an earlier post, in order for classes to be exposed via WCF it is necessary to apply various attributes to those classes:

Nature of Item Required Attribute
Class containing callable methods ServiceContract
Callable method OperationContract
Class defining a data structure DataContract
Accessible member in a data structure DataMember

 

In an Interop project, these attributes can be automatically added to the generated classes by enabling a project option called “Generate WCF Contracts”.

  • In Solution Explorer, right-click your project and select Properties.
  • In the project properties dialog, to the left side, select the tab named Interop.
  • Check the Generate WCF Contracts option.
  • In most cases it’s also a good idea to set the Generate out parameters property to out instead of the default value of “ref”.
  • Save your changes by selecting File > Save from the menu.
  • Close the project properties dialog.
  • In Solution Explorer, right-click on your project and from the context menu select Build.
  • Check the output window and make sure that your assembly built correctly.

 

Note: The default behavior of generating out parameters as ref is to maintain compatibility with what GENCS does by default, but when exposing a new WCF service to a new client application you would always want output parameters defined as type out.

 

Now take a look at the various source files in the GeneratedCode folder. You should notice that the ServiceContract, OperationContract, DataContract and DataMember attributes are present as required.

Host the Service

That’s it, you just used a Synergy .NET Interop project to define and create a WCF service. Of course before you can actually do anything with the service you will need to host it somewhere. One option is to host the service in an ASP.NET Web Application as described in my earlier post.

However, sometimes developers don’t want to have to setup and maintain an IIS web server simply to host a WCF service. Luckily there are other ways of hosting a WCF service that do not require IIS, and that will be the topic of the next post in this series.


Building Windows 8

By Steve Ives, Posted on August 29, 2011 at 1:50 pm

Steve Ives

As Microsoft’s new Build Windows conference draws ever closer the rumor mill about what the focus of the conference will be is gathering momentum. This is due in no small part to the fact that with the conference only two weeks away there is still no published agenda. But that doesn’t seem to have deterred people from attending, I would estimate that there are generally over 10,000 delegates at these events, and this conference has been sold out since early August!

That being said it’s not too hard to figure out from the name of the conference that the focus will be on the next version of the Windows operating system, which Microsoft have “code named” Windows 8! What might be a surprise to a lot of people however is the scale of the change that is on the way next year, because from all available information it’s looking like the default Windows 8 experience will be VERY different from anything that Windows users have experienced in the past.

This suspicion was confirmed recently when Microsoft posted a video entitled “Building Windows 8 – Video 1” on one of their development team blogs. The video was also uploaded to YouTube, and I’ve embedded it in this post … take a look:

As you can see the default Windows 8 experience is very different, and is sure to bring some new challenges for developers who want to deploy applications that take advantage of the new capabilities of the platform. From Microsoft’s demonstration it is clear that traditional Windows applications will continue to be supported, so there is no need to panic, but as software developers we all need to be thinking about how a change of this magnitude could affect our businesses.

For some time now Microsoft has touted WPF and Silverlight as the flagship technologies of choice for building UI’s for .NET applications. But with Windows 8 is all that about to change? The video makes it clear that the primary UI technologies used to build Windows 8 applications are HTML5 and JavaScript, neither of which have a particularly strong toolset presence in Visual Studio 2010. So for many of the developers at the Build Windows conference the main question will be “what’s new in Visual Studio 2012 and .NET Framework 4.5 that will help me build applications for Windows 8?”.

Clearly Microsoft believe that mobile and tablet devices are going to become far more predominant in the future, and are actively planning for this by merging the various operating systems that are used on the various types of computing platforms. And of course they are not alone in this endeavor as Apple’s recent release of OS X Lion also somewhat takes this approach, although not quite to such a radical degree.

Of course there is another group of people who also have a bunch of work to do, and that’s the hardware vendors. If Windows 8 is to be successful one would assume that the default for personal computer and laptop screens will need to change to be predominantly touch-enabled devices. While it is clearly stated in the video that the new UI will work just fine with a mouse and a keyboard, I for one am very skeptical about how WELL it will work in that mode! And of course the availability of the hardware is only a part of the story … we must also consider how long it will take companies to replace existing hardware with new touch-sensitive devices.

Now don’t get me wrong … I’m not suggesting for one minute that there will be a big rush to do so, and I’m absolutely suggesting that a major change of this type could take many years … but for some of us, with certain types of applications, in certain market places, adopting these new capabilities could offer significant rewards.

By the way, I’m not a betting man but I’d lay good money on the fact that there will be a setting to disable the new Windows 8 UI in favor of reverting to Windows 7’s Aero UI, and I’d also be comfortable predicting that many corporations will be doing just that. So again, don’t panic! While the new UI may make for a fabulous demo, and may be a fantastic way of interacting with photos and videos, and browsing the web, will it really provide a suitable platform for presenting business software to commercial users? Actually, in some cases the answer will be a resounding YES … but in other cases the more traditional approach to presenting applications will continue to be far more appropriate.

Of course in order for Synergy developers to be ready for Windows 8, Synergex must be ready first. I will be attending the Build Windows conference, as will three of my colleagues from the Synergy Development team. We’ll do our best to keep you informed about what we learn.

By the way, if you’re interested in keeping track of what’s going on with Windows 8 then a good place to start is Microsoft Development’s Building Windows 8 BLOG. The blog has some interesting articles, and already has several more videos discussing these new features.


Hosting WCF Services in an ASP.NET Web Application

By Steve Ives, Posted on July 1, 2011 at 3:39 pm

Steve Ives

There are several ways that you can use Synergy/DE tools to expose WCF services, but regardless of which way you decide to create a service, the next decision you have to make is how to host it. By hosting a WCF service you expos the service and make it possible to use it from other applications. In this post I will introduce you to one way that WCF services may be hosted, via an ASP.NET web application and an IIS web server. In a later post I will show you how to host WCF services without this requirement for an IIS web server.

This is the third in a series of posts relating to the various ways in which Synergy developers can use of Windows Communication Foundation (WCF) when building their applications. The posts in the series are:

  1. Building Distributed Apps with Synergy/DE and WCF
  2. Exposing WCF Services using xfNetLink .NET
  3. Hosting WCF Services in an ASP.NET Web Application (this post)
  4. Exposing WCF Services using Synergy .NET Interop
  5. Self-Hosting WCF Services
  6. Exposing WCF services using Synergy .NET

 

A WCF service is simply a collection of one or more classes in an assembly, but the whole point of implementing a WCF service is to make those classes available to be used by other applications. And those applications will often be located on different networked systems from the service itself. So, in order for a WCF service to be useful, it needs to be “hosted” somewhere, and that somewhere needs to be available on a network.

There are three basic ways that WCF services can be hosted:

  1. Inside a Web application located on a Web server.
  2. Using Windows Process Activation Services (WAS). This mechanism was introduced in Windows Server 2008 and provides a mechanism for hosting WCF services without requiring a Web server.
  3. Services can be “self” hosted by some custom .NET application. For example, developers often host WCF services inside a Windows Service application.

In this post I will show you the basics of hosting a WCF service in an ASP.NET web application. In a future post I will go on to show how to self-host services.

Setting up basic hosting for a WCF service inside an ASP.NET Web application is very easy, but as Synergy .NET doesn’t have support for creating Web applications. You’ll have to use another .NET language, either C# or VB.NET. However, don’t worry about that too much, because there won’t actually be any code in the Web application!

  • Start Visual Studio 2010 and create a new ASP.NET application:
    • From the menu, select File > New > Project.
    • Under Installed Templates, select Visual C# > Web > ASP.NET Empty Web Application.
    • Chose the name and location for your new Web application.
    • Click the OK button to create the new project.
  • Add a new WCF Service to the project:
    • From the menu, select Project > Add New Item.
    • Under Installed Templates, select Visual C# > Web > WCF Service.
    • Enter the name for your new service. The name will be part of the service endpoint URI that the client connects to, so pick something meaningful. For example, if your service allows orders to be placed then you might name the service something like OrderServices.svc.
    • Click the Add button to add the new service to the project.

You will notice that three files were added to the project:

image

 

In addition to the service (.svc) file that you named, you will see two C# source files. These files were added because Visual Studio provided all of the files that you would need in order to expose a new WCF service that would be manually coded in these files. But what we’re trying to do is host a WCF service that already exists in another .NET assembly.

  • Delete the two C# source files by right-clicking on each and selecting delete.

In order to expose a WCF service that exists in another assembly, the first thing we need to do is add a reference to that assembly, to make the classes it contains available within the new Web application.

  • From the menu select Project > Add Reference and then select Browse.
  • Locate and select the assembly containing your WCF service and add a reference to your project.
  • If the assembly you selected was created using xfNetLink .NET then you will also need to add a reference to the xfnlnet.dll assembly, as is usual when using xfNetLink .NET

You’ll need to know that namespace and class name of the WCF service in your assembly. If you can’t remember this that double-click on the assembly that you just referenced and then use Object Browser to drill into the assembly and figure out the names. All that remains is to “point” the service file at your WCF service class.

  • Double-click on the service (.svc) file to edit it. You should see something like this:

image

Edit the file as follows:

  • Change Language=”C#” to Language=”Synergy”.
  • Change Service=”…” to Service=”YourNamespace.YourWcfClass” (obviously replacing YourNamespace and YourWcfClass with the namespace and class name of your WCF service).
  • Remove the CodeBehind=”…” item … there is no code-behind, the code is all in the other assembly.
  • Save the file.

So you should now have something like this:

image

If your service is based on an assembly created using xfNetLink .NET then you have one final configuration step to perform. You need to tell xfNetLink .NET how to connect to xfServerPlus. You can do this by using the Synergy xfNetLink .NET Configuration Utility (look in the Windows Start Menu) to edit the new web applications Web.config file. If your xfServerPlus service is not on the same machine as your new web application then you must specify a host name or IP address, and if xfServerPlus is not using the default port (2356) then you must also specify a port number. When you’re done, the Web.config file should contain a section like this:

image

That’s it, you’re done. You should now have a working WCF service!

  • To see if the service has really been hosted, right-click on the service (.svc) file and select View In Browser.

You should see the service home page, which will look something like this:

image

If you see this page then your service is up and running. By the way, the URI in your browsers address window is the URI that you would use to add a “Service Reference” to the service in a client application … but we’ll get on to that in a later post.

Of course, all we have actually done here is set up a web application to host a WCF service, but we’re using Visual Studio’s built in development web server (Cassini) to actually host the service. If you were doing this for real then you’d need to deploy your new web application onto a “real” IIS web server.

We’re not done with the subject of hosting WCF services; in fact we’ve only really scratched the surface. One step at a time!

In my next post in this series I will show you how to Expose a WCF services using Synergy .NET Interop.


Exposing WCF Services using xfNetLink .NET

By Steve Ives, Posted on at 1:40 pm

Steve Ives

Following a recent enhancement to the product in Synergy 9.5.1, developers can now use xfNetLink .NET to create and expose Windows Communication Foundation (WCF) services. In this post I will describe how to do so.

This is the second in a series of posts relating to the various ways in which Synergy developers can use of Windows Communication Foundation (WCF) when building their applications. The posts in the series are:

  1. Building Distributed Apps with Synergy/DE and WCF
  2. Exposing WCF Services using xfNetLink .NET (this post)
  3. Hosting WCF Services in an ASP.NET Web Application
  4. Exposing WCF Services using Synergy .NET Interop
  5. Self-Hosting WCF Services
  6. Exposing WCF services using Synergy .NET

 

The basic approach is pretty easy; in fact it’s very easy. In 9.5.1 we added a new -w command line switch to the gencs utility, and when you use the new switch you wind up with a WCF service. I told you it was easy!

So, what changes when you use the gencs –w switch? Well, the first thing that changes are the procedural classes that are generated, the ones that correspond to your interfaces and methods in your method catalog, change in the following ways:

  1. Three new namespaces (System.Runtime.Serialization, System.ServiceModel and System.Collections.Generic) are imported.
  2. The class is decorated with the ServiceContract attribute. This identifies the class as providing methods which can be exposed via WCF.
  3. Methods in the class are decorated with the OperationContract attribute. This identifies the individual methods as being part of the service contract exposed by the class, making the methods callable via WCF.
  4. If any methods have collection parameters, the data type of those parameters is changed from System.Collections.ArrayList to System.Collections.Generic.List. Changing the collection data type is not strictly necessary in order to use WCF, but results in a more strongly prototyped environment which is easier to use, and offers more benefits to developers in terms of increased IntelliSense, etc.

The next thing that changes are any data classes, the ones that correspond to the repository structures that are exposed by the parameters of your methods, that are generated. These data classes change in the following ways:

  1. Two new namespaces are imported. These namespaces are System.Runtime.Serialization and System.ServiceModel.
  2. Each data class (which corresponds to one of your repository structures) that is generated is decorated with the DataContract attribute. This identifies the data class as a class which can be used in conjunction with a WCF service, and which can be serialized for transmission over the wire.
  3. Each public property (which corresponds to a field in the structure) is decorated with the DataMemeber attribute. This attribute identifies each property within the class as one which will be serialized, and as a result will be visible to client applications which use the WCF service.

By the way, if you use a Workbench “.NET Component Project” to create your xfNetLink .NET assemblies then there isn’t currently an option in the component information dialog to cause the new –w switch to be used. So, for the time being, what you can do is add the switch to the Workbench “Generate C# Classes” tool command line. To do this you would go into project properties for the component project, go to the Tools tab, select the “Generate C# Classes” tool, then add the –w at the end of the command line, like this:

image

We’ll be adding a new checkbox to the component information dialog in 9.5.3 later this year.

By the way, by using the gencs –w switch you make it possible to use the resulting classes as a WCF service, but you don’t have to do so … you can continue to use the classes as a regular xfNetLink .NET assembly also. Why would you want to do that? Well, I sometimes use gencs –w just to turn my collection parameters into generic lists!

I have submitted a working example to the Synergy/DE CodeExchange, contained within the zip file called ClientServerExamples.zip. Within the example, the following folders are relevant to exposing and consuming a WCF Service using xfNetLink .NET:

Folder / Project

Description

xfServerPlus

Contains the Workbench development environment for xfServerPlus and the exposed Synergy methods. If you wish to actually execute the examples then you must follow the setup instructions in the readme.txt file.

xfNetLink_wcf

Contains the Workbench project used to create the xfNetLink .NET client assembly with the WCF attributes.

3_xfpl_xfnl_wcf_service

Contains the Visual Studio 2010 solution containing an ASP.NET web application used to host the WCF service, as well as three example client applications, written in Synergy .NET, C# and VB.

So, the gencs –w command line switch you make it possible to use the resulting classes to directly expose a WCF service, but there is still the matter of how to “host” the service in order to make it accessible to remote client applications, and that’s what I will begin to address in my next posting.


Optimizing your Visual Studio 2010 Experience

By Steve Ives, Posted on June 22, 2011 at 3:52 pm

Steve Ives

Visual Studio 2010 is one of the best IDE’s I have ever seen and worked with, and provides, out of the box, a truly impressive array of tools to make developers lives easier and more productive. But, as good as it already is, there is still room for improvement.

Luckily Microsoft has provided an extensible platform and an easy way for people who develop extensions to be able to publish those extensions to developers. Check out the “Extension Manager” utility that you will find on the Tools menu.

emThe extension manager, as suggested by its name, provides a simple UI which allows you to locate, download and install all kinds of Visual Studio extensions. The actual extensions are hosted on-line at a web site called the Visual Studio Gallery. Some extensions are written by Microsoft, some by third-parties. Some provide additional functionality throughout Visual Studio, while some are specific to a particular language. Some add new project or item templates to Visual Studio, while others add complex capabilities in a range of scenarios.

Go take a look, there are a lot of extensions to choose from. If you’re looking for recommendations then personally I think that there are two extensions that no Visual Studio 2010 developer should be without … apart from the Synergy Language Integration for Visual Studio extension of course. You’ll find these extensions in the gallery, and if you sort the list by “Highest Ranked” then they should be close to the top of the list … they are VERY popular! My favorite extensions are both published by Microsoft, and both are free. They are called:

· Productivity Power Tools

· PowerCommands for Visual Studio 2010

I won’t even attempt to go into detail about what these extensions do, because the list of enhancements is a long one. You can click on the hyperlinks above and read all about them in the gallery. Suffice it to say that if for some reason I wind up working on a system other than my own laptop, and these extensions are not installed, I miss them both terribly!


Building Distributed Apps with Synergy/DE and WCF

By Steve Ives, Posted on at 1:22 pm

Steve Ives

At the recent SPC’s in Chicago and Oxford several of the sessions that I presented were focused on networking, and in particular on the various tools and technologies that are available to Synergy developers to allow them to build and deploy distributed software applications. In particular I spent quite a bit of time talking about a technology called Windows Communication Foundation.

This is the first in a series of posts relating to the various ways in which Synergy developers can use of Windows Communication Foundation (WCF) when building their applications. The posts in the series are:

  1. Building Distributed Apps with Synergy/DE and WCF (this post)
  2. Exposing WCF Services using xfNetLink .NET
  3. Hosting WCF Services in an ASP.NET Web Application
  4. Exposing WCF Services using Synergy .NET Interop
  5. Self-Hosting WCF Services
  6. Exposing WCF services using Synergy .NET

What is WCF

WCF is a part of the .NET framework that provides a powerful and flexible way to implement network communication between the various parts of a distributed software application. For many years Synergy developers have been able to build distributed applications using xfServerPlus and xfNetLink. Many have done so, and have deployed a wide variety of applications based on these technologies. When developing a new .NET client application developers would use xfNetLink .NET to gain access to their Synergy business logic and data.

This approach has served us well over the years, will continue to do so, and is still the most appropriate solution in some scenarios. But in some other scenarios using WCF might now be more appropriate, and could help developers to broaden the capabilities of their applications in several key areas, some of which are:

WAN Communication

Because the communication between xfServerPlus and xfNetLink uses a custom protocol which operates on a “non-standard” port, it may not be appropriate for use over wide area networks and the Internet. The primary problem here is that there is a high chance that this communication would be blocked by firewalls, some of which may be outside of your control. WCF supports multiple network transport protocols, the most basic of which is HTTP. This means that it is designed with the Internet in mind, and is very suitable for implementing applications which communicate over the Internet.

Multiple Endpoints

Another advantage of WCF is that the same WCF service can be exposed via multiple “endpoints”, and each of these endpoints can be configured to use different communication protocols and mechanisms. For example a single service could be exposed via one endpoint which uses HTTP and SOAP which would be suitable for a wide variety of client applications to be able to access from anywhere (including via the Internet), while at the same time being exposed by a second endpoint which uses low-level TCP/IP communications and binary messaging protocols suitable for use by applications running on the same local network as the service, at much higher performance. A single client application could even be configured to dynamically switch between these endpoints based on the current location of the user.

More Client Options

When using xfServerPlus and xfNetLink, client applications must be written in a programming language which is able to use one of the supported xfNetLink clients (COM, Java or .NET), but because WCF services can be interacted with via “standard” protocols such as HTTP and SOAP there are many more client application possibilities, because almost all development environments and programming languages are able to use these basic protocols.

Asynchronous Support

WCF also provides the ability to easily support asynchronous communication between clients and servers. When a client application calls an xfServerPlus method the client must wait for the execution of the method to complete, and for any resulting data to be returned, before performing any other processing. Using WCF it’s easy to support asynchronous method support, where the client application can call a method and then continue with other processing, later receiving an event when the remote method has completed its operation and when any resulting data is ready for use. This approach can make client applications appear to be much more dynamic and responsive.

Bi-Directional Communication

In many distributed software applications interaction between the client and the server is initiated by some event in the client application which requires some subsequent processing in the server application. But in some situations it is necessary for the server application to be able to, at will, initiate some processing in the client application. Unfortunately xfServerPlus and xfNetLink don’t really address this use case, but it can be addressed with WCF, because WCF service endpoints can be “self-hosted” within any type of .NET application. This means that as well as a client application having the ability to interact with a WCF service on some server somewhere, the client can also expose a WCF service, which the server application (or in fact any other application) could interact with.

WCF is an extensive subject area, and in this BLOG I’m not even going to attempt to teach you about the specifics of using WCF. Instead I’m simply going to try to make you aware of some of the reasons that you might want to explore the subject further, and make sure that you know about the various ways that you can get started.

There are several ways that Synergy developers can utilize WCF in their applications, and I’ll briefly describe each of these mechanisms below.

WCF via xfNetLink .NET

In xfNetLink .NET 9.5.1 a new feature was introduced which gives developers a lot of additional flexibility in the way that they build their applications, or rather the way that they communicate between the various parts of the application. This new feature is enabled through a new command line parameter to the gencs utility (-w). When you use this new option, two things change.

When you use gencs –w, the first thing that changes is that various attributes are added to the wrapper classes that are created by gencs. These attributes in turn allow those generated classes (and the assembly that they are compiled into) to be directly exposed as a WCF service. Previously, if a Synergy developer wanted to expose a WCF service which in turn exposed their Synergy business logic and data, they have to manually “wrap” their xfNetLink .NET procedural and data classes in other classes which in turn exposed a web or WCF service.

The second change when using gencs -w is that any collections which are exposed by the application API are transformed from un-typed “ArrayList” collections, to more useful and flexible “Generic List” collections. This change will require a small amount of re-coding in any existing client applications, but results in a significantly enhanced development experience.

This mechanism is likely to be of interest to developers who already have an existing solution using xfNetLink .NET and xfServerPlus, and want to take advantage of some of the additional capabilities of WCF, or to developers who wish to expose a new WCF service where the server application exposes code running on a UNIX, Linux or OpenVMS server.

WCF via Synergy .NET Interop

Another way that Synergy developers can expose WCF services is via Synergy .NET’s “Interop” project. The primary purpose of an Interop project is to allow developers with existing xfServerPlus applications to migrate their existing Synergy methods to a native .NET environment. By adding their method source code to an interop project they are able to execute those methods directly in the .NET environment, instead of using xfNetLink .NET and xfServerPlus to execute the methods with traditional Synergy on a remote server.

The Interop project works by generating Synergy .NET “wrapper classes” for your traditional Synergy methods (subroutines and functions) and data structures (records). The external interface of these wrapper classes is very similar to that of the C# wrapper classes produced by xfNetLink .NET’s gencs utility. The primary goal of the Interop project is to allow developers to migrate existing applications from a mixed .NET / traditional Synergy environment to a 100% .NET environment, with only minor changes to the code of existing client applications.

When you create an Interop project in Visual Studio, one of the options that you have (via the project properties dialogs) is to “Generate WCF contracts”, and as discussed earlier in this article, the effect of this is to add various attributes to the generated wrapper classes so that they can be directly exposed as a WCF service.

So again, for Synergy developers, this approach can provide a quick-and-easy way to expose a WCF service based on existing code. Again, this approach is likely to be primarily of interest to those who already have xfServerPlus based applications running on the Windows platform.

WCF via Synergy .NET

Both of the previous approaches were primarily focused on those who already use xfServerPlus, and both provide an easy way to get started with WCF. However in both of the previous scenarios, the external interface of your WCF service is directly defined by the interface to your underlying traditional Synergy methods (subroutines and functions), and the WCF data contracts that are exposed are defined by the repository structures exposed by the parameters of those methods. So, while the WCF capabilities provided by xfNetLink .NET and by the Synergy .NET Interop project are easy to use, you don’t get full control over the exposed interface and data. If you want that finer level of control, or if you’re just getting started with server application development and don’t have existing xfServerPlus methods, there is a better way to go.

The third way that Synergy developers can leverage WCF is by using Synergy .NET to create an all-new WCF service with native .NET code. This task was possible in 9.5.1 when Synergy .NET was first introduced, but has been made much easier through the introduction of a new “WCF Service Library” project template in 9.5.1a.

Creating a new WCF service via a WCF Service Library is the way to go for developers who want to write an all-new service application, or who don’t mind a little extra effort to re-work some existing code in order to factor out some of the “wrapper” layers involved with the previous two approaches. As a result you will have full control of the resulting WCF service, and the contracts that it exposes.

Wrapping Up – For Now

So, as you can see, Synergy/DE is now providing you will all kinds of new and exciting things that you can do in your Synergy applications, and I firmly believe that WCF is one of the most important, and powerful. In the near future I will be writing several additional BLOG posts which will explain these three ways of exposing WCF services in more detail, and I’ll also try to provide more detail about WCF generally. So for now, be thinking about how your existing distributed applications are built, and what things you might wish to improve about them. Or be thinking about that all-new distributed application that you’ve wanted to get started on. If you’re thinking of enhancing or implementing a distributed application, then using WCF is almost certainly the way to go.


Don't miss a post!

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

Recent Posts Categories Tag Cloud Archives