Hi Taritsyn,
We've received confirmation from others (e.g., here, here, and here) that it does work. The
Ah, that is indeed unfortunate. We'll investigate the assembly resolver option. To be honest, we have yet to understand the ramifications; e.g., the behavior when multiple resolvers are installed.
Yes, that's a good point. There are advantages to a minimal assembly count - deployment simplicity and startup performance - but they're diminished in ASP.NET environments. In any case, we probably won't do any major refactoring until we add support for more script engines.
Thanks again for your input!
It seems to me that this is not correct. It is suitable for WebMatrix sites, but not for ASP.NET web applications.
We've received confirmation from others (e.g., here, here, and here) that it does work. The
V8Proxy loader supports this setup by attempting to load the V8 and ClearScriptV8 assemblies from AppDomain.BaseDirectory.
Unfortunately, the AppDomainSetup.PrivateBinPath property cannot be changed for the current AppDomain.
Ah, that is indeed unfortunate. We'll investigate the assembly resolver option. To be honest, we have yet to understand the ramifications; e.g., the behavior when multiple resolvers are installed.
Problem is not the size of assembly. Simply divide to 3 assemblies, it would be more correct (from the point of view of creating NuGet packages). In future will be easier to add a new script engines (for example, Chakra or SpiderMonkey).
Yes, that's a good point. There are advantages to a minimal assembly count - deployment simplicity and startup performance - but they're diminished in ASP.NET environments. In any case, we probably won't do any major refactoring until we add support for more script engines.
Thanks again for your input!