Sign in to follow this  
MJW

How do I link a plugin DLL with a utility DLL?

Recommended Posts

That may not be clear, but let me try to explain.

 

I'm writing a Visual Studio plugin. One of the routines seemed to be generally useful, so I decided to make it a separate project, so I could use it with other plugins. I made the utility project, which, of course, builds a DLL. I then made a plugin project whose VS "solution" includes both the plugin and the utility project. The plugin project depends on the utility project. Both projects build correctly, but when PDN tries to run the plugin, I get an error saying it can't load the utility DLL. I suppose since it's called a Dynamically Linked Library, I should have expected that, but my understanding of how all that works is rudimentary.

 

My question is whether there's an easy way to make the project produce a DLL that contains both the plugin routines and the utility routines (from the utility DLL), so it can be called as a plugin from PDN.

Edited by MJW

Share this post


Link to post
Share on other sites

That's exactly what I don't want to do. I don't want the plugin to rely on another DLL; I want to have the project produce a DLL that takes the plugin routines and the utility routines (which are in a DLL) and produce a single DLL that contains them both. The combined DLL would be the plugin.

 

EDIT: The idea is that I have various utility routines that may be used in a number of plugins. Instead of having to include them as part of each plugin project, I want to build them once and have them linked into the plugins. It seem like a very basic and useful thing to do.

Edited by MJW

Share this post


Link to post
Share on other sites

In regard to versioning, I thought .NET was supposed to have something to deal with DLL version problems. If it does, and if someone can briefly explain it, I would certainly appreciate it. The idea of having separate DLLs for the utilities, loaded at runtime, sounds less bad now that I how how difficult it is to link DLLs at build time.

Share this post


Link to post
Share on other sites

... if someone can briefly explain it ...

 

hahahahahahahahahah

 

Sorry, I'm not actually laughing at you. But the .NET versioning stuff, with strong naming and whatnot, cannot be briefly explained other than "if possible, stay the hell away" :)

  • Upvote 1

Share this post


Link to post
Share on other sites

I have to agree with Rick. It's a complex story. We are doing this in exactly one product in a mixed environment of c# and c++ libraries and we will never do it again for an other product.

OptionBasedLibrary uses therefore the simple method of different .dll names if the interface changes. Only bug fix releases are using the same name. The big disadvantage is that there are multiple variants out there. Hopefully we can get rid of the old variants with version 0.8 and updated plugins.

Share this post


Link to post
Share on other sites

 

But the .NET versioning stuff, with strong naming and whatnot, cannot be briefly explained other than "if possible, stay the hell away"

 

Too bad. I was hoping .NET was the cure to DLL Hell, not another level.

Share this post


Link to post
Share on other sites

If you are still curious how to use a dll file within an application, I have prepared a simple application for you to illustrate how to do it. I chose an executable here, but doing this from an effect dll would be the same. (Sorry if this offends you, I'm just not sure your level of understanding.)

Here is the compiled app:

MyFormApp.zip

Here is the project files:

MyFormSrc.zip

What this project does not address is the versioning problem. That is, if you make changes to the dll file, the project may stop working. Bug fixes should be fine, but don't add/delete functions or change the parameter list of a function.

If you do add/delete functions from your dll or change the parameter list of a function, you should change the dll's name to avoid versioning problems.

Just so you know, none of my effect dll's rely on external dll's for this very reason. Programmers that do put their library functions into a separate dll can tell you how much trouble their users have with installing an older version of the library dll over the top of a new library.

Hope this helps.

  • Upvote 1

Share this post


Link to post
Share on other sites

Thank you, BoltBait.  Don't worry about offending me; I said my knowledge of DLLs is rudimentary, and that wasn't false modesty.

 

I'll make the little project I'm working on function with separate DLLs just to learn how it's done, but I probably won't use that method as the ultimate solution. I doubt the versioning problems are worth it compared to the inelegant but simpler solution of including the utility routine's source file in each project the uses it.

Edited by MJW

Share this post


Link to post
Share on other sites

There are cases however, where you can't get around external dll's (e.g. when you need to interop with native dlls).

 

In my opinion, the real problem is, that the user needs to manually copy installation files/dlls. Ideally, we would provide our plugins with installers, which prevent the user from overwritting dlls with outdated versions (of course you still have to take care, that newer versions are backwards compatible).

Share this post


Link to post
Share on other sites

I'm not sure this fits your needs, but I came across ILMerge-GUI today. It lets you merge your dependencies into your main .dll file. As its name suggests, it only works with .NET assemblies. It's very easy to use, and It works very well.

  • Upvote 1

Share this post


Link to post
Share on other sites

Thank you, toe_head2001. I'll probably give it a try.

 

I've been trying to overcome my aversion to providing extra DLLs with plugins, but it still rubs me the wrong way. My original comment in this thread involved some functions I want to share between plugins. The functions fit into a single source file. I've found an acceptable solution in just putting the source file into a separate folder and linking the file into each project. But for more involved library functions, involving multiple files, (such as control libraries) that doesn't seem like a reasonable method.

Share this post


Link to post
Share on other sites

In regard to versioning, I thought .NET was supposed to have something to deal with DLL version problems. If it does, and if someone can briefly explain it, I would certainly appreciate it. The idea of having separate DLLs for the utilities, loaded at runtime, sounds less bad now that I how how difficult it is to link DLLs at build time.

Read this. It is a real-world example of a DLL versioning problem right here in River City!

I'm not sure this fits your needs, but I came across ILMerge-GUI today. It lets you merge your dependencies into your main .dll file. As its name suggests, it only works with .NET assemblies. It's very easy to use, and It works very well.

BTW, this is EXACTLY how CodeLab works today. Since converting over to the Notepad++ editor, we needed to include a separate DLL with the editor in it. Instead of shipping 2 DLL files, we're using ILMerge to combine both DLL files into one.

It is a little harder to compile CodeLab, but most users won't ever notice the difference and they won't have problems with versioning if we ever upgrade the Notepad++ editor version we're shipping.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this