Linq to SQL DBML TFS Merge Strategies

I know linq is a somewhat outdated framework but it’s super simple to use and still gets the job done for us. It’s been used for several years on our current project and we have always run into some issues when merging between 2 branches. The DBML and designer files would get all out of wack during the merge process and would require a lot of tweaking to make correct.

We created a project called “DBML Organizer” that we would run on the source .DBML and .layout files that would sort the XML alphabetically. From there the TFS merge logic would handle pretty much all cases.

The following code can be copied and pasted and used as is.

[code language=”csharp”]
using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Xml.Linq;

namespace DbmlOrganizer
{
class Program
{
static void Main(string[] args)
{
var path = args.Length > 0 ? args[0] : @"path to some folder with the .dbml files";

Directory.GetFiles(path, "*.dbml", SearchOption.TopDirectoryOnly).ToList().ForEach(f => FormatDbml(f));
Directory.GetFiles(path, "*.dbml.layout", SearchOption.TopDirectoryOnly).ToList().ForEach(f => FormatDbmlLayout(f));

Console.WriteLine("any key to continue");
Console.ReadKey();
}

private static void FormatDbmlLayout(string layoutFile)
{
var xml = XElement.Load(layoutFile);

var classShapes = (from cs in xml.Descendants("classShape")
orderby cs.Descendants("DataClassMoniker").First().Attribute("Name").Value
select cs).ToList();
classShapes.ForEach(cs => cs.Remove());

var nestedChildShapes = xml.Descendants("nestedChildShapes").FirstOrDefault();
if (nestedChildShapes == null)
return;

nestedChildShapes.Add(classShapes);

if (!File.GetAttributes(layoutFile).HasFlag(FileAttributes.ReadOnly))
{
xml.Save(layoutFile, SaveOptions.None);
Console.WriteLine("Processed Layout- " + layoutFile);
}
else
{
Console.WriteLine("Layout ignored because of read-only- " + layoutFile);
}
}

private static void FormatDbml(string dbmlFile)
{
Action<XNamespace, XElement> tableFormatter = (ns2, tableXml) => {
var type = tableXml.Descendants(ns2 + "Type").FirstOrDefault();

var columns = SortXml(ns2, tableXml, "Column", "Name").ToList();
type.Add(columns);
};

XNamespace ns = "http://schemas.microsoft.com/linqtosql/dbml/2007";

var xml = XElement.Load(dbmlFile);

var connection = xml.Descendants(ns + "Connection").FirstOrDefault();

var tables = SortXml(ns, xml, "Table", "Name").ToList();
tables.ForEach(t => tableFormatter(ns, t));

var functions = SortXml(ns, xml, "Function", "Name").ToList();

// don’t change the order of the function params, etc.
//functions.ForEach(f => FormatDbmlFunction(ns, f));

connection.AddAfterSelf(functions);
connection.AddAfterSelf(tables);

if (!File.GetAttributes(dbmlFile).HasFlag(FileAttributes.ReadOnly))
{
xml.Save(dbmlFile, SaveOptions.None);
Console.WriteLine("Processed DBML – " + dbmlFile);
}
else
{
Console.WriteLine("DBML ignored because of read-only- " + dbmlFile);
}
}

private static IEnumerable<XElement> SortXml(XNamespace ns, XElement parent, string elementName, string attributeName)
{
var elements = (from c in parent.Descendants(ns + elementName) orderby c.Attribute(attributeName).Value ascending select c).ToList();
elements.ForEach(e => e.Remove());
return elements;
}

}
}
[/code]

 

Assessments and Processes

Microsoft Licensing and Asset Management

In 2015, EmpireCLS needed to institute a formalized process for managing it’s Microsoft licenses. Up until this point EmpireCLS would never know until the “true up” period what the cost of licensing would be for the previous year and what upcoming years would hold.

We derived a simple inventory procedure to track software licenses; Sharpoint, SQL Server, Windows Server, Exchange, etc. This procedure allowed EmpireCLS to make better decisions throughout the year when provisioning new servers and doing various infrastructure maintenance tasks.

Some highlights…

  • SQL Server Software Assurance was discontinued saving hundreds of thousands of dollars over a 10 year period. Since EmpireCLS did not have the need to be on the latest versions of the software, and did not need Mobility Rights for SQL Server, this was a simple change.
  • Exchange Software Assurance was discontinued with the same type of savings and with a migration plan to Office 365 which would cut down even more on cost of the 400 MS Office licenses.
  • Training of EmpireCLS staff in regards to what Windows OS licenses to use and when was also a big win in overall savings on Datacenter vs. standard licenses.

HP Hardware Assessments

In 2015, EmpirCLS needed to figure out if moving to the latest HP storage solution was a required option. They currently had 3 storage units in place, with 1 coming close to end of life. In looking at the upcoming recurring maintenance costs vs. new storage and future maintenance costs we were able to guide EmpireCLS into just staying the course with existing hardware. This allowed them to save 3 to 4 hundred thousand for the first year and prolong the life of existing hardware. We tried to cut back on the “refresh your hardware” scenario that vendors push every 3 years.

Cloud Assessments

In 2016, EmpireCLS was weighing the benefits and costs of moving their data center to Microsoft Azure. We did deep analysis on SQL Server which we thought would be the most expensive option. We pointed out that since EmpireCLS already owned the SQL licenses through 2014 in perpetuity that it was more cost effective to leave the data center intact. This was taking into consideration data center power and space charges, FTE costs, and hardware licensing.

We then did another assessment to determine if it was a benefit to move the various websites to Azure. Since EmpireCLS already owned a lot of its hardware already, we found that it was more cost effective to cut maintenance contracts on existing hardware, using parts from unused server inventory, and then just move all websites to an internal VM, removing server licensing.

The final assessment we did was for migrating Exchange to the cloud, via Office 365. After weighing the costs of Exchange Software Assurance, hardware maintenance, storage, and Office client licenses it was determined that the move to Office 365 would greatly benefit EmpireCLS. I believe we were able to save 2 to 4 hundred thousand of a 10 year period.

These assessments were difficult because EmpireCLS had already made significant capital investments in software and hardware. If it was a ground up build it may have been a different story.

SDLC Procedures

In 2014, EmpireCLS needed help with structuring their development procedures for the multiple teams both local and remote. These procedures included full tracking of both critical path projects and day to day maintenance tasks.

We developed a set of Excel spreadsheets to pull in all TFS work items and to do analysis for forecasting future project completion dates, and to help with end of year financial cost analysis. We also used the spreadsheets to track project hours in relation to the various contractors that were working on the projects.

We instituted a modified SCRUM process where we would have a weekly sprint meeting, ad hoc impediment discussions, and pre-assigned work items.

We continuously released manually every 2 weeks. New features were exposed to subsets of users and controlled with feature toggles and security. We had a notion of beta users that could execute the latest code and give feedback. We had several notions of modules being in read-only validation states to allow cross referencing between multiple systems to validate before enabling write back.

Source Code Control Procedures

In 2007 EmpireCLS’ current Linux 1 million line code base had no source control and no build scripts. The development process was to copy a file and backup into a sub-directory before making changes.

We installed a TFS Linux client and added the entire code base to a TFS project. We then trained the 2 Linux developers on TFS check-in / check-out procedure sand branching scenarios.

Now that the code was source controlled we moved on to creating build scripts for the 120 programs and services that they were constantly updating. These build scripts where then source controlled.

The result of this was the clients code base being controlled, backed-up, and a repeatable build process.