views:

34

answers:

1

Situation

Assembly Adam.dll has a reference to assembly Frank.dll. Adam.dll is placed in a shared assemblies folder and is then referenced by my application as a binary reference.

If I run my application it will crash (and rightly so) because Frank.dll is missing.

If however, I place Frank.dll in the shared assemblies folder the .net compiler is smart enough to also move it to the bin folder and my application will run even though I have no direct reference in my application to Frank.dll

What I want

the .net compiler is obviously smart enough to realise my application needs Frank.dll. Is it possible to set a compiler option to have this flagged as an error at compile time?

Thanks,

A: 

I'm not sure what sort of "shared assemblies" folder you're talking about, but I wouldn't be too sure that Visual Studio is really "realising that your application needs Frank.dll" - I suspect it's more likely that it's copying all assemblies it finds there. What happens if you place an unrelated assembly there? If you could more details as to exactly where things are, what type of project you're creating, and how you're adding the reference to Adam.dll, that would help.

I don't know of any way of forcing dependent assemblies to be copied in all situations - because actually, it may not be necessary. Frank.dll may only be needed if you use certain features of Adam.dll, for example.

If some type in Adam that you were using exposed a type from Frank in its public API, then the compiler would give you an error - but obviously you don't want to add bits to the public API just for kicks.

While I know this isn't the answer you're looking for, I think you may just have to grin and bear it... does your code have enough complex dependencies that this is a genuine issue? Are you likely to waste enough time due to missing dependencies that it's worth trying to come up with a scheme to "fix" it? You could write a program which loaded your application's assembly, found all its dependencies, and then checked that they were all present - and recursed. It would presumably ignore dependencies already in the GAC. I'm just not sure it would be worth it.

Jon Skeet
"Shared assemblies" is just a normal folder that has some dll's in it that are not in the GAC, similar to a "lib" or "dlls" folder. Basically it is just a central place to put dll's the app relies on without GAC'ing them.
Nogusta
I checked whether it is copying unrelated dll's that are also in the folder and it is not. It is only copying dll's to the bin folder that are directly referenced by the app or indirectly referenced through another assembly. Any unrelated dll is not copied.
Nogusta
I'm not trying to force Frank.dll to be copied because that is what is already happening. You can try this out with a console app and 2 class libraries. Setup the Adam class library with a HeyAdamDoSomething method that calls HeyFrankDoSomething method in the Frank class library. In explorer create a "lib" folder and copy Adam.dll and Frank.dll to it. In the console app make a binary reference to Adam.dll and call HeyAdamDoSomething and compile. Look in the bin folder and both Frank.dll and Adam.dll will be in there even though the console app does not have a direct reference to Frank.dll
Nogusta
@Nogusta: I'm off to bed now, but I'll try it in the morning. Intriguing.
Jon Skeet
Now do a "clean solution" in the consolde app and remove Frank.dll from the "lib" folder. The console app will stil compile but will fail at runtime due to it missing Frank.dll in the bin folder
Nogusta
Yeh aussie time here. So basically what i want is in the scenario where Frank.dll is missing from the "lib" folder for the compiler to warn me rather than having a runtime error
Nogusta
@Nogusta: Hmm... right, I've reproduced it. I don't think there's anything that can be done about it though, to be honest... beyond lodging a feature request in Connect.
Jon Skeet
Bugger, thanks for looking into it
Nogusta