How to load dll's during debug in VS2013

Question

I have some code

var aa = a();
b(aa);

While debugging, I set a breakpoint on the b() call. Then going to the immediate window, I'd like to be able to execute code from a DLL that is in my project but is not yet loaded. Say I want a new Boo and call Foo(). The code is in the namespace Baz in dll Spongle.dll.

When I type

>> new Baz.Boo().Foo(aa)

I get the error: The type or namespace name 'Baz' is not valid in this scope.

If I change my code such that my Boo is already loaded it works fine.

new Boo(); // dummy to ensure loading
var aa = a();
b(aa);

Is it possible to load the dll from the immediate window during debug so I can call my code despite it being loaded (yet)?. I could use the new Boo() as a static initializer of my application main class, but then I have problems during unit testing as it won't necesarily involve the class with that static initializer.

Elnaelnar

The namespace is Baz and is already included in my question unfortunately. – Elnaelnar

There must be something you have overlooked, as I've never had the problem you are describing. Can you show the complete definition of your Boo class? – Wigley

@Nathan A:Take any DLL that you use in your application, debug a unit test not using that dll, set a breakpoint and try instantiating from that dll in the immediate window – Elnaelnar

Why is the DLL not yet loaded, and what causes it to be loaded? – Essive

@John Because no code in the test is using it as given in the question – Elnaelnar

I can't believe I didn't know that - after 14 years! weblog.west-wind.com/posts/2012/Nov/03/…. – Essive

Answer 1

Although heavy, you can of course use reflection to load the assembly for that test.

The following would not work:

var obj = new Newtonsoft.Json.Linq.JObject();

since the assembly isn't yet present. However, if I explicitly load it first via reflection and an absolute path to my bin, I can instantiate the object just fine.

var assembly = System.Reflection.Assembly.LoadFile("C:\\AbsolutePath\\bin\\Debug\\Newtonsoft.Json.dll");
var obj = new Newtonsoft.Json.Linq.JObject();

The reason for this necessity from the Immediate Window is that as your application (or unit test boostrapped application in this case) loads, it looks for references throughout the code and loads the required assemblies to satisfy your needs. In your case, you don't have an explicit reference to the assembly in your code, so it isn't loaded. The immediate window has no context and, as such, you have to explicitly load it.

To programatically reference potential assemblies to load, you can use the bin directory of the loaded assembly. This allows you to pull the absolute path at runtime.

var filePath = new Uri(this.GetType().Assembly.CodeBase).LocalPath;
var bin = System.IO.Path.GetDirectoryName(filePath);
var assembly = System.Reflection.Assembly.LoadFile(bin + "\\Newtonsoft.Json.dll");

Roller

Is there a variable in VS pointing to the build path or nuget where nuget packages reside? such that one can say System.Reflection.Assembly.LoadFile($nugetpath +"Newtonsoft.Json.dll") ? – Elnaelnar

@CarloV.Dango Updated my answer. You wouldn't necessarily want to reference the nuget package source (particularly considering that the present structure is expected to change in vNext). That said, you can pull the assemblies from the bin directory of the entrance point of the application. – Roller