Category Archives: XAF

Hosting XAF ASP.NET Projects using Azure Web Sites

Azure Web Sites is a new offering from Microsoft under their Windows Azure cloud platform. It’s a scalable solution that allows you to host ASP.NET, PHP, and node.js projects. If your needs are basic, your sites – up to 10 of them – can be hosted for free*. If you need something like a custom domain, you’ll pay a bit more – currently about $8/mo. If you’d like a reserved instance, rather than shared, that will kick it up to around $70/mo. But you can run several of your web sites on that one reserved instance.
*bandwidth and database sold separately see site for details

The awesome thing is that you can start with the free setup, get up to 10 web sites going and, if your needs grow, scale your web sites up by simple dragging sliders in a web portal. It’s all very simple and straightforward and seems to work well.


One of the first things I tried with the free Azure Web Sites preview was hosting an eXpressApp Framework ASP.NET solution and database. While there are a few gotchas that came with publishing my XAF project to Azure Web Sites, most were the sort of issues you’d work through publishing an XAF ASP.NET project to any new server. However, there are some Azure-specific steps needed to work through some of these, which I’ll cover towards the end.

To get started, head to the Windows Azure homepage and sign up for Azure Web Sites. Afterwards, visit the Azure management portal. Note that after signing up for Azure Web Sites you’ll be treated to a nice new HTML5 UI for the Azure management portal (unfortunately the database management portal is still Silverlight).

Once you are in the management portal, click WEB SITES on the left, then click the NEW button at the bottom-left of the portal. Select the CREATE WITH DATABASE option (no I’m not yelling, the site is covered in caps).


You’ll need to give both your web site and database a name, and assign a login name and password for your database.


After the process completes, you’ll be left at the DASHBOARD screen for your new web site. On the right, under quick glance, click Download publish profile. This is the file you’ll use in Visual Studio to publish your XAF ASP.NET project. Next, click View connection strings and note the ADO.NET connection string for your Azure database instance.


As a final step in the Azure portal, scroll down the DASHBOARD page and click the link to your database under linked resources. Click the MANAGE button at the bottom of the portal. This should prompt you to add your current IP address to the firewall rules so that you can access the SQL database. Click YES.


This is necessary if you want to debug your application locally with the database hosted on Azure. Afterwards you can click NO to manage the database (we just needed the firewall rule added).

Next, if you haven’t already, you’ll want to download and install the Windows Azure SDK.

Now we can jump into Visual Studio and start the process of setting up the XAF ASP.NET project for hosting in Azure. First, double-click the WebApplication.cs file in the Web project. Select the Sql Connection and then edit its ConnectionString property, using the ADO.NET connection string from above. Make sure you use your real password as that will not be shown in the portal.


With the new connection string in place, and with the firewall rule added from the steps above, you should now be able to click Start to debug your XAF ASP.NET project, and successfully run against the new Azure database. This step will also create the destination database schema within the database hosted on Azure.

With these changes in place, right-click the Web project and click Publish. Click the Import button on the first screen and import the publishing profile you saved from the Azure portal.


Click Next through the wizard. On the final page you can click Start Preview to preview what will be published. Finally, click Publish.

Aaaand YSOD! Here’s where a bit of troubleshooting comes in. Some of this will be similar to publishing an ASP.NET XAF project to any host. Start by disabling Custom Errors in your web.config and Publish again.

Now you should see that the problem is that the DevExpress ExpressApp assemblies are not on the server.


Multi-select the DevExpress assemblies referenced by your Web project using CTRL or SHIFT. In the Properties Window, set Copy Local to True.


Go ahead and Publish again. Now, all of the DevExpress assemblies referenced by your project will be uploaded to Azure.

Aaaand YSOD! Even after setting all of the assemblies explicitly referenced by the ASP.NET project to Copy Local, there are missing ExpressApp assemblies.


Some assemblies – for instance DevExpress.ExpressApp.Security and DevExpress.ExpressApp.Objects – are not explicitly referenced by any of the XAF projects (mentioned to DevExpress here). While this may be addressed by DevExpress in a future update, in the meantime you’ll need to explicitly add any references with the Add Reference dialog, set Copy Local to true, Publish, and repeat on YSOD.

At this point, the ASP.NET XAF app should run properly hosted in Azure Web Sites.


But, there’s one last “gotcha” I want to cover, as trouble-shooting this is specific to Azure Web Sites. If you encounter the generic XAF ASP.NET error, you’ll need access to the XAF log to troubleshoot.


This may happen, for instance, if you make use of the HTML property editor in your ASP.NET solution and have not published all of the required assemblies.

To access the XAF log, go back to the Azure management portal. Click on the link under FTP HOSTNAME, which is in the quick glance column of the DASHBOARD.


You’ll be prompted for a username and password. You can get these by editing the PublishSettings file (downloaded above) in Notepad. Look for the userName and userPWD values after the FTP publishMode.

Once you’ve logged in, you’ll have full FTP access to both your sites and any logs. Navigate to site, then wwwroot. You should see an eXpressAppFramework.log file.


View the file’s contents, and search for “error occurred”. This will help you find XAF errors that occur that don’t cause a YSOD. This can and will happen for missing assembly references, such as DevExpress.SpellChecker.Core, if you use the HTML property editors.

With connection strings in place and all of the proper assemblies referenced and published, XAF ASP.NET projects run quite well in Azure Web Sites.


I’ve been using Azure Web Sites for a couple of months to host both my personal website and the website for Hip Shot and have been very pleased overall. And, if you don’t need a custom domain or a reserved instance, your web site hosting is free – bandwidth and database storage aside.

Using the XAF Scheduler Module with Domain Components

It had been a while since I last looked at XAF from DevExpress, and since then the new Domain Components technology has been released in version 11.2. I decided to take a look at this new technology recently and see how exactly to make use of it.

The technology itself looks very promising, but makes using some of XAF’s modules require a little extra effort in some cases. This post will go over how to use the combination of Domain Components with the SchedulerWindowsFormsModule, which takes several steps beyond those required when using normal Domain Objects.

Start off by creating a new XAF Cross-Platform Application solution.


As with any XAF based project, build the solution first so that type information is available to the XAF model editor.

Expand the WinForms (Win) application project in the Solution Explorer and double-click WinApplication.cs. Side-note: on this designer you can select the Sql Connection and edit the connection string if necessary.

Locate the SchedulerWindowsFormsModule in the XAF Modules category of the Toolbox and drag to the Modules window in WinApplication.cs


Next, in the Solution Explorer, expand the common module project and double-click Module.cs. Under Exported Types, expand Referenced assemblies and then DevExpress.Persistent.Base.vXX.Y. Right-click IPersistentRecurrentEvent (the DC we’ll be using) and click Use Type In Application


Build the solution. This is necessary so that the newly included types are available in the model editors.

So far, this is very similar to using the Domain Objects. The exception being that we’ve included the Domain Component interfaces rather than the Domain Object classes (Event, Resource).

Now, right-click the Module.cs designer and click View Code. Add the following code:

        public override void Setup(XafApplication application)
        {
            base.Setup(application);

            //register scheduling Domain Components
            XafTypesInfo.Instance.RegisterEntity("Event", typeof(DomainComponents.Common.IPersistentRecurrentEvent));
            XafTypesInfo.Instance.RegisterEntity("Resource", typeof(DomainComponents.Common.IPersistentResource));
        }

This code is necessary with Domain Components to register the interfaces with XAF.

Next we’ll need to make some modifications to the model so that the scheduler user interface elements are displayed. These steps are taken care of automatically when using the Event Domain Object. Right-click the common module project in the Solution Explorer and click Open Model Editor.


Expand NavigationItems. Then, right-click Items, go to Add, and then NavigationItem.


Select the new navigation item and, on the right, under View, select IPersistentRecurrentEvent_ListView. If you do not see IPeristentRecurrentEvent_ListView, close the model editor, rebuild, and try again.


Back in the model editor tree, expand Views, followed by DomainComponents.Common, IPersistentRecurrentEvent_DetailView, Layout, Main, and finally SimpleEditors. Select IPersistentEvent and, on the right, change Caption to Event.


Again in the model editor tree, above Layout, expand Items. Find and delete the AppointmentId and Pattern items (normally hidden by the built in Event Domain Object).


And now run the WinForms project.


You can download the sample project here.

User Owned Objects in XAF

Working on a little XAF project, I recently had the need (a common one) to support the concept of objects being owned by certain users. When a user logs in, he or she should only see the objects owned by that user. This needed to apply to both the list views and the data available in reports.

In the end, this was fairly easy to do. I thought I’d share some notes about how I accomplished this, as some of the resources online are a bit outdated, or don’t lay all of these aspects out together.

Note that there is currently a request to support this sort of scenario directly in XAF’s security system. You can track the issue here.

The first thing to do is define the business object itself (we’ll called it OwnedObject). The only thing particularly interesting here is defining a property to reference the object’s owner, and initializing that value:

public class OwnedObject : BaseObject
{
    public OwnedObject(Session session) : base(session) { }

    public override void AfterConstruction()
    {
        base.AfterConstruction();
        if (Session.IsNewObject(this))
        {
            _ObjectOwner = Session.GetObjectByKey<SimpleUser>((Guid)SecuritySystem.CurrentUserId);
        }
    }

    private SimpleUser _ObjectOwner;
    public SimpleUser ObjectOwner
    {
        get
        {
            return _ObjectOwner;
        }
        set
        {
            SetPropertyValue("ObjectOwner", ref _ObjectOwner, value);
        }
    }
}

One way to filter list views by this ObjectOwner property is discussed here. Open up the XAFML file for the platform agnostic Module project. Navigate to the OwnedObject_ListView node under Views. Set the Criteria to ObjectOwner.Oid = '@CurrentUserID'. Here, ObjectOwner is the property defined on the OwnedObject class, and @CurrentUserID is expanded at runtime to contain the current user’s ID.

Set the same Criteria property on the OwnedObject_LookupListView node as well, and run your application. Both the WinForms and ASP.NET applications should now only show the objects created by the current user, which is automatically set when the object is created. Note that you can also accomplish the same thing with a View Controller.

You can hide the ObjectOwner property at runtime by deleting its respective items under the DetailView, ListView, and LookupListView nodes in the model editor. Also note that this can easily be applied to reports as well, so that a user only sees his or her reports. Simply descend a new object from ReportData, and use your OwnedReport as the data type for the report views.

This is all pretty cool with minimal code, but one issue that needs to be addressed is the data shown in reports. If a user were to create and run a report on OwnedObjects, they’d see all objects regardless of owner. This is also fairly easy to fix, but requires two solutions, one for the WinForms project and one for the ASP.NET project.

The solution for the WinForms project is discussed here. To the WinForms module, add a new View Controller. You’ll also need to add references to ExpressApp.Reports, ExpressApp.Reports.Win, XtraReports, and XtraReports.Design. Add the following code to your controller:

protected override void OnActivated()
{
    base.OnActivated();
    XtraReport.FilterControlProperties += XtraReport_FilterControlProperties;
    Frame.GetController<WinReportServiceController>().CustomShowPreview += ViewController1_CustomShowPreview;
    Frame.GetController<WinReportServiceController>().CustomShowDesignForm += ViewController1_CustomShowDesignForm;
}

void XtraReport_FilterControlProperties(object sender, FilterControlPropertiesEventArgs e)
{
    if (e.Control is XtraReport)
    {
        e.Properties.Remove("FilterString");
    }
}

void ViewController1_CustomShowDesignForm(object sender, CustomShowDesignFormEventArgs e)
{
    e.Report.FilterString = CriteriaOperator.Parse("ObjectOwner.Oid=?", SecuritySystem.CurrentUserId).ToString();
}

void ViewController1_CustomShowPreview(object sender, CustomShowPreviewEventArgs e)
{
    e.Report.FilterString = CriteriaOperator.Parse("ObjectOwner.Oid=?", SecuritySystem.CurrentUserId).ToString();
}

protected override void OnDeactivating()
{
    base.OnDeactivating();
    Frame.GetController<WinReportServiceController>().CustomShowPreview -= ViewController1_CustomShowPreview;
    Frame.GetController<WinReportServiceController>().CustomShowDesignForm -= ViewController1_CustomShowDesignForm;
}

Basically, when the controller is activated, it will add two event handlers to the report service controller for WinForms applications – one for when a preview is shown, and one for when the report is designed. These events force a criteria that only shows objects owned by the current user. The FilterControlProperties event hides the FilterString property.

I had to figure out the ASP.NET portion on my own, but it wasn’t hard. Based on the WinForms solution above, I knew to look at the WebReportServiceController. Turns out you can simply descend from that class and override ShowPreviewCore to filter the data.

For the ASP.NET module, add a new class. Descend the class from WebReportServiceController and add the following code:

protected override void ShowPreviewCore(IReportData reportData, CriteriaOperator criteria)
{
    criteria = new BinaryOperator("ObjectOwner.Oid", SecuritySystem.CurrentUserId);

    base.ShowPreviewCore(reportData, criteria);
}

You’ll also need to add references to ExpressApp.Reports, ExpressApp.Reports.Web, XtraReports, and XtraReports.Web. This does essentially the same thing as the WinForms solution, overriding the preview of the report to force a filter on the object’s owner.

With those two changes made, you can now run both the WinForms and ASP.NET XAF applications, create and run reports, and you will only be able to see your own objects.

You can download a sample that demonstrates all this here.

Using XAF with Embedded Firebird

I spent a few hours tonight trying to work out how to get my XAF application using embedded Firebird as a backend. I was unable to find documentation that covered something like this start-to-finish, so I thought I’d jot down my experience in case it helps some other folk using XAF or XPO. In my case, this was on a 64-bit OS, which had me jumping through a few extra hoops.

Let’s get started.

The first step is to download three separate files:

  • 32-bit Embedded Firebird
  • 64-bit Embedded Firebird
  • The Firebird .NET Provider

You can download the files here. At the time of writing I downloaded the 2.5.2 .NET Provider and version 2.1.3 of embedded Firebird.

The second step is to add the following project to your solution:

C:\Program Files (x86)\DevExpress 2009.3\Components\Sources\DevExpress.Xpo\DevExpress.Xpo.Providers\DevExpress.Xpo.Providers.csproj

Now, remove the assembly references and .cs files that are specific to non-Firebird DB’s from the above csproj. Also comment out any lines in the Reg.cs to do with any other drivers aside from Firebird. Next, add a reference to this newly added project to your XAF WinForms project.

The third step is to add a reference to the .NET Firebird provider (FirebirdSql.Data.FirebirdClient.dll, downloaded above) to the WinForms project for your XAF solution.

The fourth step is to change the connection string in your App.config to something like this:

<add name="ConnectionString" connectionString="XpoProvider=Firebird;DataSource=localhost;User=SYSDBA;Password=masterkey;Database=MyDB.fdb;ServerType=1;Charset=NONE"/>

The final step is where this can get tricky – making sure you have the right embedded Firebird DLL’s in the right places for the right project configurations. If you are on 64-bit Windows, as I am, and run the Any CPU configuration, you’ll get files that run as a 64-bit process in bin\Debug. So in here, you’ll want to copy the following files from the 64-bit embedded Firebird zip file:

  • fbembed.dll
  • icudt30.dll
  • icuin30.dll
  • icuuc30.dll

If you change your configuration to 32-bit, you’ll get files that run as a 32-bit process in bin\x86\Debug, and in here you want to copy the same files above, but from the 32-bit embedded Firebird zip file.

Some gotchas I found include ensuring you have all four of the above DLL’s in your application’s folder. Quite a few references I found only indicated copying in the fbembed.dll file. If you don’t have all of these DLL’s, you’ll get an error message indicating fbembed.dll could not be found.

Another gotcha is ensuring you have the right versions of these files in the right folders when you change configurations. It may seem obvious, but when changing between CPU targets or from Release to Debug and vice versa, new output folders are created, which can again lead to an error message indicating that fbembed.dll could not be found.

Wrapping up, if you get an error indicating fbembed.dll could not be found:

  • Ensure you have copied all four of the files listed above – those files exactly
  • Ensure you have copied them into the correct folder from which your application is running

If you get an error indicating the incorrect image format:

  • Double check your process in task manager – is it 32-bit or 64-bit? – and ensure that you copied the embedded Firebird DLL’s from the proper zip file.

Here are some references I found useful. However, none of them really told the whole story, and some seem outdated.

XAF – 10 – Advanced data layer features

Customizing Dataprovider

Connecting to embedded Firebird

How to connect XPO to a database other than SQL Server or Access

Embedded Firebird: Full-Featured Embedded Database with 2 MB Runtime