Comments on: Dynamic Loading of .Net Assemblies http://lostechies.com/ryansvihla/2009/08/31/dynamic-loading-of-net-assemblies/ The small minded meanderings of the confused Mon, 15 Apr 2013 15:10:00 +0000 hourly 1 http://wordpress.org/?v=3.4.2 By: Ryan Svihla http://lostechies.com/ryansvihla/2009/08/31/dynamic-loading-of-net-assemblies/#comment-87 Ryan Svihla Tue, 08 Sep 2009 14:26:46 +0000 /blogs/rssvihla/archive/2009/08/31/dynamic-loading-of-net-assemblies.aspx#comment-87 @Arnis to answer to your second question, this is not preferable to assembly probing itself, its more like extending it. @Arnis to answer to your second question, this is not preferable to assembly probing itself, its more like extending it.

]]> By: Ryan Svihla http://lostechies.com/ryansvihla/2009/08/31/dynamic-loading-of-net-assemblies/#comment-86 Ryan Svihla Tue, 08 Sep 2009 14:25:22 +0000 /blogs/rssvihla/archive/2009/08/31/dynamic-loading-of-net-assemblies.aspx#comment-86 @Arnis This is for when the default assembly probing can't work easily. I've implemented this for configurable plugin architectures and most recently with a command line client for my BDD project SpecMaker. In all those cases the consumer of software was passing in locations to "search" for assemblies. SpecMaker.exe originally was relying on default assembly loading and this required it to be run where all assemblies needed were already placed next to it. This was a non-issue for most but some people didn't A) want to have to copy specmaker to their build directory or B) have a spread out build structure where different components are located in different side by side directories. thanks again for the feedback and I hope that answers your questions. @Arnis This is for when the default assembly probing can’t work easily. I’ve implemented this for configurable plugin architectures and most recently with a command line client for my BDD project SpecMaker.

In all those cases the consumer of software was passing in locations to “search” for assemblies. SpecMaker.exe originally was relying on default assembly loading and this required it to be run where all assemblies needed were already placed next to it. This was a non-issue for most but some people didn’t A) want to have to copy specmaker to their build directory or B) have a spread out build structure where different components are located in different side by side directories.

thanks again for the feedback and I hope that answers your questions.

]]> By: Arnis L. http://lostechies.com/ryansvihla/2009/08/31/dynamic-loading-of-net-assemblies/#comment-85 Arnis L. Tue, 08 Sep 2009 13:33:17 +0000 /blogs/rssvihla/archive/2009/08/31/dynamic-loading-of-net-assemblies.aspx#comment-85 I might sound stupid - but isn't this the same what assembly probing provides? If so - are there any difference why this approach is supposed to be preferable? I might sound stupid – but isn’t this the same what assembly probing provides? If so – are there any difference why this approach is supposed to be preferable?

]]> By: Richard Dingwall http://lostechies.com/ryansvihla/2009/08/31/dynamic-loading-of-net-assemblies/#comment-84 Richard Dingwall Tue, 01 Sep 2009 10:42:22 +0000 /blogs/rssvihla/archive/2009/08/31/dynamic-loading-of-net-assemblies.aspx#comment-84 This trick is also good for including assemblies as embedded resources in WPF apps, where ilmerge doesn't work. This trick is also good for including assemblies as embedded resources in WPF apps, where ilmerge doesn’t work.

]]>