1
Vote

Configuration.LoadFromAssemblies fails on signed assemblies

description

From: Martin Calsyn
 
I have what I fear may be a fairly basic problem with signing/security or packaging, but the resolution is evading me.
 
namespace CVTWebControl
{
public class CVTControl
{
    public CVTControl( )
    {
        ScriptRuntimeSetup srs = Configuration.LoadFromAssemblies( Package.GetManifestAssemblies( ) );
        srs.HostType = typeof( BrowserScriptHost );
        ScriptRuntime runtime = new ScriptRuntime( srs );
        ScriptEngine cvtEng = runtime.GetEngine( "CVTLanguage" );
        ScriptSource source = cvtEng.CreateScriptSourceFromString( "render(){}", SourceCodeKind.Statements );
        ScriptScope scope = cvtEng.CreateScope( );
        Object ob = source.Execute( scope );
    }
}
}
 
The first-chance exception for each of the files I named above is :
 
System.IO.FileNotFoundException occurred
Message="Could not load file or assembly 'CVTWebTest, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified."
StackTrace:
   at System.Reflection.Assembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection)
   at System.Reflection.Assembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection)
 
Since our language dll fails to load for inspection, our language is not found and the rest of initialization fails.
 
All of the failing assemblies are strong-named and all of the assemblies and their dependencies appear in the xap. My working theory has been that my signing key or these assemblies are not trusted in some essential way, but I have not been able to noodle out the solution.
 
It may be interesting to note that if we recompile any of the Microsoft.Scripting dlls from source and signed with our snk, they too then fail to load, which is what is leading me to suspect signing/trust issues.
 
Any suggestions would be deeply appreciated.

comments

jimmysch wrote Feb 16, 2009 at 9:09 PM

From: John Messerly
Sent: 16 February 2009 19:52
To: Martin Calsyn; Jimmy Schementi
Subject: RE: Silverlight+antlr+DLR - Configuration.LoadFromAssemblies fails

Did Jimmy answered this already? He’s our resident expert, but it sounds to me like it might be a bug in the DLR.

You mention signing, but it appears to be trying to load CVTWebTest without a key (“PublicKeyToken=null”). Is the DLL actually signed? If so, the bug might be here in Microsoft.Scripting.Silverlight:
                result.Add(BrowserPAL.PAL.LoadAssembly(Path.GetFileNameWithoutExtension(part.Source)));
It doesn’t appear to allow signed DLLs.

What you might be able to do is remove the call to Package.GetManifestAssemblies, and instead load the assemblies yourself using the fully qualified name:

internal static IEnumerable<Assembly> LoadMyAssemblies() {
            // you could hardcode string names here too:
            yield return Assembly.Load(typeof(MyTypeFromDll1).Assembly.FullName);
            yield return Assembly.Load(typeof(MyTypeFromDll2).Assembly.FullName);
}

Hope that helps,
  • John

wrote Feb 16, 2009 at 9:09 PM

jimmysch wrote Feb 16, 2009 at 9:09 PM

From: John Messerly
Sent: Monday, February 16, 2009 1:22 PM
To: Martin Calsyn; Jimmy Schementi
Subject: RE: Silverlight+antlr+DLR - Configuration.LoadFromAssemblies fails

Awesome, glad it’s working .

It might be an intentional limitation of Package.GetManifestAssemblies that it can’t handle signed assemblies. It doesn’t seem like a very useful API though, given that limitation. I’m wondering if maybe it should call “LoadAssemblyFromPath” which would load the assemblies from the XAP. But that might be too slow if the DLL is already loaded (it would have to decompress it again, only for the CLR to discover it’s actually the same assembly).

In any case, I think you can use the more advanced “Configuration.TryParseFile” method which looks for a “languages.config” in the root of the XAP file. Offhand I don’t remember the format, but maybe one of the samples has it. That is the “more powerful” way of configuring the DLR, should allow you to specify the fully qualified assembly names.
  • John
From: Martin Calsyn
Sent: Monday, February 16, 2009 12:37 PM
To: John Messerly; Jimmy Schementi
Subject: RE: Silverlight+antlr+DLR - Configuration.LoadFromAssemblies fails

fyi - frobbing the signing didn't help anything, however implementing the LoadMyAssemblies iterator returning just the dll that contains our language seems to have gotten things working. I've verified that it is calling our lexer, parser and generators.

Thanks much for your help, though I would still be interested in knowing whether this is a bug or whether we were just applying the pattern incorrectly. Let me know if I can help with any diagnostics and I will happily do so.

--Martin

From: Martin Calsyn
Sent: 16 February 2009 20:01
To: John Messerly; Jimmy Schementi
Subject: RE: Silverlight+antlr+DLR - Configuration.LoadFromAssemblies fails

Thanks - no, I had not gotten any response so far.

Your theory here could explain why my compiled versions of Microsoft.Scripting dlls also fail, but the production ones do not - my versions were signed (simply because I presumed that they must HAVE to be signed as oppose to 'must not be') as are all of my CVT*dll assemblies.

The line you indicate, is in fact where things go south for us. I will try your suggestion and reply with the results

Thanks,
--Martin

wrote Feb 16, 2009 at 9:12 PM

wrote Feb 13, 2013 at 9:09 PM