How would you distribute an app with interop DLL dependencies you can't distribute?
-
I have a .NET app that I've been developing that uses Office automation for some features. Way back when I started using COM DLLs, I let Visual Studio do the interop generation for me. Eventually, I graduated to being able to generate my own interop DLLs outside of Visual Studio to support multiple versions of Office. However, in all of these cases, I was working with software on my system or at least a system I controlled.
How would you distribute an app like this such that a non-programmer could use those features without jumping through interop hoops?
: I'm not asking if Office automation is a good idea. I'm asking how I can use COM interop without distributing COM DLLs (or at least the versions of said DLLs that I have locally).
-
If I understand right, you'll need to generate interop dlls for the Office Interop dlls? After that just put a check for the supported version of Office interop DLL in the installer.
-
@Tsaukpaetra said in How would you distribute an app with interop DLL dependencies you can't distribute?:
If I understand right, you'll need to generate interop dlls for the Office Interop dlls? After that just put a check for the supported version of Office interop DLL in the installer.
Say I want to export a spreadsheet.
I go to References, COM, Excel 9.0 Object Library. VS generates Interop.Excel.DLL and puts it in the Bin folder.
Or I can run this tool against multiple copies of the Excel object library, generating a separate interop DLL and namespace for each version (2000, XP, 2010, 2016, etc). I don't think I have to do any custom registration but honestly it's been years since I looked at how the tool works. It's based on Microsoft's type library importer/exporter.
I don't believe I can package those interop DLLs with the app. It's not like P-Invoke, where I don't have to. So I don't know how I would get anything for the app to call on a random user's machine.
-
@Zenith said in How would you distribute an app with interop DLL dependencies you can't distribute?:
Or I can run this tool against multiple copies of the Excel object library, generating a separate interop DLL and namespace for each version (2000, XP, 2010, 2016, etc). I don't think I have to do any custom registration but honestly it's been years since I looked at how the tool works.
Right, so you get a bunch of interop DLLs, then you select which one to load and load that.
At least, I think. I haven't done a custom thing like this, but I think that's the general idea; the hard part is deciding which interop you need at runtime.
@Zenith said in How would you distribute an app with interop DLL dependencies you can't distribute?:
I don't believe I can package those interop DLLs with the app.
... Why not? In recent versions you can even embed the interops directly in your app's resources (with some caveats that the Internet will help you learn).
-
I think you can't distribute the type libraries or the official PIAs that Microsoft generates, but you can distribute interop assemblies you generate yourself, whether you generate it with Visual Studio or hand write it or (since you're a consumer) even
ilmergeit into your main assembly.
-
Yeah I'm not understanding why you can't distribute the interop DLLs either.
-
@Tsaukpaetra @TwelveBaud @bobjanova Because the way it looked from examining TLB import/export, it was effectively rebuilding those libraries in MSIL. It looked to me like WINWORD.EXE was just a shell to call functions in MSWORD9.OLB (and similar with Excel and Outlook). My expectation was that, supposing I registered those types on client machines, I could distribute Office functionality, using Microsoft code, without having a license for Office.
@Tsaukpaetra said in How would you distribute an app with interop DLL dependencies you can't distribute?:
Right, so you get a bunch of interop DLLs, then you select which one to load and load that.
At least, I think. I haven't done a custom thing like this, but I think that's the general idea; the hard part is deciding which interop you need at runtime.The solution I came up with was to put a flag in my configuration file and switch on it. I was never able to find a reliable way to automatically determine which version of Office was installed. About the closest was jumping through the part of the registry referenced by the Add/Remove Programs dialog and hoping the version number supplied there was right. I ran into a similar situation trying to determine what version of Internet Explorer was being embedded.
-
@Zenith said in How would you distribute an app with interop DLL dependencies you can't distribute?:
My expectation was that, supposing I registered those types on client machines, I could distribute Office functionality, using Microsoft code, without having a license for Office.
That would seem to be highly unlikely, and the kind of thing likely to get someone into a lot of trouble.
-
@dkf said in How would you distribute an app with interop DLL dependencies you can't distribute?:
@Zenith said in How would you distribute an app with interop DLL dependencies you can't distribute?:
My expectation was that, supposing I registered those types on client machines, I could distribute Office functionality, using Microsoft code, without having a license for Office.
That would seem to be highly unlikely, and the kind of thing likely to get someone into a lot of trouble.
I don't mean "could" as in "I'm allowed to do this" but "it's possible to do this." That's why I'm asking how I can distribute an app that needs, say, Excel and uses the customer's existing installation instead of my local interop DLLs.
-
@Zenith Well, you're probably looking at opening the DLL dynamically and just grabbing the function addresses out of that. When you're opening a DLL for that sort of thing, if you pass the full pathname of the DLL then it can be anywhere on the filesystem. (This is not a very well documented thing.) If you can find the Office installation, that ought to be enough.
Or maybe there's a COM server you can use.
-
What about the Microsoft Interop assemblies available from NuGet?
I thought those could be distributed seeing as they don't really provide the actual functionality and rely on Office being installed.
-
I'm a bit confused. It's been a while since I did .NET COM Interop, but I'm pretty sure those generated DLLs are just proxies to a running COM instance. In my case iTunes, in your case Office. So I expect a call against one of those proxies, if a user doesn't have Office, would blow up. If you can't detect that in the installer to tell the user a dependency isn't met (having Office), then I'd expect you'd get a specific exception type and/or message that you could detect to tell the user Office is missing at runtime.
-
Question about the per version interops - do you need to use the literal one for a user's Excel install? Or can you use the lowest version one that has the features you need and it'll call that version of Excel or any newer version? For instance if you have Excel 2013, can the Excel 2003 interop proxy talk to it?
-
@dkf said in How would you distribute an app with interop DLL dependencies you can't distribute?:
Or maybe there's a COM server you can use.
I was under the impression that that's literally what interop is for...
-
NPOI?
-
@Zenith said in How would you distribute an app with interop DLL dependencies you can't distribute?:
Because the way it looked from examining TLB import/export, it was effectively rebuilding those libraries in MSIL. It looked to me like WINWORD.EXE was just a shell to call functions in MSWORD9.OLB (and similar with Excel and Outlook). My expectation was that, supposing I registered those types on client machines, I could distribute Office functionality, using Microsoft code, without having a license for Office.
WinWord.EXEis just a shell aroundMSWORD9.OLB; that's how COM Object Linking and Embedding works. However, creating an interop assembly doesn't rebuild the library in MSIL; instead, it creates an MSIL-callable wrapper that hides the machinery needed to call COM away from your code. It still needsMSWORD9.OLBon the target machine, and the only legal way to do that is with a licensed copy of Word.
-
@TwelveBaud said in How would you distribute an app with interop DLL dependencies you can't distribute?:
the only legal way to do that is with a licensed copy of Word.
Right. And that's what
you're@Zenith requiring, right?Unless I'm misreading
youhim andyourhe's saying it's impossible to make that DLL file without the file from the client (target) machine?Edit: who am I even talking to anymore...
-
@Tsaukpaetra said in How would you distribute an app with interop DLL dependencies you can't distribute?:
Unless I'm misreading you and yours saying it's impossible to make that DLL file without the file from the client (target) machine?
You can download the interop DLLs from Microsoft.
-
@Tsaukpaetra Well I'm hoping that the interops generated here will work against the type libraries installed there.
-
@Zenith said in How would you distribute an app with interop DLL dependencies you can't distribute?:
@Tsaukpaetra Well I'm hoping that the interops generated here will work against the type libraries installed there.
Only one way to find out!
-
@Zenith They will. All that matters is the "shape" of the interface and the GUIDs registered in COM, neither of which change per machine.
-
@Zenith said in How would you distribute an app with interop DLL dependencies you can't distribute?:
Or I can run this tool against multiple copies of the Excel object library, generating a separate interop
Isn't it worth testing if the Interop of the oldest work in the newer ones?
-
@sockpuppet7 said in How would you distribute an app with interop DLL dependencies you can't distribute?:
@Zenith said in How would you distribute an app with interop DLL dependencies you can't distribute?:
Or I can run this tool against multiple copies of the Excel object library, generating a separate interop
Isn't it worth testing if the Interop of the oldest work in the newer ones?
It didn't last time.
