Small text Medium text Large text
  Useful links  
Genome Visual Studio 2019 Integration Update v1.0 release - Monday, September 16, 2019 - Monday, September 16, 2019
An updated version of the extension is available that is compatible with Visual Studio 2019. 

Genome Visual Studio 2017 Integration Update v1.0 release - Friday, April 07, 2017 - Friday, April 07, 2017
Starting with Visual Studio 2017 the Genome Visual Studio integration is distributed as separate Visual Studio Extension. The extension can be downloaded from the professional and express download sections. The v1.0 version includes support for Data Domain Schema projects (mapping project, mapping files). Support for Genome Messaging Extension (WOPii) will be included in the next version. 

Genome v4.2 SP10 released - Wednesday, May 18, 2016 - Friday, February 17, 2017
Genome v4.2.11 provides fixes for the integration to Microsoft Visual Studio 2015. With the update DataDomain schema projects can be compiled to .NET 4.6.1 and .NET 4.6.2 as well. The service pack contains a few minor fixes in the Sqlite provider and in the runtime too. 

Genome v4.2 SP9 released - Tuesday, September 22, 2015 - Tuesday, September 22, 2015
Genome v4.2.10 provides integration to Microsoft Visual Studio 2015 with the same functionality as for VS2013. Also with this update the DataDomain schema projects can be compiled to .NET 4.5.2 and .NET 4.6 too. The service pack adds support for PostgreSql database and contains a few minor fixes in the runtime too.  

Genome 4.2 SP8 supports VS2013 and .NET 4.5 - Thursday, October 24, 2013 - Thursday, October 24, 2013
Genome v4.2.9 provides integration to Microsoft Visual Studio 2013 with the same functionality as for VS2010 and VS2012. Also with this update the DataDomain schema projects can be compiled to .NET 4.5 and .NET 4.5.1 too. The service pack contains a few minor fixes in the runtime too.  

Genome 4.2 SP7 released - Wednesday, May 01, 2013 - Wednesday, May 01, 2013
With a few fixes and a small feature! 

Genome 4.2 SP6 supports VS2012 RTM - Friday, August 24, 2012 - Friday, August 24, 2012
Genome v4.2.7 provides integration to Microsoft Visual Studio 2012 RTM with the same functionality as for VS2010. This release contains only this tool enhancement and no change in the runtime. 

Genome 4.2 SP5 with VS2012 RC support - Friday, June 29, 2012 - Friday, June 29, 2012
Genome v4.2.6 provides integration to Microsoft Visual Studio 2012 RC with the same functionality as for VS2010. This release contains only this tool enhancement and no change in the runtime.

Important note: Visual Studio 2012 RC comes with a change in the MsBuild system, that causes the Genome builds fail (in VS2012 and also in VS2010) with the following error:
error MSB4185: The function "CurrentUICulture" on type "System.Globalization.CultureInfo" has not been enabled for execution.

This problem will be fixed my Microsoft in VS2012 RTM. In the meanwhile you have to set the environment variable “MSBUILDENABLEALLPROPERTYFUNCTIONS” to “1”. (You might need to restart Visual Studio).

Genome 4.2 SP2 (v4.2.3) released - Oct 29, 2010 - Friday, October 29, 2010
With many fixes and small features! read more ...

Genome 4.2 released - Feb 10, 2010 - Wednesday, February 17, 2010
Supports now Visual Studio 2010! read more ...

Updated roadmap - Dec 22, 2009 - Tuesday, December 22, 2009
learn more about the upcoming Genome v4.2 release read more ...

Genome 4.1 released - Mar 31, 2009 - Tuesday, March 31, 2009
Read more about what's new in this release. read more ...

New Product Video released - Jan 16, 2009 - Friday, January 16, 2009
Get a quick overview of Genome v4. read more ...

  How do I convince my manager?  

Object-relational mapping is quite a technical topic and as such is sometimes hard to introduce to managers or non-developers. The following description summarises the business use of object-relational mapping with Genome.

Less implementation efforts (lines of code)

The benefits of object-oriented over procedural code are broadly recognised in the modern software development industry (just look at .NET and Java whose base class libraries are implemented in a fully object-oriented way). However, mapping an object-oriented domain model to a relational database model (to create, read, update and delete data) involves significant implementation efforts. Even worse, this mapping always follows the same set of patterns, which means a lot of repetitive work and code duplications when done manually. This task can be much better addressed by Genome, which fully automates the mapping implementation based on a schema declared between the object model and the database. Genome does not generate code that needs to be maintained later and does not get bored or make mistakes because of repetitive work.
Think about how much of your code currently deals with data access. When using Genome, all this code does not need to be written nor maintained anymore. To give you an example, we have re-implemented the Microsoft PetShop V3.0 implementation with Genome, leading to a more than 50% reduction of statements in the Genome based implementation:


Less complexity increases flexibility and maintainability:
Changes can be implemented more quickly with less unwanted side effects

Additional code for mapping also adds subsequent additional efforts for maintenance and extensions. Manually coding a data access layers involves a lot of duplications as the mapping has to be reflected in every single SQL statement or stored procedure used. When changing the database structure or the business logic model, all duplications in the manually written data access layer have to be refactored, which can easily lead to errors or inconsistencies. This often leads to inflexibility in adapting the business model or changing the database model for larger application developments as changes become impossible to manage in the manually implemented data access layer.
Genome allows you to refactor your database structure and business model easily because it encapsulates both the entity-relational mapping as well as query logic.

Increased stability:
No hard-to-detect runtime errors when executing SQL from .NET. Dynamic queries are easier to manage.

Another typical weak point in .NET database-driven application development is the programming interface between database and business layer: to a .NET compiler (e.g. C#), a SQL command or stored procedure is just a string sent to the database which cannot be verified during compilation. This leads to hard-to-detect runtime errors when executing SQL from .NET, as the database will not parse the SQL command or stored procedure name until runtime and returns an error if there is a problem with it. This gets even worse when the business layer needs to compose dynamic queries. A very typical use case scenario for this is a search form where the user can fill in an arbitrary list of search criteria and the filter of the final query is dynamically composed from the given user input. In such cases, all possible flows of the dynamic query logic need to be tested (in the example: all possible user input combinations) to verify a correct query generation in all cases. In more complex scenarios this is usually impossible. As a result a lot of efforts are running into ad-hoc developed frameworks that provide a more secure usable and manageable infrastructure for dynamic query generation than StringBuilder and String.Format().
Genome allows you to map and verify static queries during compile time. Result sets can be dynamically composed using set operations that provide a strongly typed and compile-time checked interface for dynamic query building. Genome’s current infrastructure already anticipates today what will become more broadly available with Microsoft’s LINQ extensions for C# and VB.NET. Genome already supports (but does not depend on) LINQ today.

Real database independency:
Support for Microsoft SQL, Oracle and IBM DB2

If you have tried to support multiple database platforms in your applications already, then you know that ADO.NET does not perform enough abstraction for the database to become transparently exchangeable. The main reason for this is that ADO.NET only abstracts HOW to communicate with the database but does not abstract the communication with the database itself (i.e. the SQL commands you send). This is also partly related to the problem described before that the .NET compilers cannot “understand” queries formulated in SQL as each database platform implements its own specialised SQL dialect (T-SQL, PL/SQL, etc.).
Genome allows the database to be fully abstracted as it introduces its own database-independent object query language (OQL) that is translated automatically to the underlying database platform-specific SQL dialect. Alternatively, Genome can also translate queries formulated in LINQ into SQL. As Genome supports different database platforms, this enables true database platform portability for your solutions. Support can be extended to database platforms that are currently not supported by Genome at fixed prices, also addressing future portability demands of development investments.

Rapid prototyping without violating principles of layered architectures:
Clean data access layer separation with no extra efforts

Prototypes and very small projects are typically implemented in a „dirty“ manner, i.e. without layer separation and business layers. Prototypes usually have to be easy to change in order to try out new concepts and may reach an unexpected size quite easily, sometimes even up to the stage of having to go into production. Very small projects go into production and are often unexpectedly developed further. If basic principles of modern software architecture are disregarded due to time constraints, the prototype’s flexibility suffers, especially in its later evolution. Similarly it can happen that a prototype has to go into production, meaning that maintenance is a nightmare later on.
Genome enables clean, efficient implementing in small projects and prototypes. Its support for .NET data binding for ASP.NET and WinForms as well as the Database Reverse Engineering wizard it offers allow mapped business layers to be created quickly and without incurring additional costs for implementing data access layers.
Naturally, starting off with Genome entails a fairly steep learning curve, but this of course does not affect later projects. An experienced Genome user will work faster even in small projects by using Genome, while producing cleaner architecture.

Data access abstraction is a key concept for large scale projects:
Don’t start implementing your custom O/RM just for a single project

The points above about prototypes and small projects are of course even more important in large-scale projects. From a certain size onward, projects cannot make do without abstracting database mappings. Failing to select an O/RM product usually leads to having to develop an own database access library for the project. Apart from the implementation effort, which stands in no relation to Genome’s price tag, the quality and flexibility of Genome are substantially greater than those of individually developed data access layers. Genome has been continuously improved since 2001 and is currently used by customers around the world.
Other significant difficulties encountered with individual database abstractions concern documentation, knowledge transfer and maintenance. Usually a small team (sometimes even just a single person) implements the database abstraction in a large project. They have no time for documentation, training and knowledge transfer. Responsible persons may leave the project, leaving behind a knowledge gap and maintenance problems. Genome on the other hand is supported by TechTalk, a software company specialising in .NET development with over 30 employees and worldwide customers who have been using Genome for over four years.

Proven track record, future proof architecture
Genome already supports upcoming technologies on the Microsoft platform, in particular LINQ. LINQ is not yet available as a release and cannot therefore be used in critical projects yet. Projects developed with Genome can switch to LINQ at any time, as soon as LINQ reaches the necessary stability and has been released. Existing code and query logic in OQL do not need to be replaced, but can be used alongside LINQ for as long as it takes to switch all queries to LINQ (if desired).