Category Archives: Microsoft .NET

Creating and Running WinForms Desktop Apps on Windows RT

I’ve been following the developments on the home-brew front for Windows RT for the past few months. As you’ve probably heard, a “jailbreak” for Windows RT was documented several days ago. This “jailbreak” allows the user to run desktop applications that are not signed by Microsoft. You can ready more about how the exploit works here.

The original exploit was pretty difficult to do and involved using a combination of a Windows Store app to open a command prompt that is then able to run some unsigned applications, and then using that command prompt to exploit a bug in Windows RT that stores a new value in memory used when checking if an app is signed. The actual exploit also required the user to use remote debugging from VS2012 in order to get the exploit payload into memory on the Windows RT device and then setting several breakpoints, redirecting the RT device to that payload in memory. Yikes. This mostly just led me to BSOD my device repeatedly.

However, a couple of days ago a much simpler jailbreak tool was released that just involves a double-click and following a few prompts. You can read about the tool and download it here.

Once you have Windows RT able to run unsigned desktop apps you can download a whole set of FOSS apps that have been recompiled for ARM such as Notepad++, PuTTY, bochs, and 7-Zip. The list is growing daily, and there’s even an app you can install on Windows RT that makes for a non-official “RT Desktop Store”.

RT Desktop Store

One of the very cool and often overlooked aspect of all this, though, is that any pure .NET 4.5 application will also run on Windows RT once jailbroken. I tested this myself and it worked without any extra steps. I created a new C# .NET 4.5 application and was able to run it, unmodified, on my Surface RT.

WinForms on Windows RT

Microsoft has stated that they do not see the current jailbreak as a security vulnerability, though they could also (obviously) not promise that the exploit will remain unpatched. If you want to ensure your device remains “vulnerable” there are steps to disable automatic updated for Windows RT here.

Using RemObjects Train for Automated Testing and Building

I was recently tasked with coming up with an automated build process for one of my projects. Given the available free and commercial tools on the market I decided to give RemObjects Train a try. Train is an Open Source project from RemObjects Software (one of their many Open Source offerings). Benefits of Train include:

  • It is Open Source
  • It has a simple, extensive, extensible API
  • Scripts are friendly to version control (based on ECMAScript rather than, say, XML)
  • The tool is simple, light-weight
  • It’s free – as in beer

My requirements for the build process were limited (one of the reasons I wanted a free, simple tool rather than a capable commercial tool such as FinalBuilder or Automated Build Studio):

  1. Support for running and failing based on unit tests (using MSTest)
  2. Support for building a release configuration of several .NET assemblies
  3. Support for packaging assemblies using Inno Setup
  4. Configurable version number used for assemblies and installer

Train ended up being a very elegant and useable solution. The scripts are easy to create and maintain – I used Sublime Text 2 with its JavaScript syntax highlighting.

In the end I created two scripts: RunTests.train and BuildRelease.train. By naming my scripts with a .train extension I was able to associate them with Train.exe and can run my unit tests and build releases with a simple double-click.

My RunTests script looks like this:

//rebuild unit tests
msbuild.rebuild("../ExchangePurge.UnitTests/ExchangePurge.UnitTests.csproj", { configuration: "Release" });
msbuild.rebuild("../ExchangeSync.UnitTests/ExchangeSync.UnitTests.csproj", { configuration: "Release" });

//function for running MSTest unit tests, detecting failures
function runTest(testAssemblyPath) {
	var mstestPath = "C:/Program Files/Microsoft Visual Studio 11.0/Common7/IDE/MSTest.exe";
	shell.exec(mstestPath, "/testcontainer:" + testAssemblyPath);

//run unit tests

The script is pretty straight-forward. It builds release versions of my unit test assemblies using the msbuild API provided by Train (API documentation can be found here). It then defines a simple function – runTest – for running unit tests with MSTest.exe using the shell API. Finally, the function is called for each unit test assembly.

My BuildRelease script looks like this:

//run unit tests

//get version info from VersionInfo.ini
var versionInfoIni = ini.fromFile("VersionInfo.ini");
var appVersion = versionInfoIni.getValue("VersionInfo", "AppVersion", "1.0");

//update the assembly versions for each .NET project using the above version info
msbuild.updateAssemblyVersion("../ExchangePurge/Properties/AssemblyInfo.cs", appVersion);
msbuild.updateAssemblyVersion("../ExchangeSync/Properties/AssemblyInfo.cs", appVersion);
msbuild.updateAssemblyVersion("../ExchangeSyncAdmin/Properties/AssemblyInfo.cs", appVersion);

//rebuild each .NET project
msbuild.rebuild("../ExchangePurge/ExchangePurge.csproj", { configuration: "Release" });
msbuild.rebuild("../ExchangeSync/ExchangeSync.csproj", { configuration: "Release" });
msbuild.rebuild("../ExchangeSyncAdmin/ExchangeSyncAdmin.csproj", { configuration: "Release" });

//export environment variable for InnoSetup to use for app version
export("ES_AppVersion", appVersion);

//build an InnoSetup installer"Installer.iss", { });

//copy setup.exe to folder for this version
folder.create("Output/" + appVersion);
file.copy("Output/setup.exe", "Output/" + appVersion);

This script is a bit more complex but still pretty easy to understand. It starts by using the Train API to run the RunTests script. Because of the nature of MSTest.exe and Train.exe, if the RunTests.train script fails then the BuildRelease.train script will be aborted.

The script then uses Train’s ini API to read a configurable version from VersionInfo.ini. Next, the msbuild API is used to both update the assembly version information and build release versions of each assembly.

Next, I used the Train API to export an environment variable – ES_AppVersion – with the version information read earlier from the INI file. My Inno Setup script uses ISPP, which is installed by default if you download an Inno Setup QuickStart Pack. At the top of my Installer.iss Inno Setup script I used the following code (thanks to Carlo from RemObjects):

#define MyAppVersion GetEnv("ES_AppVersion")
#if MyAppVersion == ""
#define MyAppVersion "1.0"

And then further down use the MyAppVersion ISPP macro:


This bit of ISPP macro code will make use of the ES_AppVersion environment variable set by the BuildRelease.train script to define the installer’s version.

Finally, the last lines of the BuildRelease.train script use the folder and file Train API’s to copy the created installer to a folder named after the version read from the INI file.

So far I’m very happy with Train as a simple, capable tool for automated testing and building. If you’d like to read more about Train you can refer to Marc Hoffman’s post on the project as well as the official documentation.

Open Source Solution for Migrating from ExpressScheduler to XtraScheduler


Express2XtraScheduler is a .NET solution consisting primarily of two assemblies and a WinForms utility that simplify importing database data from the format stored by the DevExpress VCL ExpressScheduler into a format supported by the WinForms XtraScheduler control.


  • Express2XtraScheduler.Core.dll provides the functionality needed to import data from one format to another given a pair of database settings
  • Express2XtraScheduler.UI.dll provides UI controls for mapping source and destination database settings
  • Express2XtraScheduler.exe uses these assemblies to provide a simple utility for transferring data
  • ExpressSchedulerInterop.dll is a Delphi DLL used to read resource information stored as Delphi variants

Express2XtraScheduler App

The solution also contains two simple applications that allow testing both VCL and WinForms scheduler data: ExpressSchedulerApp and XtraSchedulerApp.


Below are links to blog posts that discuss some of the techniques used by this solution:


The source code for the Express2XtraScheduler solution is available immediately on this public Git repo hosted at Bitbucket.

Displaying the XtraScheduler Context Menu Programmatically

The XtraScheduler product from DevExpress is suite of flexible and powerful calendar controls. The scheduler control itself has a built in popup menu that displays context sensitive items when the end-user right-clicks the control.

However, it’s not immediately obvious how to display this menu, with the appropriate context options, programmatically. For instance, you may have an XtraGrid control setup synchronized with the XtraScheduler control. It would be pretty sweet if right-clicking an appointment in the XtraGrid control displayed the appropriate XtraScheduler context menu.

With some digging through the XtraScheduler classes, comments, and some trial and error, I was able to come up with the following working code:

        private void gridControl1_MouseUp(object sender, MouseEventArgs e)
            if (e.Button == System.Windows.Forms.MouseButtons.Right)
                SchedulerHitInfo hitInfo = new SchedulerHitInfo(SelectableIntervalViewInfo.Empty, SchedulerHitTest.AppointmentContent);
                WinFormsSchedulerMenuBuilderUIFactory uiFactory = new WinFormsSchedulerMenuBuilderUIFactory();
                SchedulerDefaultPopupMenuWinBuilder builder = new SchedulerDefaultPopupMenuWinBuilder(uiFactory, schedulerControl, hitInfo);
                IDXPopupMenu<SchedulerMenuItemId> popupMenu = builder.CreatePopupMenu();
                ((IDXDropDownControl)popupMenu).Show(schedulerControl.MenuManager, (Control)sender, new System.Drawing.Point(e.X, e.Y));

The first line creates a new instance SchedulerHitInfo with SchedulerHitTest.AppointmentContent specified as the element under the hit info. This controls which menu contents will be displayed. In this case, the menu contents shown when right-clicking an appointment are displayed.

The next three lines create the popup menu itself by using a WinFormsSchedulerMenuBuilderUIFactory and WinFormsSchedulerMenuBuilderUIFactory.

Finally, the last line displays the popup menu itself. The first parameter is an IDXMenuManager, which can be accessed via the MenuManager property of the scheduler control. The second parameter is the parent control for the popup menu. The final parameter is the position for the popup menu within the parent control.

Together, these lines allow you to display the XtraScheduler menu, with the appropriate context sensitive contents and at any position, from code. Hopefully this bit of code comes in handy as these classes aren’t currently (well) documented. Enjoy!

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.

Emitting XtraScheduler Reminder XML

In a previous post I discussed how to generate the XML that the DevExpress XtraScheduler uses when persisting its appointment resource ID’s to a database. You can read that blog post here, and review the structure of the XtraScheduler data tables here.

In this post I’ll cover how to create the XML needed to persist XtraScheduler reminder information to a database. It’s pretty straight forward but not covered (yet) in the DevExpress documentation for the XtraScheduler control.

Again you’ll need a reference to the DevExpress.XtraScheduler.XML namespace. The classes you’ll be using are ReminderInfo and ReminderInfoContextElement. Here is an example of how to use ReminderInfo along with ReminderInfoContextElement:

        private string GetReminderInfoXML(DateTime? reminderDate, int? reminderMinutes)
            ReminderInfo reminderInfo = new ReminderInfo();

            if (reminderDate != null)
                reminderInfo.AlertTime = reminderDate.Value;
            else if (reminderMinutes != null)
                reminderInfo.TimeBeforeStart = new TimeSpan(0, reminderMinutes.Value, 0);

            ReminderInfoContextElement element = new ReminderInfoContextElement(reminderInfo, DateSavingType.LocalTime);
            return element.ValueToString();

I’ve also put together a small working example that you can download here.

UPDATE: There’s a real-world example of this technique you can find here. It is an open source project for transferring data from ExpressScheduler to XtraScheduler.

Using AutoMapper with Strongly-Typed DataRows

Over the years I’ve done a lot of work involving moving data in and out of databases. In most cases, this involves taking data from some form of data access object (DAO) and then copying it to a simple data transfer object (DTO) and vice-versa. I do this when working on web services or data synchronization utilities, and the practice can be tedious and repetitive. And, as with anything tedious and repetitive, it can introduce hard-to-spot bugs.

I was recently delighted to discover a very nice open source project called AutoMapper which handles these sorts of scenarios for you in a very simple manner. With only a couple of lines of code using static methods AutoMapper will copy the properties of a source object to a destination object (of different types) using very straight forward name mapping. AutoMapper also allows you to customize how each member of the source object is mapped (called projection), so you can do any necessary transformation in a very terse and easy-to-read manner.

That said, the first scenario where I wanted to make use of AutoMapper had me initially scratching my head: I had two strongly-typed datarows from different, but similar, databases and I wanted to copy the property values of one datarow to the other. I also wanted to make use of the .ForMember() and .MapFrom() methods to transform a few properties. While the mapping succeeded without error, the properties of my source row were copied to my destination row exactly, disregarding any custom mapping I provided.

Here is an example:

            DestinationData.PersonDataTable destinationDataTable = new DestinationData.PersonDataTable();
            DestinationData.PersonRow destinationRow = destinationDataTable.NewPersonRow();

            AutoMapper.Mapper.CreateMap<SourceData.PersonRow, DestinationData.PersonRow>()
                //with this ForMember, every FirstName should be "First!"
                .ForMember(src => src.FirstName, opt => opt.MapFrom(src => "First!"));

            AutoMapper.Mapper.Map<SourceData.PersonRow, DestinationData.PersonRow>(sourceRow, destinationRow);

            Debug.Assert(destinationRow.FirstName.Equals("First!"), "datarow mapping failed");

After running into the issue, I created a sample illustrating the issue, hosted it on Github, reported the issue, and took a break from the issue.

Taking a break from an issue is almost always a great help for me. Once I started looking into the issue again, it was only a few minutes and logical steps before I realized what was going on. Being new to AutoMapper, I had made an assumption that was totally invalid: I assumed AutoMapper was only mapping my type’s properties, not ancestor properties. Once I started thinking along these lines the solution came quickly.

The ancestor DataRow class has an ItemArray public property. It’s an array of objects that provides direct access to the row’s values. AutoMapper was doing its job and doing it well. After copying over the individual, strongly-typed properties found in my DataRow implementations it was also copying the ItemArray property, which is why I always ended up with an exact copy of the source row without any custom mapping via .ForMember() and .MapFrom()!

The working code looks like this:

            DestinationData.PersonDataTable destinationDataTable = new DestinationData.PersonDataTable();
            DestinationData.PersonRow destinationRow = destinationDataTable.NewPersonRow();

            AutoMapper.Mapper.CreateMap<SourceData.PersonRow, DestinationData.PersonRow>()
                //with this ForMember, every FirstName should be "First!"
                .ForMember(src => src.FirstName, opt => opt.MapFrom(src => "First!"))

                //!!don't map property ItemArray from DataRow!!
                .ForMember(src => src.ItemArray, opt => opt.Ignore());

            AutoMapper.Mapper.Map<SourceData.PersonRow, DestinationData.PersonRow>(sourceRow, destinationRow);

            //!!this assertion will fail unless you use opt.Ignore() for ItemArray!!
            Debug.Assert(destinationRow.FirstName.Equals("First!"), "datarow mapping failed");

With the extra .ForMember() in place the issue with mapping goes away. I’m excited to be back on track with AutoMapper as it seems like a great tool for mapping objects to objects.

You can view the example project on Github here.