This is the most common issue on windows server 2008/2012 when .net 3.5 'features' are not installed but 4.5 is.
Any ideas how to fix this?

The Feed Builder crops some file names if the output folder path ends with \

Steps to reproduce:

1. Enter a Project Output Folder path that ends with \
2. Press Refresh files

Expected outcome: All file names in the list should be complete

Actual outcome: Some file names are cropped

Work around: Remove the trailing \ from the Project Output Folder

Right now, Updater failing shows only a MessageBox saying "Update failed".

I'd like to be able to overwrite that, and for example say something like "Couldn't update MyApplication. Please try again and if that fails contact your administrator" (it's an internal Enterprise app)

Hi. I have a working project. the only problem is this:

• the app is installed with an installer, it works for admins and non admins.
• the self-update works ok (I run the app as admin) it restarts and it is updated
• the problem is that now the main .exe has permissions only for the admin user and admins. so when I log in as a non-admin user, it doesn't work anymore.

any idea how can I fix this?

TIA

NAU should log all steps and decisions. Logging should also be exposed to classes implementing the internal interfaces (conditions, readers, tasks, sources).

Logging would be update-process wide, and transferred over the IPC back and forth if cold-updates are required.

No dependencies, although integration with external libs could be nice for existing projects interested in a unified logging mechanism. This could probably be achieved by integrating https://github.com/damianh/DH.Logging

Exceptions should be logged as well where possible (async mode).

If you have selected multiple conditions in the FeedBuilder it will change the type of all subsequent to the first condition from or to or-not.

This logic is incorrect since there always is multiple conditions, the FileExistsCondition is always included first. The side effect of this is that files are not created if they do not exist.

Remove the hasFirstCondition from the FeedBuilder to resolve this.

Could you perhaps make a Nuget package for this library? Would make things a lot smoother :)

When calling the async version of library methods, exceptions are caught and not handled, therefore allow for silent failing, which is bad. Those exceptions should be made known of, by rethrowing and them to the calling process, or passing them to a new OnUpdateError/Failure event.

Hi,
I have a issue that looks like permission-related but I need a little more information to find out whats going on there and fix that. I have the app deployed on multiple test computers and only on one system I run into the following problem:

log4net.LogManager.GetLogger("gui").Debug("Applying");
if (!UpdateManager.Instance.ApplyUpdates(true)) {
    log4net.LogManager.GetLogger("gui").Debug("Failed: " + UpdateManager.Instance.LatestError);
}

If I run the app as a normal user, the app hangs on applying updates and won't restart. Task manager shows no updater-exe (=foo.exe). If I run the app as an administrator, everything works fine.

Now my problem is: how to get that debugged? Where my I find information helping me? (logger doesn't log anything)

Currently, all IUpdateTask objects are applied in one go, or rollbacked at once if something goes wrong. NAppUpdate should support grouping of tasks, so a feed (NauXml or any other) can specify what tasks are related to each other. This way, even if one task fails another unrelated one can still be completed.

Presenting a new "BatchTask" object will probably do the job, but some thought needs to be put into this, so functionality such as update descriptions, reporting, rolling back etc will all be compatible and done correctly.

When I check for updates, using "UpdateManager.Instance.CheckForUpdates()", I get the InvalidOperationException "Another update process is already in progress", although nothing else is running this update. What could be causing this to get marked as in progress?

The mutex used to make the updater wait until the caller application is closed may be being dismissed too early. Perhaps it needs to be declared in a broader scope, and be disposed of only when UpdateManager.Instance is being disposed. If the mutex is cleaned up as part of the GC process, that could be a simple solution (though not elegant).

The problem is running updater takes a couple of seconds in my case.

During that time the main application is inaccessible, but since it's taking a while the users might want to relaunch it, thinking something has failed, and that it should have re-launched by now.

Having some sort of (other than the console) UI (A progress bar + some text saying "update in progress") would help.

https://github.com/LogosBible/bsdiff.net/blob/master/src/bsdiff/BinaryPatchUtility.cs

Probably via FilePatchTask

Hi,
first I want you to thank you for that great work on NAppUpdate!

I'm integrating NAppUpdate into an application that is deployed to the Program Files-directory on lots of computers. To make sure we don't have double efforts on deployment I want to double-check that everything works well and I still have some issues. I'm not sure if that is because of how NAppUpdate works or if I made something wrong.

Basically the application checks for updates on launch and starts the update automatically. This works well in most cases but we seem to have some permission problems sometimes, especially after the application upgraded itself after auto-run on logon, which leads to an endless loop of update, restart, update, restart, ...

It seems like you did everything to make sure the UAC prompt is not triggered to not disturb the user. But as the application directory and its contents are not writeable for the application in most cases and/or the user don't have admin privileges the UAC prompt has to be triggered. TrickUK provided a patch/commit for that, but it only checks the directory where the writes are going to and leaves the files that are modified out. After checking what the update process does and what it doesn't, I think I figured out that the problem is the write access to the files in the directory but not to the directory itself.

So this leads me to the question: do I make something wrong in either my setup or the way I use NAppUpdate or should I extend TrickUKs permission check to every file that's going to be modified? That would elevate the rights if required and fix that - or did I miss something?

Create and support an update feed generator functionality.

Here's a very initial take on what I consider to be a flexible and effective approach. Would love to hear any thoughts:

1. Pointed to an application directory containing a NAppUpdate DLL, the feed-generator desktop application will use Reflection to detect all objects implementing IUpdateTask, IUpdateCondition and IUpdateSource in all assemblies in that folder. It will then list them in a nice organized manner (TBD), and allow the creation of complex feeds in a simple graphical UI.
2. Explanatory text to be displayed by the application for each task / condition / source type will be available through fields we will add to the interfaces, and each implementing object will have to provide. Another option is to use a class-scope attribute. This text will then be displayed in tooltips etc.
3. The rest of the fields in each object will use attributes to signal the feed generator their exact state - if they are required, what's their expected input (regex?), validation type (?), and explanatory text (to be displayed in forms by the input fields). I will provide concrete examples at a later time.
4. Output will be in the NauXml format (which should be standardized further prior to any release of such application). I don't think there is any reason to support any other formats.
5. NauXml Feeds should be able to be read into this application. This perhaps will need some code adjustments in the core, and will also allow to load other feed types.
6. It would be nice if we could create all that in a such a way so it could be used by a web application too, at least partially, to allow feed updates on the fly.

To allow for dynamically loading assemblies during cold-updates

Otherwise, this exception is thrown

System.BadImageFormatException: This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded. (Exception from HRESULT: 0x8013101B)

I normally prefer to move the samples to a separate branch, this to keep the main branch as clean as possible.

Did it on my fork of the project: https://github.com/robinwassen/NAppUpdate2

@synhershko What are your thoughts on this?

When working on a program and the update framework is in the feed, the nappupdate dll can't be written to because it is loaded. There needs to be an out of band updater for the dll that doesn't use the dll.

I have problem with loading configuration. When I try to open some previously created configuration all settings remains the same and only when I close and reopen the application, the changes are visible... Calling Settings.Default.Reload(); in FeedBuilderSettingsProvider is apparently not enough to reload the settings form the copied file.

Make NAppUpdate more consumer-friendly, by allowing it to report detailed status back of what has been done and what hasn't. A simplistic approach will probably make sense (a generic and predefined XML structure, for example).

Such a report will be generated on the FS, based on a path provided by the consumer application. It should be the consumer's responsibility to provide a valid and writable path, to remember it (in case a restart was required), to interpret it, and to delete it when done.

BooleanCondition needs unit tests since it is a vital part of the system, it might also help explaining how they actually work.

Hi
in FileVersionCondition.cs in IsMet()
add:
if(Version!=null)
{
Version = Version.Replace(", ", ".");
}

it is replacing it for versionInfo but not for Version.
Thanks!

UpdateFeed example:

<Feed>
  <Tasks>
    <FileUpdateTask hotswap="false" updateTo="subdirectory\remotefile.dll" localPath="subdirectory\localfile.dll">
      <Description />
    </FileUpdateTask>
  </Tasks>
</Feed>

FileUpdateTask.Execute tries to do a backup if the destination file already exists, but does not create subdirectories to the backup folder if needed; therefore, a DirectoryNotFoundException is thrown:

System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\work\myproject\Backup\subdirectory\localfile.dll'.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.File.InternalCopy(String sourceFileName, String destFileName, Boolean overwrite)
at System.IO.File.Copy(String sourceFileName, String destFileName)
at NAppUpdate.Framework.Tasks.FileUpdateTask.Execute()
at NAppUpdate.Framework.UpdateManager.ApplyUpdates(Boolean relaunchApplication)
at aviita.CAF.client.util.AppUpdater.CheckForUpdates(AppUpdaterMode updaterMode)

fix: see attached diff file

I just need help to fix this error, I dont know if this is a bug

I've got the following in my update xml:

When a client using NA localization (MM/DD/YYYY) runs it, this rule works as expected. The file is downloaded, the updated copy has a timestamp after EDT midnight on 9/20, all is good.

When a client using EU localization (DD/MM/YYYY) tries to update, the rule fires every single time. This results in EU users seeing the update dialog every time the application is launched, even after they've updated. Changing their OS date localization format to MM/DD/YYYY causes the rule to perform properly, but it's a bit inconvenient of a workaround.

Let's say that I have MyUpdateTask bundled within MySuperApp.exe, v.0.1.
As soon as I release new version of this assembly, updater starts failing as it loads only new version of assembly into AppDomain and not the old one.

System.Runtime.Serialization.SerializationException: Unable to find assembly 'MySuperApp, Version=0.1, Culture=neutral, PublicKeyToken=null'.
   at System.Runtime.Serialization.Formatters.Binary.BinaryAssemblyInfo.GetAssembly()
   at System.Runtime.Serialization.Formatters.Binary.ObjectReader.GetType(BinaryAssemblyInfo assemblyInfo, String name)
   at System.Runtime.Serialization.Formatters.Binary.ObjectMap..ctor(String objectName, String[] memberNames, BinaryTypeEnum[] binaryTypeEnumA, Object[] typeInformationA, Int32[] memberAssemIds, ObjectReader objectReader, Int32 objectId, BinaryAssemblyInfo assemblyInfo, SizedArray assemIdToAssemblyTable)
   at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(BinaryObjectWithMapTyped record)
   at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
   at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler handler, __BinaryParser serParser, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
   at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream, HeaderHandler handler, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
   at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream, HeaderHandler handler, Boolean fCheck, IMethodCallMessage methodCallMessage)
   at NAppUpdate.Framework.Utils.NauIpc.ReadDto(String syncProcessName)
   at NAppUpdate.Updater.AppStart.Main()

Please, how can I create an condition to update just newer files. It aways download/update ALL MY FILES on my XML

<FileUpdateTask hotswap="true" updateTo="file://192.168.1.13/Build/AppSplash.dll" localPath="AppSplash.dll"> <Description>UPDATE-7</Description> <Conditions> <FileDateCondition type="not" what="older" timestamp="09/20/2011 00:00:00 -4:00"/> </Conditions> </FileUpdateTask> <FileUpdateTask updateTo="file://192.168.1.13/Build/AppUpdate.dll" localPath="AppUpdate.dll" lastModified="131051666731851911"> <Description>UPDATE-8</Description> </FileUpdateTask> <FileUpdateTask hotswap="true" updateTo="file://192.168.1.13/Build/Leiame.txt" localPath="Leiame.txt" lastModified="131051666731851911"> <Description>UPDATE-LEIAME</Description> <Conditions> <FileDateCondition what="newer" timestamp="09/20/2011 00:00:00 -4:00"/> </Conditions> </FileUpdateTask> <FileUpdateTask hotswap="true" updateTo="file://192.168.1.13/Build/SimplesEmpresa.txt" localPath="SimplesEmpresa.txt" lastModified="131051666731851911"> <Description>UPDATE-SIMPLESEMPRESA</Description> <Conditions> <FileDateCondition type="and" what="newer" timestamp="09/20/2011 00:00:00 -4:00"/> </Conditions> </FileUpdateTask>

when use auto update app every time get bellow error.
Error while trying to install software updates
Could not launch cold update proc

ess.

I'm getting "task prepare failed" exception while calling UpdateManager.Instance.PrepareUpdates.
Now I can't figure out what the actual problem. I tried to look through Exception's Stack Trace, but it's almost empty. Here is a source code:

try
{
    task.Prepare(UpdateSource);
}
catch (Exception ex)
{
    task.ExecutionStatus = TaskExecutionStatus.FailedToPrepare;
    Logger.Log(ex);
    throw new UpdateProcessFailedException("Failed to prepare task: " + task.Description, ex);
}

If exception occurs while preparing a task - it is re-trown, so exception stack is empty and you can't find out a real problem reason.

My suggestion is to include it in inner exception, so you can see it's stack trace

Just running into an odd issue when trying to update a DLL from CefSharp3, libEGL.dll. Under FileVersionCondition.cs line 40: versionString = versionInfo.FileVersion will return product version which is 2.1.f4126d2b9eb0. This will cause Incorrect string format exception when we try to create new localVersion instance in the next line by simply pass this string into var localVersion = new Version(versionString).

Not sure if this is just an odd issue, it might be safer to use new Version (int major, int minor, int build, int revision) in both FileVersionCondition.cs and FeedBuilder to get the correct file version to avoid exception.

Just my 2 cents and thanks for the awesome work. Cheers! 👍

Hi,
I can't find updater.exe file which is included as a resource in "NAppUpdate.Framework" project which the downloaded zip file. From where can I get that file? Please help me.
Thanks & regards,
Aneesh Daniel

The current indentation is currently mixed between tabs and spaces, which sometimes makes a mess when people send pull requests.

@synhershko Should we settle for tabs as indentation for the whole project? I can do the dirty work of converting all indentation.

Hi, I hit the following error:
Debug Creating Temp directory C:\Users\Tomer\AppData\Local\Temp\149a22f3-9195-4577-aab9-43f79a89c9d0
Debug FileUpdateTask: Downloading foo.exe with BaseUrl of http://localhost:8888 to C:\Users\Tomer\AppData\Local\Temp\149a22f3-9195-
Debug FileUpdateTask: Prepared successfully; destination file: C:\Users\Tomer\bar\foo.exe
Debug Starting to process cold updates...
Debug Update process name: 'NAppUpdateProcess'
Debug Loading C:\Users\Tomer\AppData\Local\Temp\149a22f3-9195-4577-aab9-43f79a89c9d0\foo.exe
Debug Skipping (part of current execution)
Debug Loading C:\Users\Tomer\AppData\Local\Temp\149a22f3-9195-4577-aab9-43f79a89c9d0\NAppUpdate.Framework.dll
Debug Skipping (part of current execution)
Debug The application has terminated (as expected)
Debug Got 1 task objects
Debug Task "": RequiresAppRestart
Debug Executing...
Error
Could not replace the file
System.UnauthorizedAccessException: Access to the path 'C:\Users\Tomer\bar\foo.exe' is denied.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.File.Delete(String path)
at NAppUpdate.Framework.Tasks.FileUpdateTask.Execute(Boolean coldRun)
Debug Task execution failed
Error Update failed
Debug Re-launching process C:\Users\Tomer\bar\foo.exe with working dir C:\Users\Tomer\bar

I am using the latest sources from github.

Thanks,
Tomer

It is possible upgrade version that not require framework 2 / 3.5
cause some user don't have access to windows feature to enable them.

Last framework it is 4.6 it thing it is a good thing have framework 4 for prerequisite and not old framework.

We currently have two stale branches:

• better-tasks, last modified: 2011
• web-deployment, last modified: 2011

I do not know the state of them and I suspect that it would be tremendous amount of work to merge them into master since they are so far behind.

@synhershko Should we remove them?

I have this in my xml:

<FileUpdateTask localPath="d3dcompiler_43.dll" lastModified="130069068600000000" fileSize="2106216" version="9.29.952.3111">
  <Conditions>
    <FileExistsCondition type="or" />
    <FileVersionCondition what="below" version="9.29.952.3111" />
    <FileChecksumCondition type="or-not" checksumType="sha256" checksum="2F23182EC6F4889397AC4BF03D62536136C5BDBA825C7D2C4EF08C827F3A8A1C" />
  </Conditions>
</FileUpdateTask>

the problem is that the file is new, but after it updates (I know it updates because it updates other files), it doesn't create this new file. what I'm missing?

TIA

I'm writing a JSON feed reader and have encountered a limitation. (I use JSON as I never have liked XML)
I'm also have a small program that dynamically builds a feed from the current directory. This creates an IList. The problem I'm encountering is that since BooleanCondition hides ChildConditions, the JSON serializer can't iterate over children so conditions get left out making the apply fail. I'm planning on working around the issue by modifying sources to expose ChildConditions via a property but really dislike having to modify external libraries as it makes updating those libraries later harder.

If you have a update feed that does not specify a BaseUrl attribute on the feed element, then the UpdateManager.BaseUrl property is left null. When the SimpleWebSource.GetData() method is invoked, it does:

if (!baseUrl.EndsWith("/")) baseUrl += "/";

Which results in a NullReferenceException.

At a minimum there should be a String.IsNullOrEmpty() check on baseUrl, but it might be a good idea to make the UpdateManager.BaseUrl property public so it an be set by the client code.

I used the project in my application for automatic update. But during update, after downloading the updates to appdata folder, norton is detecting the files as threat and deletes all the update files from the system. You can view the screen shot of norton message http://i50.tinypic.com/2emmmc3.jpg Can you please help me to overcome this problem?

hey,

Whilst i haven't (and won't for a while) had time to do any development on this i'm still using it. I found that application settings are lost when updating (this is the first program where i've really used them rather than my own).
There is a way to check this: http://cs.rthand.com/blogs/blog_with_righthand/archive/2005/12/09/246.aspx which we should implement within the library rather than expect the user to.

The library successfully checks for files that need to be updated, downloads them into the temporary directory, and restarts. However, it does not take the newly updated files collected in the temporary directory and places them into the working directory of the application itself. Instead, it keeps the older files the same.

What is interesting is that the files to be updated in the working directory do get modified as the date modified time stamp changes on them, but the newer version that is residing in the temporary directory is simply not replacing the older version files in the working directory of the application.

Sometimes this function fails although there is a pipe created.
It seems that the CreateNamedPipe function can report that the connection is complete when it's not ready yet.

Changing the code by checking on the 535 (ERROR_PIPE_CONNECTED) seems to overcome this issue.

//failed to connect client pipe
if ((success != 1) && (Marshal.GetLastWin32Error() != 535))
{
    break;
}

Seems like updater's web client is caching the "Feed.xml" data somehow.

I had the following xml file:

<?xml version="1.0" encoding="utf-8" ?>
<Feed>
  <Tasks>
    <FileUpdateTask localPath="Test.dll" updateTo="http://tt.test.exotest.net/updates/Test.dll">
        <Conditions>
            <FileVersionCondition what="is" version="1.0.0.0" />
        </Conditions>
    </FileUpdateTask>
    <FileUpdateTask localPath="Test.exe" updateTo="http://tt.test.exotest.net/updates/Test.exe">
        <Conditions>
            <FileVersionCondition what="below" version="0.1.7" />
        </Conditions>
    </FileUpdateTask>
  </Tasks>
</Feed>

But updater said there are no updates. Then I tried to click "Check" for a couple of times (10-20) and once it shown that updates are avaliable.
I checked and added random dummy QueryString parameter to Feed.xml path and it solved the problem.

I'm not sure, maybe no-caching policy has to be applied to the inner web client?

I am trying to run a simple update based on the steps provided in the post http://code972.com/blog/2012/06/55-the-philosophy-behind-nappupdate
When I try to run the updates, I get the message "Failed to prepare task:
System.Net.WebException: Could not find file '\AutoUpgrade.exe'. ---> System.Net.WebException: Could not find file '\AutoUpgrade.exe'. ---> System.IO.FileNotFoundException: Could not find file '\AutoUpgrade.exe'.
Obviously, I'm missing the AutoUpgrade.exe file, but where do I find that and include it in the updates folder?

I think the first thing a lot of people would do to try out this project is run the WPF sample app. When doing so it's likely they'll notice that the Current Version displayed on the main window usually doesn't change from 1.0 to 1.1 as expected after doing an "Install Now". In the following code from UpdateWindow.xaml.cs you can see it's possible for updateManager.CleanUp to finish before the BeginInvoke that closes the update window finishes. If that happens, the CleanUp method sets the updatemanager's state back to unchecked before the closed event handler inside the main window does its check to see that the state is AppliedSuccessfully. The Closed handler in the MainWindow code only calls OnPropertyChanged("AppVersion") if the state is AppliedSuccessfully. Maybe the easiest thing is to make sure the Update window closes before CleanUp is called.

private void InstallNow_Click(object sender, RoutedEventArgs e)
{
...
    Dispatcher d = Application.Current.Dispatcher;
    d.BeginInvoke(new Action(Hide));
    try
    {
        _updateManager.ApplyUpdates(true);
        d.BeginInvoke(new Action(Close));
    }
    catch
    {
        d.BeginInvoke(new Action(this.Show));
            // this.WindowState = WindowState.Normal;
        MessageBox.Show(
            "An error occurred while trying to install software updates");
    }

    _updateManager.CleanUp();
    d.BeginInvoke(new Action(this.Close));

    Action close = Close;

    if (Dispatcher.CheckAccess())
        close();
    else
        Dispatcher.Invoke(close);
...
}

Hi,

i found your "product" great stuff! Is it possible to connect via an self signed cert to https server?

Thanks a lot !

András Székely
Hungary

Hi

I was following an example from NAppUpdate blog (which I now know is not only outdated but erroneous, see: http://pastebin.com/198EtE6B).

In it CheckForUpdates is passed IUpdateSource but unless set globally ahead of the time, it will cause the PrepareUpdates to fail.

So this does not work:

// prep
var updateManager = UpdateManager.Instance;
// more checks
updateManager.CheckForUpdates(updateSource); // passed in via method arg
// other stuff...
 updateManager.PrepareUpdates(); // <-- NPE

But this does

// prep
var updateManager = UpdateManager.Instance;
updateManager.UpdateSource = updateSource; // must set it here !!!
// more checks
updateManager.CheckForUpdates(updateSource);
// other stuff...
 updateManager.PrepareUpdates();  // <-- now it works....

Suggested fix:
in UpdateManager.cs inside of public void CheckForUpdates(IUpdateSource source) method after checking the args re-set UpdateSource to (maybe line 247)

UpdateSource = source;

so that subseqent call to Prepare does not fail...

Perhaps even better, do not allow methods to accept update source at all, and have checks in all methods to insure it is set before invoking them (unless there is a need to have varying update sources during update process ?)....

Hi,

we're using your framework and stumbled upon the problem where File.Exists(localPath); from *Condition classes returns false because our app was not started manually (by clicking on an exe) but through registry upon machine startup.

After some debugging we found out that the problem was System.IO.File would look at a different default folder based on the two different ways of starting the app. If the app is started manually it properly looks into its root and updates the changed files. If however the app is started automatically on startup, the default directory that System.IO.File uses is for some reason C:\Windows\SysWOW64.

This caused us some problems so we temporarily fixed NAppUpdate by adding these few lines:

var appDirectory = Path.GetDirectoryName(UpdateManager.Instance.ApplicationPath);
if (!localPath.StartsWith(appDirectory, StringComparison.InvariantCultureIgnoreCase))
{
    localPath = Path.Combine(appDirectory, localPath);
}

after:

if (string.IsNullOrEmpty(localPath))
    return true;

in the following classes:

• FileChecksumCondition
• FileDateCondition
• FileExistsCondition
• FileSizeCondition
• FileVersionCondition

A better approach would be do the append the path to a more generic place such as SetNauAttributes(INauFieldsHolder fieldsHolder, Dictionary<string, string> attributes) method from Reflection.cs but we didn't want to do this as we didn't want to break some other functionality (we saw that in some places you actually did something similar to what we did (for example in FileUpdateTask class).

The mix of absolute/relative behavior should probably be refactored and standardized so it wouldn't cause the kind of problems we experienced.

Anyway, hope this helps if someone else stumbles into same problem or until this (hopefuly ;) gets fixed/refactored in a future version of the framework.

Also, thanks for creating the framework! :)
It helped us a lot.

Cheers