Quantcast
Channel: ClearScript
Viewing all articles
Browse latest Browse all 2297

New Post: How to add the ClearScript.V8 assemblies into GAC

$
0
0
Our normal recommendation for ASP.NET projects is to add the V8 and ClearScriptV8 assemblies as content files at
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?
It seems to me that this is not correct. It is suitable for WebMatrix sites, but not for ASP.NET web applications.
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!

Viewing all articles
Browse latest Browse all 2297

Latest Images

Trending Articles





Latest Images