Compile a version agnostic .DLL in .NET (Using Manifests?)

Question

Hi,

SCENARIO: I have two wrappers around Microsoft Office, one for 2003 and one for 2007. Since having two versions of Microsoft Office running side by side is "not officially possible" nor recommended by Microsoft, we have two boxes, one with Office 2003 and the other with Office 2007. We compile the wrappers separately. The DLLs are included in our solution, each box has the same checkout but with either office 2003 or 2007 "unloaded" so it doesn't attempt to compile that particular DLL. Failure to do that will throw errors on compilation due to the Office COM dlls not available.

We use .NET 2.0 / VS2008

FACTS: Since Microsoft mysteriously changed the Office 2003 API in 2007, renaming and changing some methods (sigh) thus making them not backwards compatible, we need the two wrappers. We have each build machine with the solution and one Office DLL activated. E.g.: the machine with Office 2003 has the "Office 2007" dll unloaded, therefore not compiling it. The other box is the same idea but the other way around. All this because we can't have 2 different offices in the same box for programming purposes. (you could technically have two offices together according to Microsoft) but not for programming and not without some issues.

PROBLEM: When we change the Application Version (from 1.5.0.1 to 1.5.0.2 for example) we need to recompile the .DLL to match the new version of the application, this is automatically done, because the office wrapper is included in the solution. Since the wrappers are contained in the solution, those inherit the APP Version, but we have to do it twice and then "copy" the other DLL to the machine that creates the installer. (A Pain…)

QUESTION: Is it possible to compile a DLL that will work with any version of the application, despite being "older" ? I've read something about manifests but I have never had to interact with those. Any pointers will be appreciated.

The secret reason for this is that we haven't changed our warppers in "ages" and neither did Microsoft with their ancient APIs, yet we are recompiling the DLL to match the app version on every release we make. I'd like to automate this process instead of having to rely on TWO machines.

I can't remove the DLL from the project (neither of them) because there are dependencies.

I could create a third "master wrapper" but haven't thought about it yet.

Any ideas? Anyone else with the same requirement?

UPDATE: Clarifying:

I have 1 solution with N projects.

"Application" + Office11Warpper.dll + Office12Wrapper.dll.

Both "wrappers" use dependencies for application + other libraries in the solution (datalayer, businesslayer, framework, etc.)

Each Wrapper has references for the respective Office Package (2003 and 2007).

If I compile and don't have office 12 installed, i get errors from Office12Wrapper.dll not finding the Office 2007 libraries. So what I have are two building machines, one with Office 2003, one with Office 2007. After a full svn update + compile on each machine, we simply use office12.dll in the "installer" to have the wrapper compiled against the "same code, same version".

Note: The Office 2007 Build Machine, has the Wrapper for Office 2003 "unloaded" and viceversa.

Thanks in advance.

Answer 1

Just a thought - could you use TlbExp to create two interop assemblies (with different names and assemblies), and use an interface/factory to code against the two via your own interface? Once you have the interop dll, you don't need the COM dependency (except of course for testing etc).

TlbImp has a /asmversion for the version, so it could be done as part of the build script; but I'm sure you even need this: just make sure that "specific version" is false in the reference (solution explorer)?

Also - I know it doesn't help, but C# 4.0 with dynamic and/or "No PIA" might help here (in the future; maybe).

Answer 2

I'm not sure I am completely following everything you stated, but let me try:

It sounds like you have one solution with 2(?) projects. One is the actual application, and the other is a wrapper for the Office API. Your application then has a project reference to your Office API wrapper. I've never programmed for office before, but it sounds like the programming APIs are a common component that you can only have one version of on a machine (ie. 2003 or 2007, not both). And maybe this is where the problem is, but because you have a project reference, the wrapper will be compiled first, copied to the bin directory of your application, where your application will be linked to that build of the wrapper. This will cause the manifest of the application to specifically request that version of the wrapper at run time.

If you had the wrapper in a separate solution, and added a reference to the compiled library rather than the project, you would always link your application to that version of the wrapper and you could avoid the problem.

Another possible choice is Assembly Binding Redirection. This is more advanced, and comes with it's own set of problems, but you can read about it here.

Or similar to Marc's idea, you could extract an interface and pull some common objects into a Framework library, and code your application against the interface and common objects. Then at runtime use reflection to load the assembly and instantiate the wrapper you want.

I think the key is to remove the project dependency if you can. It sounds like the wrapper is pretty stable and isn't changing, otherwise you wouldn't be asking to link to a previous version of it.

Answer 3

Installing Office 2003 and 2007 side-by-side on the same machine is definitely possible - we do it in our organisation even on end-user production workstations.

In that linked article, Microsoft recommend that you don't do this for actual use. But in your case it appears to be just for a single build machine, i.e. you're not going to actually use either version of Office on that machine. In this context, I would try to see if you can make the side-by-side installation work.

My assumption might be wrong, and you're attempting to do this for every developer's machine. In that case, you should ignore this answer :-)

Answer 4

When the .NET assembly resolver is unable to find a referenced assembly at runtime (in this case, it cannot find the particular wrapper DLL version the application was linked against), its default behavior is to fail and essentially crash the application. However, this behavior can be overridden by hooking the AppDomain.AssemblyResolve event. This event is fired whenever a referenced assembly cannot be found, and it gives you the opportunity to substitute another assembly in place of the missing one (provided that they are compatible). So, for instance, you could substitute an older version of the wrapper DLL that you load yourself.

The best way I've found to do this is to add a static constructor on the main class of the application that hooks the event, e.g.:

using System.Reflection;

static Program()
{
    AppDomain.CurrentDomain.AssemblyResolve += delegate(object sender, ResolveEventArgs e)
    {
        AssemblyName requestedName = new AssemblyName(e.Name);

        if (requestedName.Name == "Office11Wrapper")
        {
            // Put code here to load whatever version of the assembly you actually have

            return Assembly.LoadFile("Office11Wrapper.DLL");
        }
        else
        {
            return null;
        }
    }
}

By putting this in a static constructor of the main application class, it is guaranteed to run before any code attempts to access anything in the wrapper DLL, ensuring that the hook is in place ahead of time.

You can also use policy files to do version redirection, but that tends to be more complex.

Answer 5

Nice sleuthwork! I just threw together an implementation based on the concept presented above, and it works wonderfully:

static Assembly domain_AssemblyResolve(object sender, ResolveEventArgs args)
{
     string partialName = args.Name.Substring(0, args.Name.IndexOf(','));
     return Assembly.Load(new AssemblyName(partialName));
}

Of course there is room for enhancement, but this does the trick for me!