Removal of Windows Services Fails? Use the Correct Version of InstallUtil.exe

This is a narrative, following my resolution to removing a stubborn service that simply wouldn't let go.

Today, I tried using the Developer Command Prompt for VS2013 running as administrator, to remove a Windows Service I was developing in Visual Studio 2013 and testing on my workstation. Instead of removing the service, all I got was this lousy T-shirt. And this exception:

Exception occurred while initializing the installation:
System.BadImageFormatException: Could not load file or assembly 'file:///C:\Dev\ ... \MyService.exe' or one of its dependencies. An attempt was made to load a program with an incorrect format.

Huh. That's weird. The project was started in Visual Studio 2012 and not 2013. So, I tried using the Developer Command Prompt for VS2012 running ad Administrator; sometimes that will fix the issue. I launched it, and typed (well, copied and pasted):

cd "C:\Dev\ ... \Release"
installutil /u MyService.exe

Nope! I got the command displays an error identical to the first. I tossed this second T-shirt on my pile of conference shirts, and stepped back from the problem. So, if it isn't the .NET Framework version, and the path is definitely correct, something else must be different. I looked up the InstallUtil.exe in the usual place, in Windows Explorer:

C:\Windows\Microsoft.NET\Framework\v4.0.30319

But, then something caught my eye. The "Framework64" directory. Ah. Because my Windows Service is to be executed on a server, I targeted the x64 CPU instruction set in the build profile. In the developer command prompt window, I typed:

cd C:\Windows\Microsoft.NET\Framework64\v4.0.30319installutil /u "C:\Dev\ ... \MyService.exe"

The utility happily complied, and I am free of the service.

Moral of the story:
You must use the proper x86 or x64 utilities, to match the target platform of the binary files.

Resolve Visual Studio Project Mismatch Between Processor Architecture

The Problem

Starting in Visual Studio 2012, you may have seen this .NET Framework compiler warning (it is not an error):

There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference [project path], "AMD64". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.

This is easy to resolve! The warning means one of two things:

1. The target CPU platform (x86, x64, Itanium, etc.) of one or more projects does not match the others
2. A referenced resource (DLL) is compiled for a different CPU platform than the referring project

Fixing the problem is easy:

1. Ensure all projects in the solution are set to the same CPU platform target
2. Ensure projects referencing DLL files are set to the same CPU platform as the DLL

Troubleshooting

Entity Framework 5 to 6.0.1 Upgrade SqlProviderServices Exception

Today, I decided to update my Entity Framework (EF) 5.0 NuGet packages to EF 6.0.1. No problem updating; NuGet did its duty, as usual. However, a great number of the Model project tests failed, and executing the application threw an exception, as expected:

The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider 

with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. 

See http://go.microsoft.com/fwlink/?LinkId=260882 for more information.

As usual, the link provided minimal assistance. With a little prodding, I found a workaround for the issue.

The goal of this post is to make as few modifications to the code base as possible, to make the EF5 to EF6 upgrade. Sure, there are some differences between EF5 and EF6 implementation, but we're ignoring that for now. EF6 does not require data provider configurations in the App.config file. The new ProviderService types, embedded in the System.Data.Entity.(ProviderName) namespace does this for us. But, these are the objects giving us trouble. First things first...

Versioning RESTful Services

As I was explaining Representational State Transfer (RESTful) Service Oriented Architecture (SOA) to my customer, who require extensive modernization of an enterprise class system, they asked a very good question:

"Things change over time. If everything is service based, how do we handle versioning of the services, without client disruption. When one applications suddenly requires different information, we can't update all of the other client applications just to accommodate the needs of the one. We also should not be duplicating services fo every client that needs something slightly different."

Excellent question! There are myriad reasons to update a service, but only three major courses of action to follow. One of the three will be a best fit for each situation. Sometimes, things are just that easy. The options are few; because, the ultimate goal is to maintain integrity of the URLs. You simply don't want your service URLs changing, for many reasons into which I will not delve in this post. (If you are reading this post, you should know well enough to be nodding in agreement, anyway.)

To be clear, this post covers RESTful services, such as Web API, and not traditional WISDL-based Web Services or object serialization proxy services, like WCF. No, we're talking true REST.