Tag Archive for v10

I upgraded, why didn’t the CorasWorks version change?

A frequent question to the CorasWorks Support team concerns the version of the Version 11 Platform installed into an environment.  Oftentimes, the user has performed an upgrade to the latest release, but is confused when the version displayed by a component indicates they are running v11.0.  The goal of this article is to explain why this phenomena is happening and how to check the version of a component.  Before we discuss Version 11, let’s look back on how the installations were handled with Version 10.

History: Installations and Upgrades with Version 10
When CorasWorks first released Version 10, we followed the generally accepted guidance concerning the installation process for SharePoint.  The Platform required a full deployment process, meaning that the 40+ components included in the platform were deployed into SharePoint.

Generally speaking, this installation methodology worked well, albeit slowly.  However, the deployment installation approach introduced two problems for our users.  First, when users upgraded to a new release, they first had to retract the original components from their SharePoint environment and then deploy the new components.  This took a great deal of time, particularly for multiple server customers, and could introduce stability issues within their SharePoint server environments.

Second, the components used on a web part page stored the version used.  When a v10.2 Basic Grid was placed onto a page, the Grid stored its version in the information on the page.  When the page was loaded, it looked for its stored version (v10.2) or later.  If an earlier version was found, SharePoint generated an error.  In short, this behavior meant that a site template built using a later version of the Platform could not be used in an earlier version.

Imagine a user created a site in their Development environment where they were testing Version 10.3 of the CorasWorks Platform.  When they went to implement their site template into a Production environment running the earlier Version 10.2, SharePoint would throw errors on the site.  The site template was looking for the v10.3 version of the components and wouldn’t run with the v10.2 version!

Our goal in developing Version 11 was to overcome both of these challenges.  It was clear when speaking with our users that they wanted an easier upgrade path, one that took minutes instead of hours.  Our larger customers and partners asked for a way of building site templates that would not introduce errors when running on an older version.  Version 11 accomplished both of these goals.

Overcoming These Problems
Version 11 has a different upgrade process.  Instead of requiring a complete retraction of the components, we instead offer MSI-only upgrades that update the DLLs within the environment.  Users who have Version 11 installed can download the smaller, upgrade-only package from the Community’s My Place.  This smaller package includes a new setup file.  Generally speaking, the upgrade process is to uninstall the current CorasWorks setup file from the web front end and to install the new one.  This process is run on each web front end and should take less than half an hour to install.

This installation process has been an overwhelming success for us.  Nearly all users like this new installation process, but some have noticed that the version of the components does not change.  This is expected behavior and a requirement for our DLL-only upgrades.  With the Version 11 release, CorasWorks has locked the version of our components being reported to SharePoint.  As a result, we can use the MSI file to update the DLLs on the web front ends without having to redeploy the components.

The benefit of locking the version of the components is a faster, more reliable upgrade process as well as removing the problem with web pages looking for the wrong version of the components.  Users who are building using our v11.1.01 release can save their sites as templates and use them to build sites in an environment using the earlier v11.1 release.  The components won’t throw an error as, internally, they are looking for the v11.0 version of the DLLs.  The result is a win-win for customers and partners alike.

How to Determine the Installed Version
Having said that, how do we check for the version of a component to ensure an installation was complete?  If you are a server administrator, the easiest way is to check the version of the installed MSI file within the web front end’s Add/Remove Programs via the server’s Control Panel.  If you don’t have rights to the server, you can check via the browser.  Go to a web part page with the CorasWorks component on it and add the following to the end of the URL in the address bar: ?version=coras.  This will flip all of the CorasWorks components on the page into “version mode” and show their version information.  This information is being displayed for you alone; all other users of the page will see the normal displays.  To get out of version mode, click on the “Close” button on the page or remove the ?version=coras from the end of the URL.

Once you’re in the version window, you should see something similar to this:

There are four fields presented.  The first is the Title of the component and the second is the Organization who created it (CorasWorks Corporation).  The Version displayed for the Basic Components is always and will not change, regardless of the version of the Platform installed.  Remember, we’ve locked the version of the component being reported to SharePoint to allow us to have DLL-only upgrades and for backward compatibility between releases.

The Date value is different and is the key for determining the release of the component.  With the Basic components, the Date indicates when the component was last updated and it is what we use to determine when a component was released.  In short, the Version of the components won’t change, but the Date of the components will!

%d bloggers like this: