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.
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
