Minimum Permission Requests?

Using VS2005 RC1, every time I create a project and add a reference to a DLL or control that resides on a different drive I get the following error either when attemting to run the program or when I first attempt to add the reference:

... Could not load file or assembly ... Failed to grant minimum permission requests. (Exception from HRESULT: 0x80131417)

I'm an administrator-equivalent user and have full create/modify/destroy on both my local drives and all network volumes.  This seems to be the case when I create the project on my local C: drive and attempt to add a reference to something on a network mapped drive and when I create the project on a network drive and attempt to add a reference to a DLL on my C:.   I've made sure the "Copy Local" setting is TRUE on the reference so I'm clueless as to what is triggering the exception.

I've google'd both the error code and text and haven't found anything on MSDN/MSDN2 or anywhere else that explains this (at least in any terms an old VB programmer such as myself can understand).  Can anyone enlighten me as to what the heck causes this, and more to the point, how it can be avoided in the first place

Thanks!



Answer this question

Minimum Permission Requests?

  • Tussh

    Richard,

    If you are trying to have a central repository for your application so that your users can get to it, then the best way I know of to do that is to use ClickOnce to deploy your application. This will also make it easy to get through the security issues your are seeing. Otherwise, you'll need to go to every machine you want to run your app and update their machine's configuration settings.

    ClickOnce deployment is very simple, and you can still use UNC network shares if you like.  The best introduction is probably already written up at: http://msdn2.microsoft.com/en-us/library/t71a733d

    and

    http://msdn2.microsoft.com/en-us/library/31kztyey

     



  • Emran Hussain

    That makes some sense, I guess....  The whole purpose of having it on the network drive is to maintain a central repository of the source code and to be sure it gets backed up nightly.  Sourcesafe is a wee bit of overkill as I'm the only programmer currently, and likely to be for quite some time.

    I've only been messing around with .NET for a few weeks now, so please forgive my ignorance when I ask, where do you enter the "<Assembly: RegistryPermissionAttribute(SecurityAction.RequestMinimum,  ViewAndModify:="HKEY_CURRENT_USER\Software")> " code   In my class that references the DLL or in the form that is the startup object

    p.s.   Yes, it runs great on my local.  Here's what I did:

    1. Copy the entire project folder to the network.
    2. Copy the DLL in question to the network project folder
    3. Load the project from the network folder.
    4. Remove the reference to the DLL on my C:
    5. Add the reference to the DLL in the network folder
    6. Run project

    It then blows up trying to create the form (form has "Private withevents MyObject as Class-that-refs-dll" as a form-level variable).


  • MartinKrieger

    You are my hero
  • RobARob

    This isn't a deployment issue, it's about being able to create a project on a network drive in the IDE.  The project is referencing a C DLL that resides on my local drive (and I assume the C DLL requires the MSVC runtime files).  The project when created on my local C: drive works just fine.  If you create the same project on a network drive, it will not be able to construct the form with the reference to the DLL file.  It throws the "failed to set minimum permissions" error.

    I try to keep any production project I create on our network drive so (1) I can access the project folder and documentation/resources from any terminal and (2) be sure it gets backed up nightly (which my local C: does not).  Currently I am unable to do this if I have to add a reference to the project.


  • CharlesY

    Please know that I don't claim to be an expert on this.

    I encountered this problem when I was writing a non-trivial project of about 4000 lines in Beta-II. I ran into this exact error and I think I understand it. But I also know that I've seen a problem that sounds like this quickly solved in this forum within the last couple of months. It was solved by editing an XML assembly file for an exectuable on shares or on the network. The fact that it run on your local machine and doesn't run on network share confirms my suspicions. I rather suspect that both solutions will work as long as System.Security.Policies has this as an argument and overall, it makes a lot of sense. There's more than one way to give the Policies class the information that it needs - either internally or externally.  Suppose there were users who were not admins. The code specifys what access permission that the developer says are needed. As far as security is concerned, it's one thing to be able to have code run a DLL on your system. It's very much a different question from a security point of view when that same code is on a network, where the code can be run on systems of different types with different users having different functions missions and permission. If code with this function did not exist, there would be frantic requests for how do I limit this on a network Microsoft has done the intelligent thing. They've required that the developer specify what is expected and system polcies has something concrete to test against when the image is run: 1.) the user's permissions and 2.) the protections of the object against 3.) what the developer specifies is required ie the minimum access levels for the code to function as specified.

    I believe you must put that line at the beginning of the class that references the dll. I'd suggest that because that's where I put my code that references the registry.

    Here's what the begginning of the class looks like:

    Imports System

    Imports System.Security

    Imports System.Security.Permissions

    Imports System.IO

    Imports System.Security.Policy

    Imports System.Collections

    Imports Microsoft.VisualBasic

    Imports Microsoft.Win32

    <Assembly: RegistryPermissionAttribute( _

    SecurityAction.RequestMinimum, ViewAndModify:="HKEY_CURRENT_USER\Software")>

    Public Class ClsSettings

    Inherits System.Windows.Forms.Form

    Protected sUserPath As String = vbNull

    Protected Status As Integer

    Dim RegKeySettings As Microsoft.Win32.RegistryKey

    I hope this helps.

    Renee



  • veronika

    Well, you're more of an expert than I am, obviously!  ;)

    I've tried the basic syntax for every permission from .EnvironemntPermission to .ZoneIdentityPermission with no success.  Granted, there are a few hundred parameters you can pass these functions and I don't know what 99% of them control.  The only difference in behavior I've seen is sometimes I'll get the standard unhandled exception dialog and sometimes I'll get the windows exception dialog box instead depending on which attribute I'm specifying.

    /shrug

    Thanks again for your suggestions, Renee.


  • tchyT

    Ok, here's what worked for me finally.  Not sure if this is the optimum or even a recommend solution but at least I can create and run projects on a network drive.  Make sure VS is closed then:

    Control Panel -> -Administrative Tools -> .Net Framework 2.0 configuration

    Expand the tree, click on Runtime Security Policy then select Adjust Zone Security from the browser window on the right side to get the Security Adjustment Wizard dialog. 

    On the wizard dialog, first choose for this machine or current user at your discretion, then on the next step select Local Intranet from the zone choices and set the slider bar below it to Full Trust.  Finish the wizard and edit away!

    We're a very small company and I'm the only programmer currently so I doubt this change will pose any great risk to my system ;)

    Thanks again everyone for your suggestions!


  • Hans Groeneveld

    Thanks for your reply, any and all insights are helpful :)

    Well, I'm not trying to modify anything in the registry, just call a DLL (which, to the best of my knowledge does not either).  

    I can create the project on my local drive, run it, works just fine.  Copy the entire project folder to a network drive, load it, run it and it gets the permission error in the constructor for the class that imports the DLL. 

    If the problem is the DLL is accessing something, how can I determine what permission to ask for since it's a 3rd party DLL

  • swemaniac

    I hear you Richard.

    You'd never want to do that in a large company because you'd really be opening your self up.

    As to whether it's a deployment problem or not,  it was an environment/security issue which deployment addresses.

    I'm glad you got it going. :)



  • hari.chinnan

    I know I can't enligten you. :)

    I've seen that error before in Beta-II when I was calling some new registry routines.

    There were a couple of things I needed to do to deal with it.

    To begin with. I needed to import system.secuity and system.security.permissions

    Then I searched all over the net and found my immediate answer on MSDN.

    For the registry I had to add this to my class that was dealing with this code.

    <Assembly: RegistryPermissionAttribute( _

    SecurityAction.RequestMinimum, ViewAndModify:="HKEY_CURRENT_USER\Software")>

    System.Security.Policies has a variety of calls... for the excution of portable code.

    I believe it can also be dealt with programattically. The reason that I believe this is that system.security.policy has members called: RegistryPermissionAttribute. The System.Security.Policy class has a member called codeaccesssecurityattribute.

    I wish you luck. I did run into this and survived because I really researched it. May you have the same good fortune. :)



  • Molon Labe

    OOOOOOOHHHHHH A network drive....we'll get back to that.

    I'm going to use the registry as a model for what I'm talking about. Like the code you want to execute - both are objects.


    I have hypothesis about the long term evolution of this code. I too have admin privs but that doesn't mean I'm the Goddess, just the admin.


    I think I see a trend in these routines. Although the registry can be ACL protected there really is little other granularity in protections. The old routines offer next to none. VS2005 demands more granularity. It's not blocking you whether you are the admin or not, it's blocking you through exception because the minimum level of required security has not been specified. Newer routines want more specificity and I think this is a good thing. It's possible that over time, older routines as interfaces will dissapear.

    System.security.policies doesn't just regulate access only to the registry. There are members in that class which correspond to many protected objects in windows such as the registry, and what code is executed and what files are accessed. This really is the policies facility we are discussing. We received the same error and if you look closely at the security specifier I posted, it has arguments having the same name as members of system.security.policy.

    But that may be neither here nor there. You're trying to run this off a share and on a network. No wonder it's watching what you execute. I don't know what your local configuration is, but is it practical to build this on your own machine Does it run on your machine

    I'm asking because I remember a post here, some months back where an assembly would not run on a network. I'm not on a network and didn't pay close attention but I defintiely remember that the fix was not to the code but to an xml file that described what the image could access and what it could. That post is in one of these two fora.

    Returning to security policies for just a moment. We had the same error from the same class while trying to do two things that look different, but to that class what we were doing isn't different. We were both accessing protected objects.

     how can I determine what permission to ask for since it's a 3rd party DLL


    Here's what I would do. I'd spend time with the object browser (don't you just love it :). I'd look at system.security.policies. I'd find the members relevant to the execution of portable code and I'd look at the arguments and find the arguments that related to my problem and try to make sense of the routines in terms of what I was trying to do. Ninety-nine percent of the time, that work for me. :)

  • Minimum Permission Requests?