locked
Assembly.LoadFile failing in .NET 4 3.5 to .NET 4 System.NotSupportedException, System.TypeLoadException RRS feed

  • Question

  • I'm stuck on this .NET 4 security changes. 
    My application creates it's own AppDomain and loads assemblies with Assembly.LoadFile(string).
    The assemblies are all on disk on the local machine.

    When I moved my application to .NET 4 I started getting the following error: 
    • An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information. at    at System.Reflection.RuntimeAssembly.nLoadFile(String path, Evidence evidence)

    • One solution is the add the following <configuration>

       <runtime>
          <loadFromRemoteSources enabled="true"/>
       </runtime>
    </configuration>

     but that solution would have to be added to each client machine so I'm looking for a code fix. I started to have a look at Sandboxing my appdomain with http://blogs.msdn.com/b/shawnfa/archive/2005/08/08/449050.aspx but now I've started to get the following:

     



    Error 1 The "CompilerTask" task failed unexpectedly.
    System.TypeLoadException: Inheritance security rules violated by type: 'CompilerTask'. Derived types must either match the security accessibility of the base type or be less accessible.
       at System.Reflection.RuntimeAssembly.GetType(RuntimeAssembly assembly, String name, Boolean throwOnError, Boolean ignoreCase, ObjectHandleOnStack type)
       at System.Reflection.RuntimeAssembly.GetType(String name, Boolean throwOnError, Boolean ignoreCase)
       at System.Reflection.Assembly.GetType(String name)
       at System.AppDomainInitializerInfo.Unwrap()
       at System.AppDomain.Setup(Object arg)
       at System.AppDomain.nCreateDomain(String friendlyName, AppDomainSetup setup, Evidence providedSecurityInfo, Evidence creatorsSecurityInfo, IntPtr parentSecurityDescriptor)
       at System.AppDomainManager.CreateDomainHelper(String friendlyName, Evidence securityInfo, AppDomainSetup appDomainInfo)
       at System.AppDomainManager.CreateDomain(String friendlyName, Evidence securityInfo, AppDomainSetup appDomainInfo)
       at System.AppDomain.InternalCreateDomain(String friendlyName, Evidence securityInfo, AppDomainSetup info)
       at System.AppDomain.CreateDomain(String friendlyName, Evidence securityInfo, AppDomainSetup info)
       at System.AppDomain.CreateDomain(String friendlyName, Evidence securityInfo, AppDomainSetup info, PermissionSet grantSet, StrongName[] fullTrustAssemblies)
       at CompilerTask.Execute() in C:\\src-VS2010\CompilerTask.cs:line 122
       at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
       at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask, Boolean& taskResult)


    http://learnerps-dotnet.blogspot.com
    Thursday, July 1, 2010 3:26 PM

Answers

  • I think this has to do with you specifically acknowledging that the assembly is to run under unrestricted permissions (full trust).

    Thus, it sounds like you have found an acceptable workaround.  Great!

     

    • Marked as answer by SamAgain Thursday, July 8, 2010 6:47 AM
    Wednesday, July 7, 2010 12:00 AM
  • unfortunately not. My application is a hosted by VisualStudio, msbuild. I would have to change the msbuild config file.

     

    I have found a code solution here

    http://blogs.msdn.com/b/shawnfa/archive/2009/06/08/more-implicit-uses-of-cas-policy-loadfromremotesources.aspx

    adding a PErmissionSet to my appDomain 

    PermissionSet trustedLoadFromRemoteSourceGrantSet = new PermissionSet(PermissionState.Unrestricted);

    I still don't know why it's required.

    This particular assembly is being loaded from the local machine using Assembly.LoadFile. the path for this assembly in particular is C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PublicAssemblies

    the AppDomain has it's base set to C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\PublicAssemblies

     

     

     

     

    AppDomainSetup appSetup = new AppDomainSetup();
    
    applicationBase = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
    
                appSetup.ApplicationBase = applicationBase;
    
                appSetup.AppDomainInitializer = new AppDomainInitializer(initAppDomain);
    
    
    
     PermissionSet trustedLoadFromRemoteSourceGrantSet = new PermissionSet(PermissionState.Unrestricted);//this is the fix
    
                AppDomain ad = AppDomain.CreateDomain("Compiling",
    
                               null,
    
                               appSetup,
    
                               trustedLoadFromRemoteSourceGrantSet);
    
    
    

     

     


    http://learnerps-dotnet.blogspot.com
    • Marked as answer by SamAgain Thursday, July 8, 2010 6:47 AM
    Friday, July 2, 2010 9:47 AM

All replies

  • >  but that solution would have to be added to each client machine

    Maybe I'm missing something, but can't you just put add an Application Configuration File (app.config) to your project and put that configuration in it?  Release the programname.exe.config that Visual Studio produces in the output folder along with your application.

    Since you are switching to .NET 4, you presumably are rebuilding and rereleasing your application anyways.

    Of course, be sure that you have fully read the KB article and understand what you are doing.

     

    • Proposed as answer by SamAgain Friday, July 2, 2010 2:19 AM
    • Unproposed as answer by learnerplates Friday, July 2, 2010 9:47 AM
    Friday, July 2, 2010 1:41 AM
  • Hi,

       I am not quite sure about your scenario, but why would "that solution have to be added to each client machine"?


    Please mark the right answer at right time.
    Thanks,
    Sam
    Friday, July 2, 2010 2:21 AM
  • unfortunately not. My application is a hosted by VisualStudio, msbuild. I would have to change the msbuild config file.

     

    I have found a code solution here

    http://blogs.msdn.com/b/shawnfa/archive/2009/06/08/more-implicit-uses-of-cas-policy-loadfromremotesources.aspx

    adding a PErmissionSet to my appDomain 

    PermissionSet trustedLoadFromRemoteSourceGrantSet = new PermissionSet(PermissionState.Unrestricted);

    I still don't know why it's required.

    This particular assembly is being loaded from the local machine using Assembly.LoadFile. the path for this assembly in particular is C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PublicAssemblies

    the AppDomain has it's base set to C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\PublicAssemblies

     

     

     

     

    AppDomainSetup appSetup = new AppDomainSetup();
    
    applicationBase = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
    
                appSetup.ApplicationBase = applicationBase;
    
                appSetup.AppDomainInitializer = new AppDomainInitializer(initAppDomain);
    
    
    
     PermissionSet trustedLoadFromRemoteSourceGrantSet = new PermissionSet(PermissionState.Unrestricted);//this is the fix
    
                AppDomain ad = AppDomain.CreateDomain("Compiling",
    
                               null,
    
                               appSetup,
    
                               trustedLoadFromRemoteSourceGrantSet);
    
    
    

     

     


    http://learnerps-dotnet.blogspot.com
    • Marked as answer by SamAgain Thursday, July 8, 2010 6:47 AM
    Friday, July 2, 2010 9:47 AM
  • I think this has to do with you specifically acknowledging that the assembly is to run under unrestricted permissions (full trust).

    Thus, it sounds like you have found an acceptable workaround.  Great!

     

    • Marked as answer by SamAgain Thursday, July 8, 2010 6:47 AM
    Wednesday, July 7, 2010 12:00 AM