C# + DLL dependency issue

[nelsonbrodyk]

Hey all,
This is a bit of a weird one, so I'll try and explain it best I can.
I have 1 dll that contains a third party library of wpf user controls (Bag o tricks). In my framework dll, I added this dll and reference it. I then made my own component that extends one of the components in the third party library. So far so good.

Now if someone else depends on my project, and they try and use the component I offer (that extends the third party component), the following error is thrown:

'Cannot resolve dependency to assembly 'J832.Wpf.BagOT ricksLib, Version=0.0.0.0 , Culture=neutral , PublicKeyToken= null' because it has not been preloaded. When using the ReflectionOnly APIs, dependent assemblies must be pre-loaded or loaded on demand through the ReflectionOnlyA ssemblyResolve event.

Is there something I am doing wrong? I figure that if they use my control, that control should have loaded the dll and should know how to use it?

Any ideas would be much appreciated.

Cheers,

[Plater]

Is this a project on the same system? If it's a different system, are you exposing/transfering all the correct .DLLs you will need?

[nelsonbrodyk]

Is this a project on the same system? If it's a different system, are you exposing/transfering all the correct .DLLs you will need?

Hmm can you be more specific? The Bag O Tricks library exists within my module, A.

Module B, depends on A, and tries to use something from A when the error occurs. This is when running in VS.

In production module A contains the Bag O Tricks library, so they will be on the same system, but Module B might not be. Module B would get downloaded to the client machine (which would have A via clickOnce). How or what do I need to do to expose the .DLL's?

[Plater]

What I was getting it that if your DLL (that uses that bag o tricks DLL) is 'compiled' and sent elsewhere, it won't contain the bag o tricks dll. So that will have to be transfered as well.

[nelsonbrodyk]

What I was getting it that if your DLL (that uses that bag o tricks DLL) is 'compiled' and sent elsewhere, it won't contain the bag o tricks dll. So that will have to be transfered as well.

Oh ok. Well I have a startup dll that runs and does a login etc. I notice in the bin of the startup the bag o tricks dll is there in debug mode. Also the module that is using it is there, so I am unsure what is happening. It looks like they are all in the startup dll's Debug bin folder.

[nelsonbrodyk]

Oh ok. Well I have a startup dll that runs and does a login etc. I notice in the bin of the startup the bag o tricks dll is there in debug mode. Also the module that is using it is there, so I am unsure what is happening. It looks like they are all in the startup dll's Debug bin folder.

Any ideas on what might be causing this?

[Plater]

Do you do any "reflection " stuff? Like System.Reflecti on? Or is the error coming from microsoft's own code do you think?

[nelsonbrodyk]

Do you do any "reflection " stuff? Like System.Reflecti on? Or is the error coming from microsoft's own code do you think?

Looks like it's coming from MS. It happens at compile time actually. We are using WPF, and I was just sent the error, and it seemed a little odd. I was shown that it's actually a compile error from WPF when trying to use the user control that extends the bag o tricks library. Is there something that has to be done to link this properly?

[nelsonbrodyk]

Anyone know how to do this with WPF?

[nelsonbrodyk]

hmmm..maybe I am referencing the third party user control wrong or something.

ComponentA : ThirdPartyUserC ontrol.



In dll B

WPF references Component A. Then the error is thrown at compile time.

[Plater]

So you have a DLL with a custom control that inherets from a control in another DLL
your.DLL has a class that inhereits from their.dll

And then you try to use your.dll with WPF it gives all those wierd compile errors?

Can you reference their.dll in your WPF project as well as your.dll?

[nelsonbrodyk]

So you have a DLL with a custom control that inherets from a control in another DLL
your.DLL has a class that inhereits from their.dll

And then you try to use your.dll with WPF it gives all those wierd compile errors?

Can you reference their.dll in your WPF project as well as your.dll?

That is correct.

I can try and reference it, and it would hopefully work. Is that a correct approach though? I figured that it would be nice that if we had a component wrapping there component, then there dll would be loaded when they tried to use ours.

[Plater]

That is correct.

I can try and reference it, and it would hopefully work. Is that a correct approach though? I figured that it would be nice that if we had a component wrapping there component, then there dll would be loaded when they tried to use ours.

I'm not to sure about how the wpf stuff works, but it might be because it's wpf it won't let you do that type of nesting of .DLLs.
If you create a non-WPF project, does it throw the same errors durring compile?