Phone800.366.3472 SupportGet Support DocumentationDocumentation Resource CenterResource Center
search
close
Open Menu

Synergex Blog


Using Synergy .NET in Multi-Threaded Applications

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

Steve Ives

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


2013 DevPartner Conference Tutorials Now Available On-Line

By Steve Ives, Posted on June 30, 2013 at 10:24 am

Steve Ives

We and many of our customers have just returned home from another great conference, during which we introduced another batch of Synergy/DE related developer tutorials. These tutorials have now been added to those from previous years and made available on-line. The tutorials can be downloaded via a small client application. If you already have the tutorials client installed then you will see the new content when you start the application. If not you can download and install the tutorials client from the following URL:

http://tutorials.synergex.com/Download.aspx

 


We’re Ready for for the 2013 DevPartner Conference … Are You?

By Steve Ives, Posted on June 5, 2013 at 9:36 pm

Steve Ives

photo

What you’re looking at is fifty terabytes of external USB 3.0 hard drives (for the oldies amongst us that’s the equivalent of 10,000 RL01’s), and we’ll be giving them away during the DevPartner conferences in Bristol (UK) and Providence (RI) in the next three weeks.

Of course it’s not really about the hardware, anyone can get that! It’s really about what’s ON the hardware. Each of these disks contains a Windows 8 virtual machine that includes the latest version of Synergy/DE (10.1.1a, just released today) and Microsoft Visual Studio 2012 (Update 2).

But it’s not really about the products that are installed on the virtual machines either. It’s really about what you can learn from these “freebies”, and how you can use what you have learned to the benefit of your employer.

During this years DevPartner conferences the Synergex Professional Services Group will introduce seventeen all-new hands-on tutorials that will provide you with a quick-start to all of the latest features of Synergy/DE. And in addition we’ll be including updated versions of three of the most popular tutorials from previous conferences.

It’s not too late! If you haven’t already signed up for the 2013 DevPartner Conference then all you have to do is visit this link:

http://conference.synergex.com/register.aspx

But talk to your boss before you visit the link, because if your company is already a member of the DevPartner program you might find that your conference registration is free!

We are all looking forward to seeing you again for another great conference.


HTTP API Enhancements in DBL 10.1

By Steve Ives, Posted on January 14, 2013 at 11:24 pm

Steve Ives

In addition to introducing several totally new features DBL 10.1 also includes enhancements to the client portion of the HTTP API. These enhancements make the API significantly easier to use, and also make it possible to achieve things that were not previously possible.

Since the HTTP API was introduced in DBL 7.5 the client part of the API consisted of two routines. These routines are HTTP_CLIENT_GET and HTTP_CLIENT_POST. As suggested by their names these routines allowed you to issue GET and POST requests to an HTTP server. A GET request is a simple request to a server in which a URI is sent to the server and a response (which may include data) comes back. A POST request is slightly different in that in addition to the URI, additional data may also be sent to the server in the body of the HTTP request.

When dealing with an HTTP server it isn’t always possible to pre-determine the amount of data to be sent to the server, and it’s certainly not possible to know how much data will come back from the server for any given request. So in order to implement the HTTP API it was necessary to have a mechanism to deal with variable length data of any size, and at that time the only solution was to use dynamic memory.

Using dynamic memory worked fine, any data to be sent to the HTTP server as part of a POST request was placed into dynamic memory and the memory handle passed to the API, and any data returned from a GET or POST request was placed into dynamic memory by the API and the handle returned to the application. Dealing with variable length strings using dynamic memory isn’t particularly hard, but the fact of the matter is that while only a single line of code is required to perform an HTTP GET or POST, typically several lines of code were required in order to marshal data into and out of memory handles.

When the System.String class was introduced in DBL 9.1, so was the opportunity to simplify the use of the HTTP API, and that became a reality in DBL 10.1.

In order to maintain compatibility with existing code the HTTP_CLIENT_GET and HTTP_CLIENT_POST routines remain unchanged, but they are joined by two new siblings named HTTP_GET and HTTP_POST. These routines are similar to the original routines, essentially performing the same task, but they are easier to use because they use string objects instead of dynamic memory. And because the string class has a length property it is no longer necessary to pass separate parameters to indicate the length of the data being sent, or to determine the length of the data that was received. String objects are also used when passing and receiving HTTP headers.

So the new HTTP_GET and HTTP_POST routines make the HTTP API easier to use, but there is a second part to this story, so read on.

One of the primary use cases for the HTTP API is to implement code that interacts with Web Services, and in recent years a new flavor of Web Services called REST Services (REST stands for Representational State Transfer) has become popular. With traditional Web Services all requests were typically sent to the server via either an HTTP GET or POST request, but with REST Services two additional HTTP methods are typically used; the HTTP PUT and DELETE methods.

Many of you will be familiar with the term “CRUD” which stands for “Create, Read, Update and Delete”. Of course these are four operations that commonly occur in software applications. The code that we write often creates, reads, updates or deletes something. When designing traditional Web Services we would often indicate the type of operation via a parameter to a method, or perhaps even implement a separate method for each of these operations. With REST based web services however, the type of operation (create, read, update or delete) is indicated by the type of HTTP request used (PUT, GET, POST or DELETE).

To enable DBL developers to use the HTTP API to interact with REST services an extension to the HTTP API was required, and DBL 10.1 delivers that enhancement in the form of another two new routines capable of performing HTTP PUT and DELETE requests. As you can probably guess the names of these two new routines are HTTP_PUT and HTTP_DELETE. And of course, in order to make these new routines easy to use, they also use string parameters where variable length data is being passed or received.

You can find much more information about the HTTP API in the DBL Language Reference Manual, which of course you can also find on-line at http://docs.synergyde.com. In fact, if you’re feeling really adventurous you could try Googling something like “Synergy DBL HTTP_PUT”.


Unit Testing with Synergy .NET

By Steve Ives, Posted on at 11:02 pm

Steve Ives

One of the “sexy” buzz words, or more accurately “buzz phrases” that is being bandied around with increased frequency is “unit testing”. Put simply unit testing is the ability to implement specific tests of small “units” of an application (often down at the individual method level) and then automate those tests in a predictably repeatable way. The theory goes that if you are able to automate the testing of all of the individual building blocks of your application, ensuring that each of those components behaves as expected under various circumstances, testing what happens when you use those components as expected, and also when you use them in ways that they are not supposed to be used, then you stand a much better change of the application as a whole behaving as expected.

There are several popular unit testing frameworks available and in common use today, many of which integrate directly with common development tools such as Microsoft Visual Studio. In fact some versions of Visual Studio have an excellent unit testing framework build in; it’s called the Microsoft Unit Test Framework for Managed Code and it is included in the Visual Studio Premium and Ultimate editions. I am delighted to be able to tell you that in Synergy .NET version 10.1 we have added support for unit testing Synergy applications with that framework.

I’ve always been of the opinion that unit testing is a good idea, but it was never really something that I had ever set out to actually do. But that all changed in December, when I found that I had a few spare days on my hands. I decided to give it a try.

As many of you know I develop the CodeGen tool that is used by my team, as well as by an increasing number of customers. I decided to set about writing some unit tests for some areas of the code generator.

I was surprised by how easy it was to do, and by how quickly I was able to start to see some tangible results from the relatively minimal effort; I probably spent around two days developing around 700 individual unit tests for various parts of the CodeGen environment.

Now bear in mind that when I started this effort I wasn’t aware of any bugs. I wasn’t naive enough to think that my “baby” was bug free, but I was pretty sure there weren’t many bugs in the code, I pretty much thought that everything was “hunky dory”. Boy was I in for a surprise!

By developing these SIMPLE tests … call this routine, pass these parameters, expect to get this result type of stuff … I was able to identify (and fix) over 20 bugs! Now to be fair most of these bugs were in pretty remote areas of the code, in places that perhaps rarely get executed. After all there are lots of people using CodeGen every day … but a bug is a bug … the app would have fallen over for someone, somewhere, sometime, eventually. We all have those kind of bugs … right?

Anyway, suffice it to say that I’m now a unit testing convert. So much so in fact that I think that the next time I get to develop a new application I’m pretty sure that the first code that I’ll write after the specs are agreed will be the unit tests … BEFORE the actual application code is written!

Unit testing is a pretty big subject, and I’m really just scratching the surface at this point, so I’m not going to go into more detail just yet. So for now I’m just throwing this information out there as a little “teaser” … I’ll be talking more about unit testing with Synergy .NET at the DevPartner conferences a little later in the year, and I’ll certainly write some more in-depth articles on the subject for the BLOG also.


Symphony Framework and CodeGen Helping Customers Migrate to a WPF UI

By Steve Ives, Posted on August 1, 2012 at 4:20 pm

Steve Ives

Richard Morris and I have just returned from a seven-day consulting engagement with a customer, and I wanted to share with you some information about our achievements during the visit. The customer we visited with is one of our larger ISV’s and has an extensive Synergy application, much of which is implemented using the Synergy/DE UI Toolkit. As with many applications, life started out on cell-based systems many years ago, but for many years now it has been deployed exclusively on Windows systems.

SymphonyLogoThe customer in question had listened to us talking about Symphony Framework and CodeGen at the Chicago DevPartner conference, and was interested in how they might be able to leverage them to accelerate the process of updating the look and feel of their applications by replacing their existing UI Toolkit user interface with a Windows Presentation Foundation (WPF) user interface. Needless to say we were eager to help, because we believe we have a great story to tell, and some great tools to share!

Most in the industry would agree that WPF represents the current “state of the art” when it comes to implementing user interfaces for Windows Desktop applications. We have had our eyes on WPF for some time now, and have been learning about it’s capabilities. We have also been encouraging customers to consider WPF as a great way of updating the UI of their existing applications, or implementing the UI of new applications. And thanks to new features in Synergy/DE 9.3 and 9.5 there are a couple of great ways of doing just that.

For existing applications the Synergy/DE .NET Assembly API can be used to embed WPF directly into existing applications. Of course one of the main benefits of doing so is that the application can be enhanced screen-by-screen, without the need for extensive re-writes and long development cycles. Of course for new development Synergy .NET can be used to build all-new applications with a WPF user interface. There is also a realistic migration path between the two; you can chose to start off by enhancing screens in an existing application via the .NET Assembly API today, and then ultimately migrate the entire application to a native Synergy .NET solution. All very “doable”.

Before I get into the specifics of our tools and what was achieved, there is one more thing that I should mention. Just as most industry pundits would agree that WPF is the way to go for Windows Desktop applications, most would also tell you that there is a specific WAY that WPF applications should be implemented; it’s called the “Model-View-ViewModel Design Pattern”, which is often abbreviated as MVVM.

A design pattern describes a methodology for implementing a software solution to a certain problem. The MVVM design pattern sets out a way of designing software such that there are clear lines of demarcation between code that deals with different parts of an application. Specifically it prescribes how the “Model” (code which implements an applications data definitions and business logic) should be separated from the “View” (code which implements the applications user interface), and how these two entities should be joined by the “ViewModel”. We’ve talked quite extensively about MVVM in the past, and there are lots of great resources available on line, so I don’t intend to go into more detail here. Suffice it to say that adhering to the MVVM design pattern is strongly recommended when implementing WPF applications.

I mentioned earlier that we have been focusing on WPF for some time now, and also on MVVM. But as well as just learning about the technologies and patterns, Richard Morris has been “beavering away” at his home office in England pondering the question “how can we help our customers to easily use WPF and MVVM in the context of their existing Synergy applications?”. Once he’d finished pondering the question, he then started coding the answer … and the Symphony Framework was born.

So just what is the Symphony Framework and how can it help you? Well in a nutshell, Symphony Framework is an MVVM Framework (library) which can be leveraged by Synergy developers to significantly simplify the process of implementing WPF user interfaces in their Synergy applications, while at the same time adhering to the best practices prescribed by the MVVM design pattern. Symphony Framework can be used to incrementally add WPF UI to existing applications in conjunction with the .NET Assembly API, and it can be used to implement all-new Synergy .NET applications with a WPF UI.

Some areas of Symphony Framework are designed to specifically address the somewhat unique challenges associated with migrating UI Toolkit applications, but the framework is in no way limited to working only with UI Toolkit applications. To cut a long story short, if you have an existing Synergy application and want to “spiff it up” with a fabulous new WPF UI, then Symphony Framework might just become your new best friend!

I’m not going to go into a huge amount of detail about HOW this all takes place, but I do want to briefly describe some of the common steps. For the purpose of this illustration I’ll ask you to imagine an existing UI Toolkit application (but remember, it doesn’t have to be Toolkit), and imagine that I want to do a gradual screen-by screen migration to a WPF UI, initially driven by the existing application (via the .NET assembly API). What might the steps be? Well, for each screen (or window) we might:

  • Create a “Model” class that describes and exposes the underlying data to be worked with. Model classes inherit a lot of functionality from base classes in the Symphony Framework.
  • Create a “View” using WPF.
  • Create a “ViewModel” that exposes the information in the model to the view, and provides the functionality needed to service the requirements of the view. ViewModel classes also inherit a lot of functionality (in some cases all of the required functionality) from base classes in the Symphony framework.

The code for all of the steps described above would be implemented in Synergy .NET and would be compiled into a .NET assembly.

  • Use the .NET assembly APIs “GENNET” tool to create Traditional Synergy “wrapper” classes that allow these various components to be accessed and manipulated from the existing Traditional Synergy application.
  • Create a “Manager” class (we’re still trying to figure out what to call this bit!) which contains the bulk of the code required to instantiate and drive the underlying .NET code.
  • Modify the existing application to present the new WPF UI instead of the existing UI, primarily by accessing functionality exposed by the “Manager” class.

You might be tempted to see this last bullet point and think “there is is, modify our existing code, that’s the hard and time consuming part”! But don’t let this thought put you off, believe it or not the changes that typically need to be made to the existing code are relatively small and painless. This is due in no small part to the things that the Symphony Framework is doing for you!

During our visit with our customer we initially worked on what it would take to replace existing “lookup” routines with new WPF implementations. In a UI Toolkit application a lookup routine is often accessed via a “drill method” associated with an input field, and often uses a combination of input processing to allow the user to define search criteria, and list processing to present matching results. When the user picks an item the associated value is returned into the input field. We managed to get this process down to a fine art. and this is where CodeGen comes in.

CodeGen1We were able to create CodeGen templates which allowed us to generate most of the code that was required to “switch out” a UI Toolkit lookup for a WPF lookup. We were able to code generate 100% of the Model class, 100% of the View class, 100% of the ViewModel class, and 100% of the “Manager” class. All that remained was to modify the existing application to utilize the new code instead of the existing UI Toolkit UI. Figuring out how to do the first lookup probably took in the order of half a day, but with the process and CodeGen templates in place, the next four lookups probably took around 20 minutes each to implement. We left it at that, because we were confident that we had the process down at that point.

Then we moved on to other areas, attacking a “maintenance” type program. The process is actually remarkably similar, and actually not that much more complex, again because much of the base functionality required is inherited from the Symphony Framework. By the end of our engagement we pretty much had that process down also, and again much of the required new code was being code generated, leaving only relatively minor changes to the existing application to be made.

Of course not all aspects of an application are as simple to deal with as the scenarios that I just described, some parts of an application and its UI get pretty complex, and it isn’t always possible to code generate all of the required components, and it isn’t always possible for the Symphony Framework to provide all of the required functionality in the form of base classes. Programmers still have a role to play, and thank goodness for that! But I do believe that the tools that Richard and I have developed can play a significant role in projects of this type, and it’s not just theory, we just proved it!

Actually that’s probably not a totally fair statement for me to make, as there are several other customers who have already used the Symphony Framework with great effect. Just as there are many customers who already use CodeGen to generate many different types of code to address various application needs. But Richard and I don’t often get to work together on a project, and this is perhaps the first time that we have really tried to use both of these tools together and push them HARD to see what could be achieved. And I for one am confident that everyone involved, including our customer of course, was pretty impressed with the results.

By the way, if your goal is to build an all-new WPF application directly in Synergy .NET, while retaining and re-using large portions of your existing code, then the steps aren’t that different to those described above. The Models, Views, ViewModels and “Manager” classes would be essentially the same, but would be driven by a Synergy .NET WPF application rather than by a DBR application via the .NET Assembly API. We actually proved this recently while preparing a proof of concept demo for another customer. Having been provided with the code for a small sample application, and some sample data, we migrated the UI of the application to WPF using the steps described above. Once the application was working with a new UI, and armed with the classes that we had just created, we were able to re-purpose those classes without change in a 100% Synergy .NET WPF application. In all the process took about four hours … but probably could have been completed faster had we not been sat at a bar at the time! This really is pretty cool stuff!

Before finish I do want to stress one more time that the Symphony Framework and CodeGen tools are not just about UI Toolkit applications on Windows. Symphony Framework helps you migrate to an ultra-modern WPF UI on Windows, but the starting point could easily be an application that runs on a cell-based platform today. And CodeGen can be and is being used on all systems supported by Synergy.


Release Notifications for CodeGen and Symphony Framework

By Steve Ives, Posted on July 31, 2012 at 5:19 pm

Steve Ives

At the DevPartner conference I told people that in order to receive notifications for new releases of the open source CodeGen and Symphony Framework projects they should “Follow” the projects on CodePlex.

It turns out that “following” a project doesn’t send release notifications. If you want to get release notifications then you must go to the “Downloads” page for each project and subscribe for notifications. If you are interested in either of these two projects then I would recommend that you do just that, as we’ve done some great enhancements to both recently, and there are more great things still in the pipeline.

The downloads page for CodeGen is at http://codegen.codeplex.com/releases and the downloads page for Symphony Framework is at http://symphonyframework.codeplex.com/releases.


Are you Ready for Windows 8 and Synergy 10?

By Steve Ives, Posted on at 4:49 pm

Steve Ives

As discussed at the recent DevPartner Conferences, support for Synergy applications on Windows 8 will be introduced in Synergy 10, which is currently available as a beta release. Microsoft has announced the launch date for Windows 8 and Visual Studio 2012 will be October 26th, so it is reasonable to expect that the final versions of Windows 8 and Visual Studio 2012 will be available to developers via MSDN some time soon.

As well as introducing many new features and enhancements in Synergy .NET, Synergy 10 also includes some very significant new features on all of the Traditional Synergy platforms, particularly in the area of SDBMS (that’s ISAM to us mere mortals!). These changes are introduced in a new ISAM revision 6. It is important that you test your applications with Synergy 10 as soon as possible.

As soon as Windows 8 is available to your customers you are likely to start getting calls to install your applications on Windows 8, and that will REQUIRE you to install Synergy 10. At the very least, Synergex recommends that you install the Synergy 10 beta on a system (not necessarily Windows 8 ) and validate that your current application runs without errors. And if you don’t have s system to to that with, remember that it’s easy to build a Virtual Machine to use for testing.

Even better would be to rebuild your applications with version 10 and make sure you don’t have any issues there. And even better than that would be to do a little beta testing and try out some of the many cool new Synergy 10 features. There are even REWARDS for finding bugs!!!

You can find more information about Synergy 10 at http://www.synergyde.com/products/synergyde_beta.aspx


Synergy .NET Without Purchasing Visual Studio

By Steve Ives, Posted on June 20, 2012 at 1:16 pm

Steve Ives

It occurs to me that we may have forgotten to tell you about something important … sorry! Of course if you were at either of the recent Synergex DevPartner conferences then you will already know this, but if not then “listen up” because this could save you some money!

The development environment for Synergy .NET is provided by Microsoft Visual Studio. For Synergy 9 we support Visual Studio 2010 Professional or higher. If a developer wants to develop with Synergy .NET then they would install Synergy/DE and Visual Studio 2010, and then install “Synergy Language Integration for Visual Studio” (we call it SLI because it’s less of a mouthful) to add all of the Synergy .NET capabilities and templates alongside the other Microsoft languages like C# and Visual Basic. Many developers already have Visual Studio 2010 so this isn’t a problem … but what if you don’t?

Well … good news! In addition to purchasing Visual Studio 2010 there is also a free solution. It’s called Visual Studio 2010 Shell (Integrated) and you can download it directly from Microsoft. Basically the Integrated Shell is a bare bones version of Visual Studio, with all of the other languages stripped out. It’s not much use on its own, but if you install it and then install SLI … hey presto you have a full Synergy .NET development environment!

If you do decide to try this out then please remember that Synergy .NET requires Visual Studio 2010 Service Pack 1, so you’ll need to install that after installing Integrated Shell, but before installing SLI.

You can download the files that you’ll need from these locations:

Visual Studio 2010 Shell (Integrated)

http://www.microsoft.com/en-us/download/details.aspx?id=115

Visual Studio 2010 Service Pack 1

http://www.microsoft.com/en-us/download/details.aspx?id=23691

By the way, when Synergy 10 is released later this year you will have a choice of two development environments. We’ll continue to support Visual Studio 2010, but we’ll also support Visual Studio 2012 … and there is an Integrated Shell available for it too, but the requirements are a little different. There is also something called Visual Studio 2012 RC Shell (Isolated), and you have to install that before you can install the Integrated Shell.

Visual Studio 2012 RC Shell (Isolated)

http://www.microsoft.com/en-us/download/details.aspx?id=29927

Visual Studio 2012 RC Shell (Integrated)

http://www.microsoft.com/en-us/download/details.aspx?id=29912

By the way, it appears that the Visual Studio 2012 RC Integrated Shell installation may have a problem. I found that it reported errors about missing components when I tried to install it. I also found that if I did a reboot between installing Isolated Shell and Integrated Shell – the errors went away!

If you do decide to play with Synergy 10 (the beta will be out very soon now) and Visual Studio 2012, and we really hope that you all will, remember that Visual Studio 2012 is currently release candidate. When the final product ships later in the year there will be new Isolated and Integrated shells to download and install.


Microsoft Surface

By Steve Ives, Posted on June 18, 2012 at 8:01 pm

Steve Ives

Get ready … here comes the big push! Microsoft today announced a new Windows 8 based tablet platform that they are calling “Microsoft Surface” (strange choice of a name, they already had a product with that name and it was literally the size of a table!), and they are boldly claiming that it will rival the almighty iPad. But then again they’d have to say that, otherwise people probably wouldn’t pay much attention!

surfaceDetails are still somewhat “sketchy” but it appears that there will be two initial models, the “Surface for Windows RT” which uses an NVIDIA ARM processor, and the thicker and heavier “Surface for Windows 8 Pro” tablet which uses an Intel Core i5 (Ivy Bridge) processor and not surprisingly will include a significantly larger battery.

You can find Microsoft information about the new device here, and Engadget have a pretty good write-up that addresses the differences between the two models which you can find here.


Microsoft Removes Installer Project Templates from Visual Studio 2012

By Steve Ives, Posted on June 13, 2012 at 8:09 am

Steve Ives

Microsoft has recently announced that the various “Visual Studio Installer” project templates that were included in Visual Studio 2010 will NOT be included in Visual Studio 2012. These project templates are used within Visual Studio 2010 to build Windows Installer setup packages for .NET applications.

I’m writing this post because one of the 2012 tutorials that was published during our recent DevPartner conferences was based on using these these project templates; it showed developers how to build an installation package for a simple windows application. I wanted let customers know that the specific mechanism taught during the tutorial will not work in future versions of Visual Studio.

Bear in mind, however, the end result of the tutorial is a “standard” Windows Installer MSI package, and many of the techniques and concepts presented are still very much applicable to building any Windows Installer packages using other products.

Unfortunately there will no longer be any free tools for building installations included with Visual Studio, so developers will likely have to select one of several third-party products (e.g. InstallShield) to build their installation packages.


Synergy/DE On-Line Tutorials

By Steve Ives, Posted on at 7:24 am

Steve Ives

During the 2011 Synergex Conferences we introduced several self-paced tutorials that allowed developers to work through various programming scenarios in order to learn new development techniques or become familiar with new Synergy/DE features. In all we published sixteen tutorials last year, and the feedback that we received from customers was very positive.

Because of the success of the tutorials in 2011 we decided to repeat the process for the 2012 DevPartner conferences, introducing another sixteen tutorials covering a wide range of subjects. Again the feedback from customers has been extremely positive.

During the conferences we provided a Virtual Machine pre-configured with the required development tools and data files, but we also wanted to make the tutorials available to a much wider audience, so I am delighted to announce that the tutorials are now available on-line at http://tutorials.synergex.com.

On this web site you will find a brief description of each of the tutorials, as well as information about any prerequisites for each tutorial. Most of the tutorials are completed either in Workbench or Visual Studio, so generally you’ll need a Windows system with a recent version of Synergy/DE (some tutorials require the very latest version), Visual Studio 2010 SP1, and Synergy Language Integration for Visual Studio. There is a requirements page on the web site that goes into much more detail.

The tutorials are downloaded and accessed via a tutorials client application which can be downloaded and installed (via Click-Once) by clicking the install button on the Download page.

Once you installed the tutorials client application it will present a list of the available tutorials. A globe icon to the right indicates that the tutorial has not been downloaded, and a hard drive icon indicates that the tutorial has been downloaded to your system.

Once you have downloaded a tutorial you can double-click on it to view the instructions for the tutorial. If the tutorial includes pre-configured Workbench workspaces or Visual Studio solutions then toolbar buttons provide quick access to those items.

The sixteen tutorials from 2011 are available immediately, and the sixteen new tutorials from the 2012 conference will become available on-line on Thursday 14th June.

We hope that you enjoy the tutorials and find them useful.

Synergex Professional Services Group


CodeGen 4.1 Released

By Steve Ives, Posted on June 7, 2012 at 12:48 am

Steve Ives

Recently I announced that our code generator, CodeGen, had been published on CodePlex for everyone to use. Today I am delighted to announce that we have released a new version of CodeGen which includes some significant new features.

It is now possible to generate code which is based on information drawn from multiple repository structures, which makes it possible to generate many more types of routines and classes than ever before.

Also we have added the ability to launch code generation based on a repository file definition. CodeGen will make any structures that are assigned to the file available to the template when generating code.

We’re now starting planning for the next release. CodeGen can already be used to generate code for Synergy Language, C#, Visual Basic and Objective-C, and one of the features we’ll be adding in the next release is data type mappings and new field loop tokens for the Java language.

For more information about CodeGen refer to the CodeGen site on CodePlex, which you will find at http://codegen.codeplex.com.


LinkedIn Passwords Hacked

By Steve Ives, Posted on June 6, 2012 at 7:27 pm

Steve Ives

It is being widely reported today that password information from the social network site LinkedIn has been compromised. It is currently unclear at whether matching username information (email addresses) has also been compromised.

I STRONGLY recommend that LinkedIn users change their passwords as soon as possible. And if you are in the habit of using the same password on multiple web sites, many of which use an email address as a username, then I would recommend that you change your password on those other sites also.


Windows 8 Release Preview Available Now

By Steve Ives, Posted on May 31, 2012 at 11:42 pm

Steve Ives

If you hadn’t already heard, Microsoft today announced that the Windows 8 Release Preview is now available for download. As I talked about in my Introduction to Windows 8 session at the DevPartner Conference in Chicago, my colleagues and I are strongly urging all Synergy developers who build and deploy Synergy applications on Windows to download the release preview now and start testing your installations and applications.

If you attended my session you will know that there are some significant changes in Windows 8 that developers need to be aware of, and we want to help our customers to avoid any potential problems when Windows 8 starts shipping.

As well as the new operating system there is also a new version of the .NET Framework (4.5) which is an “upgrade” to Framework 4.0. This upgrade will be delivered to systems via Windows Update, and replaces the 4.0 version. We have already encountered problems with several existing .NET applications (not just Synergy .NET, just .NET generally) and we strongly advise you to test your .NET applications on Framework 4.5 also.

This version of Windows 8 is likely to be fairly close to whet the final released version will be, but Microsoft have already stated that they are still developing in some areas. If things go “as normal” then we might expect the final RTM (Release to Manufacturing) versions in around two months time, but no guarantees of course! Microsoft have also publicly stated that they are in good shape for a final release well in time for the 2012 “holiday season” … presumably they have big ideas about Santa Claus delivering lots of Windows 8 ARM-based tablets this year … we’ll have to wait and see how well that works out!

You can get more information and download the Windows 8 Release Preview here:

http://windows.microsoft.com/en-US/windows-8/release-preview

By the way, if you’re more interested in the server version of the O/S then the Windows Server 2012 Release Candidate is also available for download now:

http://technet.microsoft.com/en-us/evalcenter/hh670538.aspx?ocid=&wt.mc_id=TEC_108_1_33

We’re still in conference mode here at Synergex, but once the UK conference in York is out of the way I’ll write more about the changes in Windows 8, and provide more information about what you need to know before your customers start buying Windows 8 systems.


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