I was trying to find a .NET equivalent to the “\/delayload” option that the linker has for unmanaged code. For the uninitiated, “\/delayload:someDLL.dll” changes the resulting .EXE\/.DLL so that someDLL.dll will not be loaded until the first time a function in it is called. It’s a handy option you can use so that you do not need to install someDLL.dll on computers where you know it’s not going to be needed.
\n
\nI wanted to find a way to the same thing with .NET assemblies. I have an Assembly1.DLL which will sometimes call into an Assembly2.DLL. But not always. And on computers where Assembly2.DLL will never be called, I don’t want to install it on the system at all.<\/p>\n
I couldn’t find any equivalent to “\/delayload:Assembly2.DLL”. I figured that it would be possible to achieve the desired effect using a proxy class with Then I thought, maybe I should go talk to our resident .NET expert, see if he knows of any existing code that does this. But the answer was worse than I could have imagined. In fact, “\/delayload” is the default behaviour of .NET!<\/p>\n That’s right… you don’t need “\/delayload” at all. By default, an assembly is not loaded at all until it’s time to run code from it. If you never run code in it, then the assembly need not even be present on the target system; nobody will ever look for it.<\/p>\n So all that work was for nothing.<\/p>\n I guess my approach still has the trivial advantage that you don’t even need the second assembly to be present even when compiling the first assembly. Whatever…<\/p>\n","protected":false},"excerpt":{"rendered":" I was trying to find a .NET equivalent to the “\/delayload” option that the linker has for unmanaged code. For the uninitiated, “\/delayload:someDLL.dll” changes the resulting .EXE\/.DLL so that someDLL.dll will not be loaded until the first time a function in it is called. It’s a handy option you can use so that you do […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[34,39,38,37,40,36],"class_list":["post-477","post","type-post","status-publish","format-standard","hentry","category-tech","tag-net","tag-assemblies","tag-assembly","tag-delay-load","tag-delayload","tag-demand-load"],"_links":{"self":[{"href":"https:\/\/www.thegatesofdawn.ca\/wordpress\/wp-json\/wp\/v2\/posts\/477"}],"collection":[{"href":"https:\/\/www.thegatesofdawn.ca\/wordpress\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.thegatesofdawn.ca\/wordpress\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.thegatesofdawn.ca\/wordpress\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.thegatesofdawn.ca\/wordpress\/wp-json\/wp\/v2\/comments?post=477"}],"version-history":[{"count":3,"href":"https:\/\/www.thegatesofdawn.ca\/wordpress\/wp-json\/wp\/v2\/posts\/477\/revisions"}],"predecessor-version":[{"id":634,"href":"https:\/\/www.thegatesofdawn.ca\/wordpress\/wp-json\/wp\/v2\/posts\/477\/revisions\/634"}],"wp:attachment":[{"href":"https:\/\/www.thegatesofdawn.ca\/wordpress\/wp-json\/wp\/v2\/media?parent=477"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.thegatesofdawn.ca\/wordpress\/wp-json\/wp\/v2\/categories?post=477"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.thegatesofdawn.ca\/wordpress\/wp-json\/wp\/v2\/tags?post=477"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}System.Assembly.Load<\/code> and System.Type.InvokeMember<\/code>. I couldn’t find any existing code on the Internet that did this, so I set about writing one. I called it DelayLoadProxy<\/code>. It was using “method intercept” techniques and Reflection and attributes, and was going to be all cool and nifty. Development was going along really well, for about a day and half.<\/p>\n