none
Loading custom module from different folder RRS feed

  • Question

  • I have an application that compiles code on the fly and loads it into a class.

    That all works OK but I need to serialize the class to disc, to save it's staus (and that of the compiled code).

    Something like this:

    <Serializable()> _
    Class MyClass
    Dim Mod as Type
    Sub CompileCode()
     Dim Cp = New Compiler.CompilerParameters
     Dim File = "d:\myfolder\script.dll"
     Cp.OutputAssembly = File
     Cp.GenerateInMemory = True
     ...
     ...
     Mod = Result.CompiledAssembly.GetType("CodeModule")
    End Sub
    End Class

    When I serialize MyClass is only includes a reference to script.dll but not the full path so can't find script.dll to desrialize it.

    If I set myfolder = My.Application.Info.DirectoryPath that works, as the CLR looks there for modules in there but I can't compile that on a users PC, because program files is readonly.

    Can anyone offer a solution.

    Thanks


    Thursday, August 29, 2013 4:06 PM

Answers

  • You can do several different things depending upon what works best for your needs.

    1. Create a writable directory under your application's installation directory where "compiled" binaries will go.  Then add an entry to your config file to probe this directory as well.  ASP.NET and other codegen apps work similar to this.  You can technically put the directory anywhere.
    2. Handle the assembly Resolve event in the appdomain.  If it fails to load an assembly and it is one you compiled then you can look anywhere you want to actually find the file.  Provided you return back the loaded assembly the CLR doesn't care.

    In most cases I prefer to use (1) as you can set up the output directory during installation with the necessary write access.  If that isn't an option then a subfolder of the temp directory is the next best place.

    Michael Taylor
    http://msmvps.com/blogs/p3net

    Friday, August 30, 2013 7:36 PM
    Moderator
  • Readonly is different than a permissions issue.  Readonly is simply an attribute that can be changed. In Windows only files actually have this attribute.  Most programs will not allow you to save a file if it is read only.  The readonly option on folders is actually not for the folder itself but rather it allows you to set/clear the read only flag on all files in the folder (at the time it is set).  Each time you go back into the folder Windows resets it to an indeterminate state.

    Program Files is locked down by the OS (an NTFS permission on the directory).  You cannot write to files in this directory without admin privileges.  It is generally recommended that applications do not write to this directory as it is shared by all users.  Instead applications should store user-generated files in the user's writable directories or in the All Users directories.  If you do need to be able to write to Program Files then you need to change the NTFS permissions for your subfolder (or more correctly the subfolder in which you want users to have write access) during application installation which is generally run with admin privileges.  After installation it is too late to change without requiring the user to elevate their privileges.

    Michael Taylor
    http://msmvps.com/blogs/p3net

    Friday, August 30, 2013 8:44 PM
    Moderator

All replies

  • You can do several different things depending upon what works best for your needs.

    1. Create a writable directory under your application's installation directory where "compiled" binaries will go.  Then add an entry to your config file to probe this directory as well.  ASP.NET and other codegen apps work similar to this.  You can technically put the directory anywhere.
    2. Handle the assembly Resolve event in the appdomain.  If it fails to load an assembly and it is one you compiled then you can look anywhere you want to actually find the file.  Provided you return back the loaded assembly the CLR doesn't care.

    In most cases I prefer to use (1) as you can set up the output directory during installation with the necessary write access.  If that isn't an option then a subfolder of the temp directory is the next best place.

    Michael Taylor
    http://msmvps.com/blogs/p3net

    Friday, August 30, 2013 7:36 PM
    Moderator
  • Thanks very much Michael

    First method looks good. It would be more difficult any other way, as deserialize fails to load even the container class because it can't resolve script.dll.

    Do you know what controls readonly on program files and it's subfolders?

    When testing this on a clients PC(single user with admin account), it just wouldn't change readonly on the app folder. It asked for admin permission and appeared to change but readonly remained inderterminate in attributes.

    Friday, August 30, 2013 8:13 PM
  • Readonly is different than a permissions issue.  Readonly is simply an attribute that can be changed. In Windows only files actually have this attribute.  Most programs will not allow you to save a file if it is read only.  The readonly option on folders is actually not for the folder itself but rather it allows you to set/clear the read only flag on all files in the folder (at the time it is set).  Each time you go back into the folder Windows resets it to an indeterminate state.

    Program Files is locked down by the OS (an NTFS permission on the directory).  You cannot write to files in this directory without admin privileges.  It is generally recommended that applications do not write to this directory as it is shared by all users.  Instead applications should store user-generated files in the user's writable directories or in the All Users directories.  If you do need to be able to write to Program Files then you need to change the NTFS permissions for your subfolder (or more correctly the subfolder in which you want users to have write access) during application installation which is generally run with admin privileges.  After installation it is too late to change without requiring the user to elevate their privileges.

    Michael Taylor
    http://msmvps.com/blogs/p3net

    Friday, August 30, 2013 8:44 PM
    Moderator
  • Thanks Michael, that's clearer now.

    I have always used user folders for data, which is why I've never really looked at permissions for shared folders.

    Andrew

    Friday, August 30, 2013 9:18 PM