Subprojects in PlayFramework 2.3 (Scala): overcoming difficulties

After struggling a bit to configure a Play 2.3 application (Scala) to work with subprojects (including another Play application) I've decided to create a simple example on GitHub.

Things to pay attention to:

• Build.sbt in the Root project to configure modules
• Root's conf/routes to attach Play subproject's routes to the routing system
• Play subproject's routes in modules/{subproject-name}/conf/{subproject-name}.routes
• Play subproject's build.sbt without unnecessary information
• Play subproject's controllers and views reside in additional subpackages {subproject-name}
• Explicitly added Assets controller in Play subproject
• How assests are referenced in Play subproject's main.scala.html

Introducing Antler Framework to the CodeProject community(Part II)

Welcome to read another article about Antler framework on the CodeProject in which I dived into details of implementing configurable Unit-of-work and ORM adapters.

Introducing Antler Framework to the CodeProject community

I've just posted an article introducing our open-source framework Antler to the CodeProject community.

The concepts explained in the article:

• Antler framework is an abstraction over ORMs
• Antler framework is an abstraction over IoC containers
• Antler framework improves testability of applications that use it
• Antler framework has pluggable structure

If you are interested you are welcomed to dive into the details on the CodeProject.

Antler Framework: TeamCity build server for our open source project

We are pleased to announce the launch of TeamCity build server for the Antler Framework for public viewing.

It is available here.

Antler Framework is a pluggable framework for .NET to work with popular ORMs(NHibernate, EntityFramework Code First) using the same syntax. GitHub: https://github.com/SmartElk/Antler.

Antler Framework: Releasing 2.0 Version

Antler is a pluggable framework for damn-easy good-style working with different ORMs using the same syntax.

"Pluggable" means that you can easily switch, say, between NHibernate and EntityFramework Code First using one line of code. Also you can easily switch your IoC container: currently we have Castle Windsor and StructureMap adapters.

Configuration example (using EntityFramework ORM + Castle Windsor container):

 var configurator = new AntlerConfigurator();  
 configurator.UseWindsorContainer().UseStorage(EntityFrameworkStorage.Use.WithConnectionString(connectionString).WithMappings(assemblyWithMappings));  

Antler Framework has strong architectural background out of the box: you can easily build your layered design using build-in support for UnitOfWork, Repository etc patterns.

If you are interested you are welcomed on GitHub:
https://github.com/SmartElk/Antler

Powershell: Deploying Windows Service remotely

As a big adherent of Continuous Integration practice I often need to deploy a Windows Service on an another computer remotely "by click".

Mostly, this task is performed from our TeamCity Build Server and consists of the following steps:

• Stopping remote Windows Service
• Backuping it's files
• Copying new files into the remote folder where the service is
• Starting remote Windows Service

It's very easy to accomplish these steps using Powershell:

• Get-WmiObject cmdlet is used for managing Windows Service remotely
• Robocopy tool is used for "smart" copying files into remote shared folder

If you are interested you can find the simplified script example on GitHub: 

https://github.com/ialekseev/DeployRemoteServiceExample

NuGet: Publishing different packages from the same solution

Let's say we need to generate different NuGet packages from our solution: core package and some specific adapter packages(e.g. Windsor container adapter package, EntityFramework + SQL CE adapter package).

This raises some interesting questions:

• How not to get confused with different versions when republishing packages?
• How not to forget to republish some package after you updated one of underlying projects?
• How to remember that you need to update some package(because you made some changes in underlying projects) and you don't need to update other packages(because you didn't make any changes to that projects)?

So, how the hell to keep this process simple and straightforward?

My answer is to republish every NuGet package from solution at once.
I have just one script file to run. When I run this file the following is happened:

• All projects from my solution are built in Release mode;
• Tests are run;
• All NuGet packages are created;
• All NuGet packages are published with the same specified version;

When I need to update any package from my solution I just run this script. I do not need to remember which projects from my solution I updated and which package I need to republish(core or some adapter). All I need is to run one script without any potential problems to upload broken package to NuGet repository.

Now I am planning to include republishing step in our Continuous Integration Server(TeamCity) using almost the same script.

See example of the build script in our Antler project: 
https://github.com/SmartElk/Antler/tree/master/build