1

In C#, I have an assembly (AssemblyA) whose internals are visible to another assembly (AssemblyB) in the same solution, which I have achieved using

[assembly: InternalsVisibleTo(AssemblyB, PublicKey=1234566.......)]

However, AssemblyA is packaged into our installer, while AssemblyB remains an internal library that we do not want our customers to have access to. Does Assembly B need to be present for Assembly A to load properly? Currently I am getting a FileNotFoundException stating that then assembly or one of its dependecies was not found, and I am wondering if this is the case.

If this is indeed the case, is there a way to make the module load without Assembly B present?

codewario
  • 19,553
  • 20
  • 90
  • 159
  • You are talking about .net you almost give your customers the source code so what does this matters? – rekire Nov 26 '12 at 20:56
  • This is in no way constructive. – codewario Nov 26 '12 at 21:02
  • You are right but this is just a comment... – rekire Nov 26 '12 at 21:05
  • We commonly set the InternalsVisibleTo attribute to expose internals to our unit test assemblies, and we are able to deploy without needing the unit test assemblies present. So, in general, you do not need AssemblyB to be present to load AssemblyA as long as there are no other dependencies upon AssemblyB that AssemblyA has. – Eric Olsson Nov 26 '12 at 21:05
  • So this error I'm receiving is due to another issue then. I thought maybe there was some kind of strange behavior when using friend assemblies (I'm not very familiar with them), but it seems to not be the case. – codewario Nov 26 '12 at 21:14

1 Answers1

1

The fact that AssemblyA has InternalsVisibleTo(AssemblyB) does not mean that AssemblyA depends on AssemblyB or needs it runtime in order to load.

If you are getting a FileNotFoundException trying to load AssemblyA, that's because of another reason.

If you post the stack trace of the exception, along with some more code that shows what you are doing, this might help someone here solve the exception.

Additionally, you can use a tool such as the Fusion Log Viewer (fuslgvw.exe) that comes with .NET in order to view .NET assembly bind failures and figure out exactly which .dll is missing and where it was expected to exist.

Ran
  • 5,989
  • 1
  • 24
  • 26
  • A stacktrace won't be helpful here. The stacktrace stops at the method it blew up in, and if I run the debugger it blows up the second I try to instantiate an object from the "missing" assembly (even setting the object to null blows up). It is also worth mentioning that this only happens when our program is installed, everything works fine when debugging. I know that the assembly works because one of our services also uses the assembly and can access the dll fine. I think I'll give the Fusion Log Viewer a shot and see what that shows. – codewario Nov 27 '12 at 13:47