Our normal recommendation for ASP.NET projects is to add the V8 and ClearScriptV8 assemblies as content files atIt seems to me that this is not correct. It is suitable for WebMatrix sites, but not for ASP.NET web applications.
the root of the web application, where the V8Proxy loader looks for them. We've used this scheme successfully in local, on-premises, and Azure deployments. Is it not practical for you?
If we understand correctly, this means that ClearScript.dll would have to be in the GAC as well, but the V8 and ClearScriptV8 assemblies could still be deployed as recommended above. Do you agree?OK
Yes, we can see how this might add some flexibility. We'll take a look at it. In the meantime, would it be possible to use AppDomainSetup.PrivateBinPath?Unfortunately, the
AppDomainSetup.PrivateBinPath
property cannot be changed for the current AppDomain
. Now I use the following decision:/// <summary>
/// Sets a path under the base directory where the assembly resolver should probe for private assemblies
/// </summary>
static V8JsEngine()
{
var currentDomain = AppDomain.CurrentDomain;
string binDirectoryPath = currentDomain.SetupInformation.PrivateBinPath;
if (string.IsNullOrEmpty(binDirectoryPath))
{
// `PrivateBinPath` property is empty in test scenarios, so
// need to use the `BaseDirectory` property
binDirectoryPath = currentDomain.BaseDirectory;
}
string assemblyDirectoryPath = Path.Combine(binDirectoryPath, ASSEMBLY_DIRECTORY_NAME);
if (!Directory.Exists(assemblyDirectoryPath) && HttpContext.Current != null)
{
// Fix for WebMatrix
string applicationRootPath = HttpContext.Current.Server.MapPath("~");
assemblyDirectoryPath = Path.Combine(applicationRootPath, ASSEMBLY_DIRECTORY_NAME);
}
currentDomain.AppendPrivatePath(assemblyDirectoryPath);
}
But the AppendPrivatePath
method is deprecated. I would like to have some solution at the level of ClearScript.V8.The ClearScript assembly is relatively small - currently about 260K - and uses late-binding to instantiate the underlying script engines. It can be deployed without the V8 assemblies if JScript/VBScript are sufficient. Why split it up?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).
Thanks!