Thursday, July 17, 2014

In this post I will go through the process of debugging eXpandFramework for each of the distribution channel.The sources
If you download the sources either from GitHub or our download page or our build server you need to run the buildall64.cmd file located in the root folder. The batch will generate the symbol files (pdb) and will register the assemblies in the GAC. Debugging is enabled by default since symbols and sources are in place.The Nuget packages
eXpandFramework is distributed through Nuget and since version 14.1.4.8 and with the excellent GitHubLink project provides frictionless debug experience as long as Symbol Server support is enabled under your VS/Options/Debugging settings. The symbols are in the same package as the dll so expect the package size to be at least double in size. We will consider a better implementation if there are requests. GitHubLink patches the symbols so to request the assembly sources from the online GitHub repo so there is not need to have the sources in place.The Binaries / The Installer
Either way you choose you will end up with a folder containing the eXpandFramework assemblies + the patched symbols. So, debugging is enabled by default and sources will be queried from the online GitHub repo as long as Symbol Server support is enabled under your VS/Options/Debugging settings
PS: In the installer case you can also find the sources under the Sources folder in your installation directory.

Troubleshooting
With debugger attached open your Debug/Windows/Modules list and inspect the messages for each module.

Wednesday, June 18, 2014

With smart frameworks like XAF it is inevitable that you will create applications one would except they developed by a whole team and not from just one person. A side effect of rich/large applications is that it is impossible to determine if all parts of the application function unless you have tests.

Enter AutoTest from EasyTest

XAF comes together with EasyTest a functional testing framework. EasyTest has an undocumented command the AutoTest. In short the AutoTest command will go through all your Navigation Items and for all related views will execute the New action if available and open/close the related detailview.

So, lets talk by example. In eXpandFramework there are 38 Demos with a large number of views, each one demonstrating certain features. By using the AutoTest command we can automate the opening of all views therefore we can expect a code coverage larger than 80%.

Following is the RunEasyTests target used in eXpandFramework build script (Xpand.build).

First we need to build all demos under the EasyTest configuration where the required EasyTest components are functional.

<CallTargetTargets="EasyTestUpdateDBTimeout" />

In the above line we call the EasyTestUpdateDBTimeout target that will run DBUpdater for all demos that have long operations in their ModuleUpdaters. We need to explicitly execute the DBUpdater because there is a threshold in time between each EasyTest command so the Login action may fail if moduleupdater takes more than 25sec to complete.

<DeleteFiles="@EasyTestLogs"/>

This command will delete all EasyTest logs to make sure that our build script will not pick up any previous failed tests.

This will copy a set of required files for EasyTest like the TestExecutor, XpandTestAdapters etc in the same path as the test. In the build server assemblies are not in the GAC so by putting them in the same path we minimize assembly binding errors due to version conflicts.

This line executes the TestExecutor for all EasyTests, It uses the ProcessAsUser.exe because the build script is actually executed from our build server service using the System Account which has no windows session therefore useful EasyTest features like screenshots are not available. In general we do not want to mess with the system account in order to make our tests run. So the ProcessAsUser reads a username and password from a registry key and by using an RDC connection (Windows Server) creates a new session and executes the tests there under the specified user security privileges. Finally because we are interested to execute all tests without failing the build to fail we set ContinueOnError to true.

A big thanks this time to the AutoTest command that provided 80% code coverage for our community framework. I am sure AutoTest will be extended to provide even smarter automated tested in future versions. If you got into that trouble and have interesting ideas to share or contribute for AutoTestV2 please use our community framework forums.

Tuesday, April 22, 2014

DevExpress offers a great installer for their components and frameworks. But if you work in a continuous integration environment or have to deal with different versions of the components NuGet packages are the better way to deploy and version-control dependencies. This project contains .nuspec files for DevExpress WinForms, Web and XAF assemblies. It is not an official release and it is not supported by DevExpress.

This is the description of the DX-Nuspec files, open sourced from Sergej Derjabkin a casual community contributor! The files are available in https://github.com/derjabkin/DX-Nuspec and of course they will be distributed as a submodule from eXpandFramework v13.2.9.1.

Welcome to my Blog

My name is Apostolis Bekiaris and I am working for DevExpress as a technical evangelist for the frameworks team, .Net is my passion and at this blog you will find a lot of my work using DevExpress Xaf framework and many others. If you want to contact me you can use the link bellow