[Mono-dev] Class built by mono throws FileNotFoundException when run on windows

[Alex J Lennon]

On 02/09/2015 16:32, Edward Ned Harvey (mono) wrote:
> I like the advice I'm getting from Alex and Robert.
>
> Alex, you said you're using
> 	Path.Combine(Directory.GetCurrentDirectory(), "foobar.dll")
>
> When I look around, it seems like this might be more reliable?
> 	Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "foobar.dll")

Glad it was of some use. Interesting point. Yes what you suggest seems
more correct for the .NET Framework, as the current directory may of
course change.

This is probably a result of me spending too much time over the years
with .NET Compact Framework / Windows CE which as I recall doesn't have
AppDomain.CurrentDomain BaseDirectory. Nevertheless it might be better
for me to grab the base location of the entry executable or something...
Thanks!

> I'm doing pretty well now, but not done yet - I have a base factory class, in a factory assembly, that returns instances of derivative classes from specific assemblies at runtime. The new question is: My main project only needs to reference the factory assembly, and in fact the derivative assemblies must also reference the factory assembly, because they derive from the factory assembly. So by default, the derivative assemblies dll files don't get copied to the build dir of the main project. I cannot reference the derivative assemblies from the factory assembly, because of circular reference. But I can reference the derivative assemblies from the main project, which seems to have the effect of copying their DLL's to the build dir, as desired.
>
> So is it safe for me to reference the derivative assemblies from the main project, even though the main project doesn't actually use anything from those assemblies? Or is it possible that the JIT compiler or something will someday be aggressive and cause crashing? (I think it's good - just want sanity check).

That's pretty much what I do.

fwiw I tend to have a MyApp.Core assembly with a bunch of interface
definitions and helpers in, then have console and/or UI projects
depending on that Core project and the BSP layers also depending on
Core, so I avoid circularity. Then console or UI projects reference Core
to build and I manually add in references to the output executable
projects to reference the BSP projects. This works for deployment even
though as you say the toolchain isn't aware of the dynamic loading
dependencies on the BSP projects.

> And is this a reliable way of getting the dll's to the target directory? Or will the compiler/linker/whatever sometimes exclude those dll's from the build process, because they're referenced but never used? (Again, I think it's good - just want sanity check).

Never seen it happen..  (but who knows...) The other thing I've had to
do sometimes when pushed, and it eliminates any potential compile/link
oddities, is to set library files into the main project as content to be
copied across, although less than ideal. Had to do this with SQLite
libraries for some reason that now escapes me.

Cheers,

Alex

ssarily represent those of the company.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20150902/9e88a24d/attachment.html>