I've finally had time to read "DSLs in Boo" and have been really enjoying it. My head is popping with ideas.
I've trying out my own little sample project to see if I can apply any of the ideas to one of the projects I'm working on. I've written an MSBuild task to execute the DSL API so that we can codegen a series of files that are core to out application- but for some reason the second time I'd run the custom msbuild script which would call the custom task, it would fail with:
System.InvalidOperationException: Could not find the generated type for: C:\Temp\Scripts\TestScript.boo
at Rhino.DSL.AbstractLockable.WriteLock(CacheAction cacheAction)
at Rhino.DSL.DslFactory.RegisterBatchInCache(DslEngine engine, IEnumerable1 urls, Assembly compiledAssembly) at Rhino.DSL.DslFactory.<>c__DisplayClass41.b__3()
at Rhino.DSL.AbstractLockable.ReadLock(CacheAction cacheAction)
at Rhino.DSL.DslFactory.CreateInternal[TDslBase](ScriptNotFoundBehavior notFoundBehavior, String url, Object parameters)
at Rhino.DSL.DslFactory.Create[TDslBase](String url, Object parameters)
1 urls, Assembly compiledAssembly) at Rhino.DSL.DslFactory.<>c__DisplayClass4
After a bit of debugging I discovered that the RhinoDSL cache subsystem is using Assembly.Load which doesn't resolve any assembly references / dependencies. I've made a change to use Assembly.LoadFrom which uses Fusion to resolve any dependencies from the application path.
Would you take a look / let me know if it's ok - or if I've gotten the wrong end of the stick?
If it's ok - can you accept it and publish an updated NuGet Package?
Make the cache load the generated assembly using Assembly.LoadFrom so…
… that Fusion automatically tries to load any assembly references automatically.