Note that there are some explanatory texts on larger screens.

plurals
  1. POCompile a version agnostic DLL in .NET
    primarykey
    data
    text
    <h2>Scenario</h2> <p>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 <em>same</em> 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. </p> <p>We use .NET 2.0 and Visual Studio 2008.</p> <h2>Facts</h2> <p>Since Microsoft mysteriously changed the Office 2003 API in 2007, renaming and changing some methods (<em>sigh</em>) thus making them not backwards compatible, we <em>need</em> 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 Office in the same box for programming purposes. (you could technically have two Office together according to Microsoft) but <em>not</em> for programming and not without some issues.</p> <h2>Problem</h2> <p>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…)</p> <h2>Question</h2> <p>Is it possible to compile a DLL that will work with <em>any</em> 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.</p> <p>The secret reason for this is that we haven't changed our wrappers in "ages" and neither did Microsoft with their ancient APIs, yet we are recompiling the DLL to match the app version on <em>every</em> release we make. I'd like to automate this process instead of having to rely on <em>two</em> machines.</p> <p>I can't remove the DLL from the project (neither of them) because there are dependencies. </p> <p>I could create a third "master wrapper" but haven't thought about it yet. </p> <p>Any ideas? Anyone else with the same requirement? </p> <h2>UPDATE</h2> <p>Clarifying:</p> <p>I have 1 solution with N projects. </p> <p>"Application" + Office11Wrapper.dll + Office12Wrapper.dll.</p> <p>Both "wrappers" use dependencies for application + other libraries in the solution (datalayer, businesslayer, framework, etc.)</p> <p>Each wrapper has references for the respective Office package (2003 and 2007). </p> <p>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".</p> <p>Note: The Office 2007 Build Machine, has the Wrapper for Office 2003 "unloaded" and viceversa.</p> <p>Thanks in advance.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload