Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / New Users / November 2004

Tip: Looking for answers? Try searching our database.

Execution permission cannot be acquired, when using Assembly.LoadFrom

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Thomas Jespersen - 15 Nov 2004 09:07 GMT
Hello

I have a project where I dynamically loads a DLL form the Internet (using
the Assembly.LoadFrom), which in turns loads another referenced DLL. Both
assemblies needs write access to the local Hard Drive. This actually works
on most machines, but on a clean Windows XP installation with only .NET 1.0
I get the "Execution permission cannot be acquired" error, when the second
assembly try's to write to the disk. Why is that, do I need to something
different in .NET 1.0 to grant full trust to the second assembly?

Note: In both situations I'm logged on with a user with Administrator

The Main of the .exe which is installed on the users hard drive looks
something like this (I removed a lot of the code to make it illustrate my
problem):

Public Class Main
   Public Shared Sub Main()
       Dim myAssembly As System.Reflection.Assembly

       'This should make sure that the first assembly has full trust (this
works)
       AppDomain.CurrentDomain.Evidence.AddHost(New
System.Security.Policy.Zone(System.Security.SecurityZone.MyComputer))
       myAssembly =
System.Reflection.Assembly.LoadFrom("http://mysite.com/myAssembly.dll",
AppDomain.CurrentDomain.Evidence)

       Dim updaterClass As Type = myAssembly .GetType("MyAssembly.MyClass")
       Dim myMethodInfo As System.Reflection.MethodInfo =
updaterClass.GetMethod("MyMethod")

       myMethodInfo.Invoke(updaterClass, New Object() {"c:\unziped",
{"c:\myzipfile.zip"})
   End Sub
End Class

The first assembly (myAssembly.dll) has a direct VS.NET project reference to
the second assembly, but because both assemblies are located physically on
the Internet myAssembly calls Assembly.LoadFrom to indicate where the to
find the second assembly. Something like this:

Imports ICSharpCode.SharpZipLib
Namespace MyAssembly
   Class MyClass
       Public Sub MyMethod(ByVal destinitaionFolder As String, ByVal
zipedFilenameAs String)
           Dim sharpZipLibAssembly As System.Reflection.Assembly

           'This should reuses the trust of the current domain, which
already has full trust
           sharpZipLibAssembly =
System.Reflection.Assembly.LoadFrom("http://mysite.com/ICSharpCode.SharpZipLib.dll,
AppDomain.CurrentDomain.Evidence)

           'SharpZipLib has a direct reference, so the above line is only
to indicate where the assembly is located
           Dim zipOutputStream As ZipOutputStream

           zipOutputStream = New
ZipOutputStream(File.Create(FileSystemUtil.BuildPath(destinitaionFolder,
zipedFilename)))
           ....
       End Sub
   End Class
End Namespace

Any suggestions?

Thomas
Richard Blewett [DevelopMentor] - 15 Nov 2004 10:40 GMT
Your first assembly load is loading the assembly from a remote codebase, however I think that that remote location will be checked automatically by teh assembly resolver for the dependent assembly ICSharpCode.SharpZipLib. So the ICSharpCode.SharpZipLib.dll assembly is being loaded implicitly already. Unfortuneately this is loading and resolving the types as soon as a method containing one of them gets JITed.

You second assembly loadfrom is loading the same assembly a second time into the LoadFrom context and is being ignored in terms of type resolution and therefore security. The problem with 1.0 is that teh default permission set for the internet (1.0 SP1) is Nothing. So therefore Execution permission isn't being assigned to the library.

Does changing your LoadFrom to a Load and putting the first reference to a ICSharpCode.SharpZipLib component into a method that won't have been JITed yet work?

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

  Hello

I have a project where I dynamically loads a DLL form the Internet (using
the Assembly.LoadFrom), which in turns loads another referenced DLL. Both
assemblies needs write access to the local Hard Drive. This actually works
on most machines, but on a clean Windows XP installation with only .NET 1.0
I get the "Execution permission cannot be acquired" error, when the second
assembly try's to write to the disk. Why is that, do I need to something
different in .NET 1.0 to grant full trust to the second assembly?
Thomas Jespersen - 17 Nov 2004 14:15 GMT
Hello Richard

Bingo. I got it working thanks to you!

I moved the
Assembly.LoadFrom("http://mysite.com/ICSharpCode.SharpZipLib.dll) to the
first constructor of my first assembly, and made sure that there all
references to the SharpZipLip was removed form this class (so the JIT wasn't
invoked).

The Assembly.Load (instead of LoadFrom) didn't work, because Assembly.Load
is not supported in Net 1.0.

BTW: I had a temporary workaround... I used ILLink (Microsoft (R) .NET
Framework IL Linker,  Version 1.0) to combine the first and second assembly
into one single assembly. But I didn't like that I had to do that every time
before deploying.

Thanks a lot. Guys like you makes newsgroups the best place to solve
problems.

Thomas

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.