How to package references into DLL?

[Brett Romero]

If I create a DLL (my.dll) that references other DLLs, how do I make
sure other developers only need my.dll and not all of the other DLLs it
references? Is there a way to compile the references into my.dll and
just distribute one DLL?

Thanks,
Brett

 

[Jon Skeet [C# MVP]]

If I create a DLL (my.dll) that references other DLLs, how do I make
sure other developers only need my.dll and not all of the other DLLs it
references? Is there a way to compile the references into my.dll and
just distribute one DLL?

Well, there's ILMerge, but that's a bit of a hack - it's not how things
were meant to work.

You *should* distribute the separate DLLs. That way, if there's a patch
available for a particular DLL, that patch can be applied without
affecting anything etc. It also keeps it clear where things came from.

Do you have any particular reason for not wanting to ship the other
DLLs separately?

 

[Brett Romero]

No. I just wasn't aware of the missing references in this case.

The recipient will have problems then if the distributor does not
provide everything? Is there a way for the recipient to know ahead of
time if DLLs are missing? Meaning, before they spend time compiling
and getting errors.

Thanks,
Brett

 

[Jon Skeet [C# MVP]]

No. I just wasn't aware of the missing references in this case.

The recipient will have problems then if the distributor does not
provide everything? Is there a way for the recipient to know ahead of
time if DLLs are missing? Meaning, before they spend time compiling
and getting errors.

Well, you could fairly easily write a dependency walking app to make
sure that everything's there - but a manual "these are the files you
need" file list is probably a more straightforward solution

 

[Brett Romero]

Here's a scenario, I include the new DLL in my app. It compiles fine.
Then I hit this line of code:
Config.GetAppSetting()

and get this error:

An unhandled exception of type 'System.IO.FileNotFoundException'
occurred in core.test.dll

Additional information: File or assembly name log4net, or one of its
dependencies, was not found.

I put the log4net.dll in my bin folder and everything is fine. I can't
find any place that log4net is referenced in core.test.dll or my app.
How is Config.GetAppSetting() able to do anything when there is no
"using" statement or reference to its library?

If I do a go to definition, I get a cannot navigate error. If I do a
go to reference, I get a symbol has no reference error. I don't
understand how this code is linked to the library or how it is
referencing it. Any ideas?

Thanks,
Brett

 

[Brett Romero]

Well, you could fairly easily write a dependency walking app to make
sure that everything's there - but a manual "these are the files you
need" file list is probably a more straightforward solution

In reference to the first question, all of those DLLs don't have to go with
the main DLL. After putting the log4net.dll into the bin folder, I was able
to remove all the other DLLs used to build my.DLL. How is my.DLL able to be
distributed without its references?

Thanks,
Brett

 

[Jon Skeet [C# MVP]]

In reference to the first question, all of those DLLs don't have to go with
the main DLL. After putting the log4net.dll into the bin folder, I was able
to remove all the other DLLs used to build my.DLL. How is my.DLL able to be
distributed without its references?

It can't be, if it actually uses those references. If it's trying to
call into Log4Net code, it makes sense that you've got have Log4Net on
the system in order to get it to work.

 

[Jon Skeet [C# MVP]]

Here's a scenario, I include the new DLL in my app. It compiles fine.
Then I hit this line of code:
Config.GetAppSetting()

and get this error:

An unhandled exception of type 'System.IO.FileNotFoundException'
occurred in core.test.dll

Additional information: File or assembly name log4net, or one of its
dependencies, was not found.

I put the log4net.dll in my bin folder and everything is fine. I can't
find any place that log4net is referenced in core.test.dll or my app.

Well, I would suggest that it's there somewhere. Open up the DLL in
reflector and look at the referenced assemblies there.

How is Config.GetAppSetting() able to do anything when there is no
"using" statement or reference to its library?

It's hard to know without seeing the code.

 

[Brett Romero]

Well, I removed all of the DLLs from my project that are referenced in
main.dll. I also deleted these DLLs from my project bin. The only DLL
I'm referencing in main.dll. This means, although main.dll referenced
other DLLs during its compiling, they don't have to be distributed with
main.dll.

Why is that? I know you disagree but that's just the empirical facts
of the situation. I'm still confused as to whether a DLL I create,
which references other DLLs in its project, must be distributed with
all of its references. According to the above scenario, the answer is
no.

Thanks,
Brett

 

[Brett Romero]

I did open main.dll in reflector. In the references, log4net is no
where to be found. Yet, I can't use main.dll unless log4net is in my
project's bin folder with main.dll.

 

[Jon Skeet [C# MVP]]

Well, I removed all of the DLLs from my project that are referenced in
main.dll. I also deleted these DLLs from my project bin. The only DLL
I'm referencing in main.dll. This means, although main.dll referenced
other DLLs during its compiling, they don't have to be distributed with
main.dll.

Why is that? I know you disagree but that's just the empirical facts
of the situation. I'm still confused as to whether a DLL I create,
which references other DLLs in its project, must be distributed with
all of its references. According to the above scenario, the answer is
no.

If one assembly references another, then if any of the code it executes
tries to load a type from that second assembly, then yes, the assembly
must be present.

 

[Jon Skeet [C# MVP]]

Well, I removed all of the DLLs from my project that are referenced in
main.dll. I also deleted these DLLs from my project bin. The only DLL
I'm referencing in main.dll. This means, although main.dll referenced
other DLLs during its compiling, they don't have to be distributed with
main.dll.

Why is that? I know you disagree but that's just the empirical facts
of the situation. I'm still confused as to whether a DLL I create,
which references other DLLs in its project, must be distributed with
all of its references. According to the above scenario, the answer is
no.

Just as a thought - does your configuration file mention log4net
anywhere? Maybe a config setting is trying to load it reflectively...