all groups > dotnet security > may 2005 >
Local C# network application developed using VS .Net 1. While do some local network users able to Trust The Assembly via the Control Panel .Net Framework wizard while others can not because of “security policyâ€. Why? 2. Why do I receive the following error message when I try to open my ADONet dll from the network within my local .Net application? “The application attempted to perform an operation not allowed by the security policy. The operation required the Security Exception. To grant theis application the required permission please contact your system administrator….†What do I or, my IT person, need to do to change security policy?
Nicole Thank You Nicole. If you or, anybody else, has anything to add please feel free to add any additional comments. This problem has been around my neck for weeks. I'll inform IT of your message Steve [quoted text, click to view] "Nicole Calinoiu" wrote: > "Steve B." <SteveB@discussions.microsoft.com> wrote in message > news:C86F5BC6-CB25-4DE9-965E-7FE50E8D986A@microsoft.com... > > Local C# network application developed using VS .Net > > > > 1. While do some local network users able to Trust The Assembly via the > > Control Panel .Net Framework wizard while others can not because of > > "security > > policy". Why? > > Probably because some of them are administrators and are adjusting the > assembly permissions at the machine level, whereas others are non-admins and > are only allowed to attempt to adjust the permissions at the user level. > The "trust an assembly" wizard will usually give the "due to your existing > security policy..." result you mentioned when run at the user level. (I'm > unaware of any conditions under which a user-level run of the wizard would > succeed.) > > BTW, it is possible for non-admins to restrict assembly permissions via > other tools that modify the user-level CAS policy. However, under normal > circumstances, low-privilege users cannot grant increase assembly > permissions beyond those granted at the enterprise and machine levels. > > > > 2. Why do I receive the following error message when I try to open my > > ADONet dll from the network within my local .Net application? > > > > "The application attempted to perform an operation not allowed by the > > security policy. The operation required the Security Exception. To grant > > theis application the required permission please contact your system > > administrator.." > > > > What do I or, my IT person, need to do to change security policy? > > See http://blogs.msdn.com/shawnfa/archive/2003/06/20/57023.aspx for > instructions on how to modify the CAS policy for this scenario. See > http://msdn.microsoft.com/library/en-us/cpguide/html/cpcondeployingsecuritypolicy.asp > for some deployment options. > >
[quoted text, click to view] "Steve B." <SteveB@discussions.microsoft.com> wrote in message
news:C86F5BC6-CB25-4DE9-965E-7FE50E8D986A@microsoft.com...
> Local C# network application developed using VS .Net
>
> 1. While do some local network users able to Trust The Assembly via the
> Control Panel .Net Framework wizard while others can not because of
> "security
> policy". Why?
Probably because some of them are administrators and are adjusting the assembly permissions at the machine level, whereas others are non-admins and are only allowed to attempt to adjust the permissions at the user level. The "trust an assembly" wizard will usually give the "due to your existing security policy..." result you mentioned when run at the user level. (I'm unaware of any conditions under which a user-level run of the wizard would succeed.) BTW, it is possible for non-admins to restrict assembly permissions via other tools that modify the user-level CAS policy. However, under normal circumstances, low-privilege users cannot grant increase assembly permissions beyond those granted at the enterprise and machine levels. [quoted text, click to view] > 2. Why do I receive the following error message when I try to open my
> ADONet dll from the network within my local .Net application?
>
> "The application attempted to perform an operation not allowed by the
> security policy. The operation required the Security Exception. To grant
> theis application the required permission please contact your system
> administrator.."
>
> What do I or, my IT person, need to do to change security policy?
See http://blogs.msdn.com/shawnfa/archive/2003/06/20/57023.aspx for instructions on how to modify the CAS policy for this scenario. See http://msdn.microsoft.com/library/en-us/cpguide/html/cpcondeployingsecuritypolicy.asp for some deployment options.
Nicole Are there instructions on how trust a directorory and the files within it. I have separate strong names for each project within the file VS solution. Should I have one strong name for the whole solution? [quoted text, click to view] "Nicole Calinoiu" wrote: > "Steve B." <SteveB@discussions.microsoft.com> wrote in message > news:C86F5BC6-CB25-4DE9-965E-7FE50E8D986A@microsoft.com... > > Local C# network application developed using VS .Net > > > > 1. While do some local network users able to Trust The Assembly via the > > Control Panel .Net Framework wizard while others can not because of > > "security > > policy". Why? > > Probably because some of them are administrators and are adjusting the > assembly permissions at the machine level, whereas others are non-admins and > are only allowed to attempt to adjust the permissions at the user level. > The "trust an assembly" wizard will usually give the "due to your existing > security policy..." result you mentioned when run at the user level. (I'm > unaware of any conditions under which a user-level run of the wizard would > succeed.) > > BTW, it is possible for non-admins to restrict assembly permissions via > other tools that modify the user-level CAS policy. However, under normal > circumstances, low-privilege users cannot grant increase assembly > permissions beyond those granted at the enterprise and machine levels. > > > > 2. Why do I receive the following error message when I try to open my > > ADONet dll from the network within my local .Net application? > > > > "The application attempted to perform an operation not allowed by the > > security policy. The operation required the Security Exception. To grant > > theis application the required permission please contact your system > > administrator.." > > > > What do I or, my IT person, need to do to change security policy? > > See http://blogs.msdn.com/shawnfa/archive/2003/06/20/57023.aspx for > instructions on how to modify the CAS policy for this scenario. See > http://msdn.microsoft.com/library/en-us/cpguide/html/cpcondeployingsecuritypolicy.asp > for some deployment options. > >
[quoted text, click to view] "Steve B." <SteveB@discussions.microsoft.com> wrote in message
news:A40F8CFA-F5E0-45B1-AC61-98B31FFECA70@microsoft.com...
> Nicole
>
> Are there instructions on how trust a directorory and the files within it.
You would simply need to use a URL membership condition rather than a strong name membership condition when you create the new code group. However, getting the URL right can be a bit tricky since it must match the URL used by the CLR to load the assemblies. [quoted text, click to view] > I have separate strong names for each project within the file VS solution.
> Should I have one strong name for the whole solution?
By definition, each assembly would have a distinct strong name, so I suspect you're actually concerned about different signing keys. It is rather unusual to use a different signing key for each project within a solution. The "typical" schemes are to use a single signing key for all assemblies released by an organization, or for all assemblies released in a given product group. Since all projects within your solution presumably form part of the same product, they would usually be signed with the same key under either scheme. [quoted text, click to view] > > > > "Nicole Calinoiu" wrote: > >> "Steve B." <SteveB@discussions.microsoft.com> wrote in message >> news:C86F5BC6-CB25-4DE9-965E-7FE50E8D986A@microsoft.com... >> > Local C# network application developed using VS .Net >> > >> > 1. While do some local network users able to Trust The Assembly via >> > the >> > Control Panel .Net Framework wizard while others can not because of >> > "security >> > policy". Why? >> >> Probably because some of them are administrators and are adjusting the >> assembly permissions at the machine level, whereas others are non-admins >> and >> are only allowed to attempt to adjust the permissions at the user level. >> The "trust an assembly" wizard will usually give the "due to your >> existing >> security policy..." result you mentioned when run at the user level. >> (I'm >> unaware of any conditions under which a user-level run of the wizard >> would >> succeed.) >> >> BTW, it is possible for non-admins to restrict assembly permissions via >> other tools that modify the user-level CAS policy. However, under normal >> circumstances, low-privilege users cannot grant increase assembly >> permissions beyond those granted at the enterprise and machine levels. >> >> >> > 2. Why do I receive the following error message when I try to open my >> > ADONet dll from the network within my local .Net application? >> > >> > "The application attempted to perform an operation not allowed by the >> > security policy. The operation required the Security Exception. To >> > grant >> > theis application the required permission please contact your system >> > administrator.." >> > >> > What do I or, my IT person, need to do to change security policy? >> >> See http://blogs.msdn.com/shawnfa/archive/2003/06/20/57023.aspx for >> instructions on how to modify the CAS policy for this scenario. See >> http://msdn.microsoft.com/library/en-us/cpguide/html/cpcondeployingsecuritypolicy.asp >> for some deployment options. >> >> >>
Nicole, Sorry to to keep asking these questions, however, this is the most success I've had in solving this problem so far. After following the earlier post instructions the program opened up fine on my machine but when I went to another user's machine I recieved the following message: Imported failed. The assmbly does not appear to be vailid ... strong name What wrong? The following is a typical configuration I have in each Visual Studio project (file name(s): AssemblyInfo.cs) within the solution: [assembly: AssemblyDelaySign(false)] [assembly: AssemblyKeyFile(@"C:\BusinessInformationSoftware\ADONetLibrary\obj\adoNetLibrary.snk")] [assembly: AssemblyKeyName("")] Steve [quoted text, click to view] "Nicole Calinoiu" wrote: > > "Steve B." <SteveB@discussions.microsoft.com> wrote in message > news:A40F8CFA-F5E0-45B1-AC61-98B31FFECA70@microsoft.com... > > Nicole > > > > Are there instructions on how trust a directorory and the files within it. > > You would simply need to use a URL membership condition rather than a strong > name membership condition when you create the new code group. However, > getting the URL right can be a bit tricky since it must match the URL used > by the CLR to load the assemblies. > > > > I have separate strong names for each project within the file VS solution. > > Should I have one strong name for the whole solution? > > By definition, each assembly would have a distinct strong name, so I suspect > you're actually concerned about different signing keys. It is rather > unusual to use a different signing key for each project within a solution. > The "typical" schemes are to use a single signing key for all assemblies > released by an organization, or for all assemblies released in a given > product group. Since all projects within your solution presumably form part > of the same product, they would usually be signed with the same key under > either scheme. > > > > > > > > > "Nicole Calinoiu" wrote: > > > >> "Steve B." <SteveB@discussions.microsoft.com> wrote in message > >> news:C86F5BC6-CB25-4DE9-965E-7FE50E8D986A@microsoft.com... > >> > Local C# network application developed using VS .Net > >> > > >> > 1. While do some local network users able to Trust The Assembly via > >> > the > >> > Control Panel .Net Framework wizard while others can not because of > >> > "security > >> > policy". Why? > >> > >> Probably because some of them are administrators and are adjusting the > >> assembly permissions at the machine level, whereas others are non-admins > >> and > >> are only allowed to attempt to adjust the permissions at the user level. > >> The "trust an assembly" wizard will usually give the "due to your > >> existing > >> security policy..." result you mentioned when run at the user level. > >> (I'm > >> unaware of any conditions under which a user-level run of the wizard > >> would > >> succeed.) > >> > >> BTW, it is possible for non-admins to restrict assembly permissions via > >> other tools that modify the user-level CAS policy. However, under normal > >> circumstances, low-privilege users cannot grant increase assembly > >> permissions beyond those granted at the enterprise and machine levels. > >> > >> > >> > 2. Why do I receive the following error message when I try to open my > >> > ADONet dll from the network within my local .Net application? > >> > > >> > "The application attempted to perform an operation not allowed by the > >> > security policy. The operation required the Security Exception. To > >> > grant > >> > theis application the required permission please contact your system > >> > administrator.." > >> > > >> > What do I or, my IT person, need to do to change security policy? > >> > >> See http://blogs.msdn.com/shawnfa/archive/2003/06/20/57023.aspx for > >> instructions on how to modify the CAS policy for this scenario. See > >> http://msdn.microsoft.com/library/en-us/cpguide/html/cpcondeployingsecuritypolicy.asp > >> for some deployment options. > >> > >> > >> > >
Nicole, Trying to provide you as may elements of my environment as possible. Please - don't assume I know what I'm doing -->When do you see this message? 1. When I try to do the policy changes NOT when the application runs. --> Could you please provide repro steps? 2. The policy change steps are the same steps as I did on my machine and are the the same as the earlier web site you referenced (Machine-all_code-new..). The error message occurs after selecting Strong Name from comboBox and after clicking the Import button and when I iidentify the application dll on the shared Pub drive -->Exact message 3. OK Message: "The Import failed. The assembly does not appear to be valid." -->Correct versions of your compiled assemblies 4. My VS compiling procedures: I Debug compile locally on my machine then send a Release "updated" compiled version of the application to my local network (\\serverName\Pub\Business...). Then. I went to a typical users machine and tried to set it up the Machine Code Group same way I did on my machine. My machine works fine form Pub -->Are any of the assemblies delay signed? 5. No assemblies are delay signed Note: The VS solution has one exe file project and two dll projects. One dll is a GUI for a Access dB and the other is a Library for the dB. The excute file DOES RUN on the users machine because I earlier ran the Trust Assembly wizard and identified the exe file however the exe file calls the dB GUI and that fails to open. The Trust Assembly wizard will not trust the dB dll's Steve [quoted text, click to view] "Nicole Calinoiu" wrote: > "Steve B." <SteveB@discussions.microsoft.com> wrote in message > news:F89770A4-781D-481D-B11B-0D1962B42E07@microsoft.com... > > Nicole, > > > > Sorry to to keep asking these questions, however, this is the most success > > I've had in solving this problem so far. > > > > After following the earlier post instructions the program opened up fine > > on > > my machine but when I went to another user's machine I recieved the > > following > > message: > > > > Imported failed. The assmbly does not appear to be vailid ... strong name > > When do you see this message? When attempting to apply the policy changes > or when attempting to run your application? If the former, could you please > provide repro steps? Also, is there any chance you might be able to provide > the exact message? > > > > > What wrong? > > > > The following is a typical configuration I have in each Visual Studio > > project (file name(s): AssemblyInfo.cs) within the solution: > > > > [assembly: AssemblyDelaySign(false)] > > [assembly: > > AssemblyKeyFile(@"C:\BusinessInformationSoftware\ADONetLibrary\obj\adoNetLibrary.snk")] > > [assembly: AssemblyKeyName("")] > > Are any of the assemblies delay signed? i.e.: Do any have the attribute > [assembly: AssemblyDelaySign(true)]? Also, are you sure that the other > machine has the correct versions of your compiled assemblies? > > > > > > > Steve > > > > "Nicole Calinoiu" wrote: > > > >> > >> "Steve B." <SteveB@discussions.microsoft.com> wrote in message > >> news:A40F8CFA-F5E0-45B1-AC61-98B31FFECA70@microsoft.com... > >> > Nicole > >> > > >> > Are there instructions on how trust a directorory and the files within > >> > it. > >> > >> You would simply need to use a URL membership condition rather than a > >> strong > >> name membership condition when you create the new code group. However, > >> getting the URL right can be a bit tricky since it must match the URL > >> used > >> by the CLR to load the assemblies. > >> > >> > >> > I have separate strong names for each project within the file VS > >> > solution. > >> > Should I have one strong name for the whole solution? > >> > >> By definition, each assembly would have a distinct strong name, so I > >> suspect > >> you're actually concerned about different signing keys. It is rather > >> unusual to use a different signing key for each project within a > >> solution. > >> The "typical" schemes are to use a single signing key for all assemblies > >> released by an organization, or for all assemblies released in a given > >> product group. Since all projects within your solution presumably form > >> part > >> of the same product, they would usually be signed with the same key under > >> either scheme. > >> > >> > > >> > > >> > > >> > "Nicole Calinoiu" wrote: > >> > > >> >> "Steve B." <SteveB@discussions.microsoft.com> wrote in message > >> >> news:C86F5BC6-CB25-4DE9-965E-7FE50E8D986A@microsoft.com... > >> >> > Local C# network application developed using VS .Net > >> >> > > >> >> > 1. While do some local network users able to Trust The Assembly via > >> >> > the > >> >> > Control Panel .Net Framework wizard while others can not because of > >> >> > "security > >> >> > policy". Why? > >> >> > >> >> Probably because some of them are administrators and are adjusting the > >> >> assembly permissions at the machine level, whereas others are > >> >> non-admins > >> >> and > >> >> are only allowed to attempt to adjust the permissions at the user > >> >> level. > >> >> The "trust an assembly" wizard will usually give the "due to your > >> >> existing > >> >> security policy..." result you mentioned when run at the user level. > >> >> (I'm > >> >> unaware of any conditions under which a user-level run of the wizard > >> >> would > >> >> succeed.) > >> >> > >> >> BTW, it is possible for non-admins to restrict assembly permissions > >> >> via > >> >> other tools that modify the user-level CAS policy. However, under > >> >> normal > >> >> circumstances, low-privilege users cannot grant increase assembly > >> >> permissions beyond those granted at the enterprise and machine levels. > >> >> > >> >> > >> >> > 2. Why do I receive the following error message when I try to open > >> >> > my > >> >> > ADONet dll from the network within my local .Net application? > >> >> > > >> >> > "The application attempted to perform an operation not allowed by > >> >> > the > >> >> > security policy. The operation required the Security Exception. To > >> >> > grant > >> >> > theis application the required permission please contact your system > >> >> > administrator.." > >> >> > > >> >> > What do I or, my IT person, need to do to change security policy? > >> >> > >> >> See http://blogs.msdn.com/shawnfa/archive/2003/06/20/57023.aspx for > >> >> instructions on how to modify the CAS policy for this scenario. See > >> >> http://msdn.microsoft.com/library/en-us/cpguide/html/cpcondeployingsecuritypolicy.asp > >> >> for some deployment options. > >> >> > >> >> > >> >> > >> > >> > >> > >
[quoted text, click to view] "Steve B." <SteveB@discussions.microsoft.com> wrote in message
news:F89770A4-781D-481D-B11B-0D1962B42E07@microsoft.com...
> Nicole,
>
> Sorry to to keep asking these questions, however, this is the most success
> I've had in solving this problem so far.
>
> After following the earlier post instructions the program opened up fine
> on
> my machine but when I went to another user's machine I recieved the
> following
> message:
>
> Imported failed. The assmbly does not appear to be vailid ... strong name
When do you see this message? When attempting to apply the policy changes or when attempting to run your application? If the former, could you please provide repro steps? Also, is there any chance you might be able to provide the exact message? [quoted text, click to view] >
> What wrong?
>
> The following is a typical configuration I have in each Visual Studio
> project (file name(s): AssemblyInfo.cs) within the solution:
>
> [assembly: AssemblyDelaySign(false)]
> [assembly:
> AssemblyKeyFile(@"C:\BusinessInformationSoftware\ADONetLibrary\obj\adoNetLibrary.snk")]
> [assembly: AssemblyKeyName("")]
Are any of the assemblies delay signed? i.e.: Do any have the attribute [assembly: AssemblyDelaySign(true)]? Also, are you sure that the other machine has the correct versions of your compiled assemblies? [quoted text, click to view] > > Steve > > "Nicole Calinoiu" wrote: > >> >> "Steve B." <SteveB@discussions.microsoft.com> wrote in message >> news:A40F8CFA-F5E0-45B1-AC61-98B31FFECA70@microsoft.com... >> > Nicole >> > >> > Are there instructions on how trust a directorory and the files within >> > it. >> >> You would simply need to use a URL membership condition rather than a >> strong >> name membership condition when you create the new code group. However, >> getting the URL right can be a bit tricky since it must match the URL >> used >> by the CLR to load the assemblies. >> >> >> > I have separate strong names for each project within the file VS >> > solution. >> > Should I have one strong name for the whole solution? >> >> By definition, each assembly would have a distinct strong name, so I >> suspect >> you're actually concerned about different signing keys. It is rather >> unusual to use a different signing key for each project within a >> solution. >> The "typical" schemes are to use a single signing key for all assemblies >> released by an organization, or for all assemblies released in a given >> product group. Since all projects within your solution presumably form >> part >> of the same product, they would usually be signed with the same key under >> either scheme. >> >> > >> > >> > >> > "Nicole Calinoiu" wrote: >> > >> >> "Steve B." <SteveB@discussions.microsoft.com> wrote in message >> >> news:C86F5BC6-CB25-4DE9-965E-7FE50E8D986A@microsoft.com... >> >> > Local C# network application developed using VS .Net >> >> > >> >> > 1. While do some local network users able to Trust The Assembly via >> >> > the >> >> > Control Panel .Net Framework wizard while others can not because of >> >> > "security >> >> > policy". Why? >> >> >> >> Probably because some of them are administrators and are adjusting the >> >> assembly permissions at the machine level, whereas others are >> >> non-admins >> >> and >> >> are only allowed to attempt to adjust the permissions at the user >> >> level. >> >> The "trust an assembly" wizard will usually give the "due to your >> >> existing >> >> security policy..." result you mentioned when run at the user level. >> >> (I'm >> >> unaware of any conditions under which a user-level run of the wizard >> >> would >> >> succeed.) >> >> >> >> BTW, it is possible for non-admins to restrict assembly permissions >> >> via >> >> other tools that modify the user-level CAS policy. However, under >> >> normal >> >> circumstances, low-privilege users cannot grant increase assembly >> >> permissions beyond those granted at the enterprise and machine levels. >> >> >> >> >> >> > 2. Why do I receive the following error message when I try to open >> >> > my >> >> > ADONet dll from the network within my local .Net application? >> >> > >> >> > "The application attempted to perform an operation not allowed by >> >> > the >> >> > security policy. The operation required the Security Exception. To >> >> > grant >> >> > theis application the required permission please contact your system >> >> > administrator.." >> >> > >> >> > What do I or, my IT person, need to do to change security policy? >> >> >> >> See http://blogs.msdn.com/shawnfa/archive/2003/06/20/57023.aspx for >> >> instructions on how to modify the CAS policy for this scenario. See >> >> http://msdn.microsoft.com/library/en-us/cpguide/html/cpcondeployingsecuritypolicy.asp >> >> for some deployment options. >> >> >> >> >> >> >> >> >>
I was thinking (just ideas): - Why does the trust assembly wizard give an error message (" Unable to load [path to dll]") when I identify the dll but it works for the execute file - What about the location(s) of the assembly file key (path) to my harddrive - should it be the network? (see earlier post for C: path) - Why is the policy change work on my ("the developer's") machine? - Should I test the policy change on more then one user? - Do I need to refence the assembly file or key in the VS project or the program file? - Do I need to register the key (regsvces,exe??) Steve [quoted text, click to view] "Steve B." wrote:
> Nicole,
>
> Trying to provide you as may elements of my environment as possible. Please
> - don't assume I know what I'm doing
>
> -->When do you see this message?
> 1. When I try to do the policy changes NOT when the application runs.
>
> --> Could you please provide repro steps?
> 2. The policy change steps are the same steps as I did on my machine and
> are the the same as the earlier web site you referenced
> (Machine-all_code-new..). The error message occurs after selecting Strong
> Name from comboBox and after clicking the Import button and when I iidentify
> the application dll on the shared Pub drive
>
> -->Exact message
> 3. OK Message: "The Import failed. The assembly does not appear to be
> valid."
>
> -->Correct versions of your compiled assemblies
> 4. My VS compiling procedures: I Debug compile locally on my machine then
> send a Release "updated" compiled version of the application to my local
> network (\\serverName\Pub\Business...). Then. I went to a typical users
> machine and tried to set it up the Machine Code Group same way I did on my
> machine. My machine works fine form Pub
>
> -->Are any of the assemblies delay signed?
> 5. No assemblies are delay signed
>
> Note: The VS solution has one exe file project and two dll projects. One
> dll is a GUI for a Access dB and the other is a Library for the dB. The
> excute file DOES RUN on the users machine because I earlier ran the Trust
> Assembly wizard and identified the exe file however the exe file calls the dB
> GUI and that fails to open. The Trust Assembly wizard will not trust the dB
> dll's
>
> Steve
>
> "Nicole Calinoiu" wrote:
>
> > "Steve B." <SteveB@discussions.microsoft.com> wrote in message
> > news:F89770A4-781D-481D-B11B-0D1962B42E07@microsoft.com...
> > > Nicole,
> > >
> > > Sorry to to keep asking these questions, however, this is the most success
> > > I've had in solving this problem so far.
> > >
> > > After following the earlier post instructions the program opened up fine
> > > on
> > > my machine but when I went to another user's machine I recieved the
> > > following
> > > message:
> > >
> > > Imported failed. The assmbly does not appear to be vailid ... strong name
> >
> > When do you see this message? When attempting to apply the policy changes
> > or when attempting to run your application? If the former, could you please
> > provide repro steps? Also, is there any chance you might be able to provide
> > the exact message?
> >
> > >
> > > What wrong?
> > >
> > > The following is a typical configuration I have in each Visual Studio
> > > project (file name(s): AssemblyInfo.cs) within the solution:
> > >
> > > [assembly: AssemblyDelaySign(false)]
> > > [assembly:
> > > AssemblyKeyFile(@"C:\BusinessInformationSoftware\ADONetLibrary\obj\adoNetLibrary.snk")]
> > > [assembly: AssemblyKeyName("")]
> >
> > Are any of the assemblies delay signed? i.e.: Do any have the attribute
> > [assembly: AssemblyDelaySign(true)]? Also, are you sure that the other
> > machine has the correct versions of your compiled assemblies?
> >
> >
> >
> > >
> > > Steve
> > >
> > > "Nicole Calinoiu" wrote:
> > >
> > >>
> > >> "Steve B." <SteveB@discussions.microsoft.com> wrote in message
> > >> news:A40F8CFA-F5E0-45B1-AC61-98B31FFECA70@microsoft.com...
> > >> > Nicole
> > >> >
> > >> > Are there instructions on how trust a directorory and the files within
> > >> > it.
> > >>
> > >> You would simply need to use a URL membership condition rather than a
> > >> strong
> > >> name membership condition when you create the new code group. However,
> > >> getting the URL right can be a bit tricky since it must match the URL
> > >> used
> > >> by the CLR to load the assemblies.
> > >>
> > >>
> > >> > I have separate strong names for each project within the file VS
> > >> > solution.
> > >> > Should I have one strong name for the whole solution?
> > >>
> > >> By definition, each assembly would have a distinct strong name, so I
> > >> suspect
> > >> you're actually concerned about different signing keys. It is rather
> > >> unusual to use a different signing key for each project within a
> > >> solution.
> > >> The "typical" schemes are to use a single signing key for all assemblies
> > >> released by an organization, or for all assemblies released in a given
> > >> product group. Since all projects within your solution presumably form
> > >> part
> > >> of the same product, they would usually be signed with the same key under
> > >> either scheme.
> > >>
> > >> >
> > >> >
> > >> >
> > >> > "Nicole Calinoiu" wrote:
> > >> >
> > >> >> "Steve B." <SteveB@discussions.microsoft.com> wrote in message
> > >> >> news:C86F5BC6-CB25-4DE9-965E-7FE50E8D986A@microsoft.com...
> > >> >> > Local C# network application developed using VS .Net
> > >> >> >
> > >> >> > 1. While do some local network users able to Trust The Assembly via
> > >> >> > the
> > >> >> > Control Panel .Net Framework wizard while others can not because of
> > >> >> > "security
> > >> >> > policy". Why?
> > >> >>
> > >> >> Probably because some of them are administrators and are adjusting the
> > >> >> assembly permissions at the machine level, whereas others are
> > >> >> non-admins
> > >> >> and
> > >> >> are only allowed to attempt to adjust the permissions at the user
> > >> >> level.
> > >> >> The "trust an assembly" wizard will usually give the "due to your
> > >> >> existing
> > >> >> security policy..." result you mentioned when run at the user level.
> > >> >> (I'm
> > >> >> unaware of any conditions under which a user-level run of the wizard
> > >> >> would
> > >> >> succeed.)
> > >> >>
> > >> >> BTW, it is possible for non-admins to restrict assembly permissions
> > >> >> via
> > >> >> other tools that modify the user-level CAS policy. However, under
> > >> >> normal
> > >> >> circumstances, low-privilege users cannot grant increase assembly
> > >> >> permissions beyond those granted at the enterprise and machine levels.
> > >> >>
> > >> >>
> > >> >> > 2. Why do I receive the following error message when I try to open
> > >> >> > my
> > >> >> > ADONet dll from the network within my local .Net application?
Nicole, In a previous post (last one on 5/24/05) I responded to your questions - just hope you saw it that's all. I get the same message for both dll's. The files which the dll's are developed from are in separate "VS project" directories on my hard drive. When I Release compile the exe and dll' are in one directory on the network. The exe and the dll's all use different key names and locations. Your earlier post seemed to recommend one location and one key for the whole VS solution. I going to correct that to one key and one location in the exe directory on my hard drive if you think that's good practice, however, I would think that would only be an issue when the application runs and not an issue for policy changes. What's my next step/your recommendation? (recreate keys?) Are there obvious machine configurations (not fruitless) I can check? How can I raise this up a step (note: I work for non-profit group) Steve [quoted text, click to view] "Nicole Calinoiu" wrote: > "Steve B." <SteveB@discussions.microsoft.com> wrote in message > news:F7803F8D-061B-4245-AC72-0607D655475F@microsoft.com... > >I was thinking (just ideas): > > - Why does the trust assembly wizard give an error message (" Unable to > > load [path to dll]") when I identify the dll but it works for the execute > > file > > If this works for the EXE, then perhaps there's some problem with the DLL > itself. Do you get the exact same result for both DLLs? Are the DLLs > located in the exact same directory as the EXE? > > > > - What about the location(s) of the assembly file key (path) to my > > harddrive > > Not relevant. The key file is not used anymore after the assemblies are > signed at compile-time. > > > - should it be the network? (see earlier post for C: path) > > Absolutely not. In fact, the key you use to sign your production assemblies > probably shouldn't even be stored on your development machine. See > http://msdn.microsoft.com/library/en-us/dnnetsec/html/strongNames.asp for a > discussion of key storage techniques. > > > > - Why is the policy change work on my ("the developer's") machine? > > Most likely because there's something different about your machine's > configuration. There are many, many possibilities, and trying to guess is > likely to be fruitless. > > > - Should I test the policy change on more then one user? > > Eventually, yes. However, it would be a good idea to get it working on at > least one user machine before starting to muck about with others. > > > > - Do I need to refence the assembly file or key in the VS project or the > > program file? > > No. The key file is never needed at runtime. > > > - Do I need to register the key (regsvces,exe??) > > No. Again, the key is only used to sign the assembly at compile time. It's > never needed again unless you need to re-sign a delay-signed assembly, which > you don't since you're not using delay signing. > > > > > > Steve > > > > "Steve B." wrote: > > > >> Nicole, > >> > >> Trying to provide you as may elements of my environment as possible. > >> Please > >> - don't assume I know what I'm doing > >> > >> -->When do you see this message? > >> 1. When I try to do the policy changes NOT when the application runs. > >> > >> --> Could you please provide repro steps? > >> 2. The policy change steps are the same steps as I did on my machine and > >> are the the same as the earlier web site you referenced > >> (Machine-all_code-new..). The error message occurs after selecting > >> Strong > >> Name from comboBox and after clicking the Import button and when I > >> iidentify > >> the application dll on the shared Pub drive > >> > >> -->Exact message > >> 3. OK Message: "The Import failed. The assembly does not appear to be > >> valid." > >> > >> -->Correct versions of your compiled assemblies > >> 4. My VS compiling procedures: I Debug compile locally on my machine > >> then > >> send a Release "updated" compiled version of the application to my local > >> network (\\serverName\Pub\Business...). Then. I went to a typical users > >> machine and tried to set it up the Machine Code Group same way I did on > >> my > >> machine. My machine works fine form Pub > >> > >> -->Are any of the assemblies delay signed? > >> 5. No assemblies are delay signed > >> > >> Note: The VS solution has one exe file project and two dll projects. > >> One > >> dll is a GUI for a Access dB and the other is a Library for the dB. The > >> excute file DOES RUN on the users machine because I earlier ran the Trust > >> Assembly wizard and identified the exe file however the exe file calls > >> the dB > >> GUI and that fails to open. The Trust Assembly wizard will not trust the > >> dB > >> dll's > >> > >> Steve > >> > >> "Nicole Calinoiu" wrote: > >> > >> > "Steve B." <SteveB@discussions.microsoft.com> wrote in message > >> > news:F89770A4-781D-481D-B11B-0D1962B42E07@microsoft.com... > >> > > Nicole, > >> > > > >> > > Sorry to to keep asking these questions, however, this is the most > >> > > success > >> > > I've had in solving this problem so far. > >> > > > >> > > After following the earlier post instructions the program opened up > >> > > fine > >> > > on > >> > > my machine but when I went to another user's machine I recieved the > >> > > following > >> > > message: > >> > > > >> > > Imported failed. The assmbly does not appear to be vailid ... strong > >> > > name > >> > > >> > When do you see this message? When attempting to apply the policy > >> > changes > >> > or when attempting to run your application? If the former, could you > >> > please > >> > provide repro steps? Also, is there any chance you might be able to > >> > provide > >> > the exact message? > >> > > >> > > > >> > > What wrong? > >> > > > >> > > The following is a typical configuration I have in each Visual Studio > >> > > project (file name(s): AssemblyInfo.cs) within the solution: > >> > > > >> > > [assembly: AssemblyDelaySign(false)] > >> > > [assembly: > >> > > AssemblyKeyFile(@"C:\BusinessInformationSoftware\ADONetLibrary\obj\adoNetLibrary.snk")] > >> > > [assembly: AssemblyKeyName("")] > >> > > >> > Are any of the assemblies delay signed? i.e.: Do any have the > >> > attribute > >> > [assembly: AssemblyDelaySign(true)]? Also, are you sure that the other > >> > machine has the correct versions of your compiled assemblies? > >> > > >> > > >> > > >> > > > >> > > Steve > >> > > > >> > > "Nicole Calinoiu" wrote: > >> > > > >> > >> > >> > >> "Steve B." <SteveB@discussions.microsoft.com> wrote in message > >> > >> news:A40F8CFA-F5E0-45B1-AC61-98B31FFECA70@microsoft.com... > >> > >> > Nicole > >> > >> > > >> > >> > Are there instructions on how trust a directorory and the files > >> > >> > within > >> > >> > it. > >> > >>
[quoted text, click to view] "Steve B." <SteveB@discussions.microsoft.com> wrote in message
news:F7803F8D-061B-4245-AC72-0607D655475F@microsoft.com...
>I was thinking (just ideas):
> - Why does the trust assembly wizard give an error message (" Unable to
> load [path to dll]") when I identify the dll but it works for the execute
> file
If this works for the EXE, then perhaps there's some problem with the DLL itself. Do you get the exact same result for both DLLs? Are the DLLs located in the exact same directory as the EXE? [quoted text, click to view] > - What about the location(s) of the assembly file key (path) to my
> harddrive
Not relevant. The key file is not used anymore after the assemblies are signed at compile-time. [quoted text, click to view] > - should it be the network? (see earlier post for C: path)
Absolutely not. In fact, the key you use to sign your production assemblies probably shouldn't even be stored on your development machine. See http://msdn.microsoft.com/library/en-us/dnnetsec/html/strongNames.asp for a discussion of key storage techniques. [quoted text, click to view] > - Why is the policy change work on my ("the developer's") machine?
Most likely because there's something different about your machine's configuration. There are many, many possibilities, and trying to guess is likely to be fruitless. [quoted text, click to view] > - Should I test the policy change on more then one user?
Eventually, yes. However, it would be a good idea to get it working on at least one user machine before starting to muck about with others. [quoted text, click to view] > - Do I need to refence the assembly file or key in the VS project or the
> program file?
No. The key file is never needed at runtime. [quoted text, click to view] > - Do I need to register the key (regsvces,exe??)
No. Again, the key is only used to sign the assembly at compile time. It's never needed again unless you need to re-sign a delay-signed assembly, which you don't since you're not using delay signing. [quoted text, click to view] >
> Steve
>
> "Steve B." wrote:
>
>> Nicole,
>>
>> Trying to provide you as may elements of my environment as possible.
>> Please
>> - don't assume I know what I'm doing
>>
>> -->When do you see this message?
>> 1. When I try to do the policy changes NOT when the application runs.
>>
>> --> Could you please provide repro steps?
>> 2. The policy change steps are the same steps as I did on my machine and
>> are the the same as the earlier web site you referenced
>> (Machine-all_code-new..). The error message occurs after selecting
>> Strong
>> Name from comboBox and after clicking the Import button and when I
>> iidentify
>> the application dll on the shared Pub drive
>>
>> -->Exact message
>> 3. OK Message: "The Import failed. The assembly does not appear to be
>> valid."
>>
>> -->Correct versions of your compiled assemblies
>> 4. My VS compiling procedures: I Debug compile locally on my machine
>> then
>> send a Release "updated" compiled version of the application to my local
>> network (\\serverName\Pub\Business...). Then. I went to a typical users
>> machine and tried to set it up the Machine Code Group same way I did on
>> my
>> machine. My machine works fine form Pub
>>
>> -->Are any of the assemblies delay signed?
>> 5. No assemblies are delay signed
>>
>> Note: The VS solution has one exe file project and two dll projects.
>> One
>> dll is a GUI for a Access dB and the other is a Library for the dB. The
>> excute file DOES RUN on the users machine because I earlier ran the Trust
>> Assembly wizard and identified the exe file however the exe file calls
>> the dB
>> GUI and that fails to open. The Trust Assembly wizard will not trust the
>> dB
>> dll's
>>
>> Steve
>>
>> "Nicole Calinoiu" wrote:
>>
>> > "Steve B." <SteveB@discussions.microsoft.com> wrote in message
>> > news:F89770A4-781D-481D-B11B-0D1962B42E07@microsoft.com...
>> > > Nicole,
>> > >
>> > > Sorry to to keep asking these questions, however, this is the most
>> > > success
>> > > I've had in solving this problem so far.
>> > >
>> > > After following the earlier post instructions the program opened up
>> > > fine
>> > > on
>> > > my machine but when I went to another user's machine I recieved the
>> > > following
>> > > message:
>> > >
>> > > Imported failed. The assmbly does not appear to be vailid ... strong
>> > > name
>> >
>> > When do you see this message? When attempting to apply the policy
>> > changes
>> > or when attempting to run your application? If the former, could you
>> > please
>> > provide repro steps? Also, is there any chance you might be able to
>> > provide
>> > the exact message?
>> >
>> > >
>> > > What wrong?
>> > >
>> > > The following is a typical configuration I have in each Visual Studio
>> > > project (file name(s): AssemblyInfo.cs) within the solution:
>> > >
>> > > [assembly: AssemblyDelaySign(false)]
>> > > [assembly:
>> > > AssemblyKeyFile(@"C:\BusinessInformationSoftware\ADONetLibrary\obj\adoNetLibrary.snk")]
>> > > [assembly: AssemblyKeyName("")]
>> >
>> > Are any of the assemblies delay signed? i.e.: Do any have the
>> > attribute
>> > [assembly: AssemblyDelaySign(true)]? Also, are you sure that the other
>> > machine has the correct versions of your compiled assemblies?
>> >
>> >
>> >
>> > >
>> > > Steve
>> > >
>> > > "Nicole Calinoiu" wrote:
>> > >
>> > >>
>> > >> "Steve B." <SteveB@discussions.microsoft.com> wrote in message
>> > >> news:A40F8CFA-F5E0-45B1-AC61-98B31FFECA70@microsoft.com...
>> > >> > Nicole
>> > >> >
>> > >> > Are there instructions on how trust a directorory and the files
>> > >> > within
>> > >> > it.
>> > >>
>> > >> You would simply need to use a URL membership condition rather than
>> > >> a
>> > >> strong
>> > >> name membership condition when you create the new code group.
>> > >> However,
>> > >> getting the URL right can be a bit tricky since it must match the
>> > >> URL
>> > >> used
>> > >> by the CLR to load the assemblies.
>> > >>
>> > >>
>> > >> > I have separate strong names for each project within the file VS
>> > >> > solution.
>> > >> > Should I have one strong name for the whole solution?
>> > >>
>> > >> By definition, each assembly would have a distinct strong name, so I
>> > >> suspect
>> > >> you're actually concerned about different signing keys. It is
>> > >> rather
>> > >> unusual to use a different signing key for each project within a
>> > >> solution.
>> > >> The "typical" schemes are to use a single signing key for all
>> > >> assemblies
>> > >> released by an organization, or for all assemblies released in a
>> > >> given
>> > >> product group. Since all projects within your solution presumably
>> > >> form
>> > >> part
>> > >> of the same product, they would usually be signed with the same key
>> > >> under
>> > >> either scheme.
>> > >>
>> > >> >
>> > >> >
>> > >> >
>> > >> > "Nicole Calinoiu" wrote:
>> > >> >
[quoted text, click to view] "Steve B." <SteveB@discussions.microsoft.com> wrote in message
news:23BE341C-E989-4BE1-9033-F7733697C534@microsoft.com...
<snip>
> What's my next step/your recommendation? (recreate keys?)
As long as the keys are valid, they can't be causing the problem. If you want to simplify things and use a new key that's shared across the three projects, go ahead, but this won't address any potential client configuration issues. [quoted text, click to view] > Are there obvious machine configurations (not fruitless) I can check?
There are too many candidates for blind troubleshooting. Since things seem to be in a bit of a muddle, I'd recommend taking a step back and checking if things are really working as you seem to think on your development machine before going looking for problems on the other clients. If you're up for this, here are the steps I'd take: 1. Back up your compiled assemblies (the EXE and both DLLs) and your CAS policy files (or even safer, then entire <windows>\Microsoft.NET\Framework\<version>\CONFIG directory) to some location off your machine. 2. Delete all local debug and release mode compiled copies of your EXE and DLLs, including any copies in the GAC. 3. Reset your CAS policy. (See the "To reset all policy levels" topic at http://msdn.microsoft.com/library/en-us/cptools/html/cpconNETFrameworkAdministrationToolMscorcfgmsc.asp if you're not sure how to do this.) 4. Recompile your three assemblies in release mode. 5. Replace the assemblies in your network distribution folder with the newly compiled copies, then deleted the local copies from your development machine. If any copies ended up the GAC (for example, due to a build event), delete these as well. 6. Attempt to run the EXE from the network folder. Do you see the expected SecurityException? 7. Attempt to create new code group(s) based on strong name membership condition(s) for trusting the assemblies, loading them from the network folder.. Do you encounter any problems? [quoted text, click to view] > How can I raise this up a step (note: I work for non-profit group)
The various support options available from Microsoft are listed at http://support.microsoft.com/. I suppose that some might cost less for a non-profit, but I have no personal experience in this area. [quoted text, click to view] > > Steve > > > "Nicole Calinoiu" wrote: > >> "Steve B." <SteveB@discussions.microsoft.com> wrote in message >> news:F7803F8D-061B-4245-AC72-0607D655475F@microsoft.com... >> >I was thinking (just ideas): >> > - Why does the trust assembly wizard give an error message (" Unable >> > to >> > load [path to dll]") when I identify the dll but it works for the >> > execute >> > file >> >> If this works for the EXE, then perhaps there's some problem with the DLL >> itself. Do you get the exact same result for both DLLs? Are the DLLs >> located in the exact same directory as the EXE? >> >> >> > - What about the location(s) of the assembly file key (path) to my >> > harddrive >> >> Not relevant. The key file is not used anymore after the assemblies are >> signed at compile-time. >> >> > - should it be the network? (see earlier post for C: path) >> >> Absolutely not. In fact, the key you use to sign your production >> assemblies >> probably shouldn't even be stored on your development machine. See >> http://msdn.microsoft.com/library/en-us/dnnetsec/html/strongNames.asp for >> a >> discussion of key storage techniques. >> >> >> > - Why is the policy change work on my ("the developer's") machine? >> >> Most likely because there's something different about your machine's >> configuration. There are many, many possibilities, and trying to guess >> is >> likely to be fruitless. >> >> > - Should I test the policy change on more then one user? >> >> Eventually, yes. However, it would be a good idea to get it working on >> at >> least one user machine before starting to muck about with others. >> >> >> > - Do I need to refence the assembly file or key in the VS project or >> > the >> > program file? >> >> No. The key file is never needed at runtime. >> >> > - Do I need to register the key (regsvces,exe??) >> >> No. Again, the key is only used to sign the assembly at compile time. >> It's >> never needed again unless you need to re-sign a delay-signed assembly, >> which >> you don't since you're not using delay signing. >> >> >> > >> > Steve >> > >> > "Steve B." wrote: >> > >> >> Nicole, >> >> >> >> Trying to provide you as may elements of my environment as possible. >> >> Please >> >> - don't assume I know what I'm doing >> >> >> >> -->When do you see this message? >> >> 1. When I try to do the policy changes NOT when the application runs. >> >> >> >> --> Could you please provide repro steps? >> >> 2. The policy change steps are the same steps as I did on my machine >> >> and >> >> are the the same as the earlier web site you referenced >> >> (Machine-all_code-new..). The error message occurs after selecting >> >> Strong >> >> Name from comboBox and after clicking the Import button and when I >> >> iidentify >> >> the application dll on the shared Pub drive >> >> >> >> -->Exact message >> >> 3. OK Message: "The Import failed. The assembly does not appear to >> >> be >> >> valid." >> >> >> >> -->Correct versions of your compiled assemblies >> >> 4. My VS compiling procedures: I Debug compile locally on my machine >> >> then >> >> send a Release "updated" compiled version of the application to my >> >> local >> >> network (\\serverName\Pub\Business...). Then. I went to a typical >> >> users >> >> machine and tried to set it up the Machine Code Group same way I did >> >> on >> >> my >> >> machine. My machine works fine form Pub >> >> >> >> -->Are any of the assemblies delay signed? >> >> 5. No assemblies are delay signed >> >> >> >> Note: The VS solution has one exe file project and two dll projects. >> >> One >> >> dll is a GUI for a Access dB and the other is a Library for the dB. >> >> The >> >> excute file DOES RUN on the users machine because I earlier ran the >> >> Trust >> >> Assembly wizard and identified the exe file however the exe file calls >> >> the dB >> >> GUI and that fails to open. The Trust Assembly wizard will not trust >> >> the >> >> dB >> >> dll's >> >> >> >> Steve >> >> >> >> "Nicole Calinoiu" wrote: >> >> >> >> > "Steve B." <SteveB@discussions.microsoft.com> wrote in message >> >> > news:F89770A4-781D-481D-B11B-0D1962B42E07@microsoft.com... >> >> > > Nicole, >> >> > > >> >> > > Sorry to to keep asking these questions, however, this is the most >> >> > > success >> >> > > I've had in solving this problem so far. >> >> > > >> >> > > After following the earlier post instructions the program opened >> >> > > up >> >> > > fine >> >> > > on >> >> > > my machine but when I went to another user's machine I recieved
Nicole, Thank You Nicole for sticking with me I’ve created one new key for the VS solution IAW the MS Know. Base article below but with the USA holiday coming up this weekend I won’t be back in the office till next Wednesday so I can’t try if it works If it doesn’t I’ll institute the measures you suggest and let you know the result after that I’ll have to go for MS help. The non-profit is the US military. http://support.microsoft.com/default.aspx?scid=kb;en-us;815808 Steve [quoted text, click to view] "Nicole Calinoiu" wrote: > "Steve B." <SteveB@discussions.microsoft.com> wrote in message > news:23BE341C-E989-4BE1-9033-F7733697C534@microsoft.com... > <snip> > > What's my next step/your recommendation? (recreate keys?) > > As long as the keys are valid, they can't be causing the problem. If you > want to simplify things and use a new key that's shared across the three > projects, go ahead, but this won't address any potential client > configuration issues. > > > > Are there obvious machine configurations (not fruitless) I can check? > > There are too many candidates for blind troubleshooting. Since things seem > to be in a bit of a muddle, I'd recommend taking a step back and checking if > things are really working as you seem to think on your development machine > before going looking for problems on the other clients. If you're up for > this, here are the steps I'd take: > > 1. Back up your compiled assemblies (the EXE and both DLLs) and your CAS > policy files (or even safer, then entire > <windows>\Microsoft.NET\Framework\<version>\CONFIG directory) to some > location off your machine. > > 2. Delete all local debug and release mode compiled copies of your EXE and > DLLs, including any copies in the GAC. > > 3. Reset your CAS policy. (See the "To reset all policy levels" topic at > http://msdn.microsoft.com/library/en-us/cptools/html/cpconNETFrameworkAdministrationToolMscorcfgmsc.asp > if you're not sure how to do this.) > > 4. Recompile your three assemblies in release mode. > > 5. Replace the assemblies in your network distribution folder with the > newly compiled copies, then deleted the local copies from your development > machine. If any copies ended up the GAC (for example, due to a build > event), delete these as well. > > 6. Attempt to run the EXE from the network folder. Do you see the expected > SecurityException? > > 7. Attempt to create new code group(s) based on strong name membership > condition(s) for trusting the assemblies, loading them from the network > folder.. Do you encounter any problems? > > > > > How can I raise this up a step (note: I work for non-profit group) > > The various support options available from Microsoft are listed at > http://support.microsoft.com/. I suppose that some might cost less for a > non-profit, but I have no personal experience in this area. > > > > > > > Steve > > > > > > "Nicole Calinoiu" wrote: > > > >> "Steve B." <SteveB@discussions.microsoft.com> wrote in message > >> news:F7803F8D-061B-4245-AC72-0607D655475F@microsoft.com... > >> >I was thinking (just ideas): > >> > - Why does the trust assembly wizard give an error message (" Unable > >> > to > >> > load [path to dll]") when I identify the dll but it works for the > >> > execute > >> > file > >> > >> If this works for the EXE, then perhaps there's some problem with the DLL > >> itself. Do you get the exact same result for both DLLs? Are the DLLs > >> located in the exact same directory as the EXE? > >> > >> > >> > - What about the location(s) of the assembly file key (path) to my > >> > harddrive > >> > >> Not relevant. The key file is not used anymore after the assemblies are > >> signed at compile-time. > >> > >> > - should it be the network? (see earlier post for C: path) > >> > >> Absolutely not. In fact, the key you use to sign your production > >> assemblies > >> probably shouldn't even be stored on your development machine. See > >> http://msdn.microsoft.com/library/en-us/dnnetsec/html/strongNames.asp for > >> a > >> discussion of key storage techniques. > >> > >> > >> > - Why is the policy change work on my ("the developer's") machine? > >> > >> Most likely because there's something different about your machine's > >> configuration. There are many, many possibilities, and trying to guess > >> is > >> likely to be fruitless. > >> > >> > - Should I test the policy change on more then one user? > >> > >> Eventually, yes. However, it would be a good idea to get it working on > >> at > >> least one user machine before starting to muck about with others. > >> > >> > >> > - Do I need to refence the assembly file or key in the VS project or > >> > the > >> > program file? > >> > >> No. The key file is never needed at runtime. > >> > >> > - Do I need to register the key (regsvces,exe??) > >> > >> No. Again, the key is only used to sign the assembly at compile time. > >> It's > >> never needed again unless you need to re-sign a delay-signed assembly, > >> which > >> you don't since you're not using delay signing. > >> > >> > >> > > >> > Steve > >> > > >> > "Steve B." wrote: > >> > > >> >> Nicole, > >> >> > >> >> Trying to provide you as may elements of my environment as possible. > >> >> Please > >> >> - don't assume I know what I'm doing > >> >> > >> >> -->When do you see this message? > >> >> 1. When I try to do the policy changes NOT when the application runs. > >> >> > >> >> --> Could you please provide repro steps? > >> >> 2. The policy change steps are the same steps as I did on my machine > >> >> and > >> >> are the the same as the earlier web site you referenced > >> >> (Machine-all_code-new..). The error message occurs after selecting > >> >> Strong > >> >> Name from comboBox and after clicking the Import button and when I > >> >> iidentify > >> >> the application dll on the shared Pub drive > >> >> > >> >> -->Exact message > >> >> 3. OK Message: "The Import failed. The assembly does not appear to > >> >> be > >> >> valid." > >> >> > >> >> -->Correct versions of your compiled assemblies > >> >> 4. My VS compiling procedures: I Debug compile locally on my machine > >> >> then > >> >> send a Release "updated" compiled version of the application to my > >> >> local > >> >> network (\\serverName\Pub\Business...). Then. I went to a typical > >> >> users > >> >> machine and tried to set it up the Machine Code Group same way I did > >> >> on > >> >> my > >> >> machine. My machine works fine form Pub > >> >> > >> >> -->Are any of the assemblies delay signed? > >> >> 5. No assemblies are delay signed > >> >> > >> >> Note: The VS solution has one exe file project and two dll projects. > >> >> One > >> >> dll is a GUI for a Access dB and the other is a Library for the dB. > >> >> The
Nicole, I thought I should let you what happened in discussions with MS. It’s a bit confusing to follow but below is one of my replies which I hoped solved the problem. MS replied to my questions - if interested in Q's let me know Note: are we running out of posting space Steve ****************** From: Steve I think success but, in a slightly different way. I divided your e-mail into Parts I and II (see below) Part 1 (MS suggested trying URL vice strong name) My share: file:////\\servername\pub\* or file:////\\ servername \pub\BIP\* Initially I tried this and received the error message: "Windows cannot access the specified device, path or file may not have the appropriate permissions to access item". Part II (MS - try the strong name with his MS VS solution) No comments - except that I still get the Import error message My Solution ?? In my original message to MS Help and, while driving home yesterday, I thought about why does the exe and dll's only run on my machine and that of the other user's machine only (lets call him user1). So, this morning I right clicked on the the exe and dll's on the shared pub drive and went to the file properties -> security tab. To my surprise the names for user1 and myself and, a couple of other people, had Full Control check marks next to them, while the item "Everyone" had only partial control check marks. So, at this point, I gave the "Everyone" line item Full Control check marks. I then tested two typical users with Parts I and II and they both parts WORKED! - no error message. The exe ran and also linked to the ADONet dll(s) However, this success raises a couple of more Questions 1. What did I do when I gave Everyone Full Control of BIP exe and dll's? I don't have a problem with it and I think it's a good thing that all users have full control. I'm just wondering how user1 and I got full control? My IT person? 2. Did this procedure of giving Full Control really solve my problem? Why? Or, is it just understood policy? 3. Can you point somewhere I can learn about the security tab? Does the security tab settings override .Net CAS settings (doesn't seem right and that's why I never thought of it)? I guess I'm confused at the interfacing between CAS and the security tab 4. Should I use the URL method (file://..server...\Pub\BIP\*) in Part I or the Strong Name method in Part II for the BIP program security policy? The programmer in me says to use the Strong Name method but the URL method is quick and easy plus I'll be creating more ADONet dll's in future (have 60 users). Or, does Part I incorporate Strong Names anyways? The BIP program will never be deployed except to the local Pub share (doing regular VS Release compile outputs to \\... \Pub\BIP\) 5. Very important question - How do I set security policy level for the BIP program itself without ever going to each individual machine and setting BIP security policy? Can I do something like set policy at the Enterprise level? [quoted text, click to view] "Steve B." wrote: > Nicole, > > Thank You Nicole for sticking with me > > I’ve created one new key for the VS solution IAW the MS Know. Base article > below but with the USA holiday coming up this weekend I won’t be back in the > office till next Wednesday so I can’t try if it works > > If it doesn’t I’ll institute the measures you suggest and let you know the > result after that I’ll have to go for MS help. The non-profit is the US > military. > > http://support.microsoft.com/default.aspx?scid=kb;en-us;815808 > > Steve > > > "Nicole Calinoiu" wrote: > > > "Steve B." <SteveB@discussions.microsoft.com> wrote in message > > news:23BE341C-E989-4BE1-9033-F7733697C534@microsoft.com... > > <snip> > > > What's my next step/your recommendation? (recreate keys?) > > > > As long as the keys are valid, they can't be causing the problem. If you > > want to simplify things and use a new key that's shared across the three > > projects, go ahead, but this won't address any potential client > > configuration issues. > > > > > > > Are there obvious machine configurations (not fruitless) I can check? > > > > There are too many candidates for blind troubleshooting. Since things seem > > to be in a bit of a muddle, I'd recommend taking a step back and checking if > > things are really working as you seem to think on your development machine > > before going looking for problems on the other clients. If you're up for > > this, here are the steps I'd take: > > > > 1. Back up your compiled assemblies (the EXE and both DLLs) and your CAS > > policy files (or even safer, then entire > > <windows>\Microsoft.NET\Framework\<version>\CONFIG directory) to some > > location off your machine. > > > > 2. Delete all local debug and release mode compiled copies of your EXE and > > DLLs, including any copies in the GAC. > > > > 3. Reset your CAS policy. (See the "To reset all policy levels" topic at > > http://msdn.microsoft.com/library/en-us/cptools/html/cpconNETFrameworkAdministrationToolMscorcfgmsc.asp > > if you're not sure how to do this.) > > > > 4. Recompile your three assemblies in release mode. > > > > 5. Replace the assemblies in your network distribution folder with the > > newly compiled copies, then deleted the local copies from your development > > machine. If any copies ended up the GAC (for example, due to a build > > event), delete these as well. > > > > 6. Attempt to run the EXE from the network folder. Do you see the expected > > SecurityException? > > > > 7. Attempt to create new code group(s) based on strong name membership > > condition(s) for trusting the assemblies, loading them from the network > > folder.. Do you encounter any problems? > > > > > > > > > How can I raise this up a step (note: I work for non-profit group) > > > > The various support options available from Microsoft are listed at > > http://support.microsoft.com/. I suppose that some might cost less for a > > non-profit, but I have no personal experience in this area. > > > > > > > > > > > > Steve > > > > > > > > > "Nicole Calinoiu" wrote: > > > > > >> "Steve B." <SteveB@discussions.microsoft.com> wrote in message > > >> news:F7803F8D-061B-4245-AC72-0607D655475F@microsoft.com... > > >> >I was thinking (just ideas): > > >> > - Why does the trust assembly wizard give an error message (" Unable > > >> > to > > >> > load [path to dll]") when I identify the dll but it works for the > > >> > execute > > >> > file > > >> > > >> If this works for the EXE, then perhaps there's some problem with the DLL > > >> itself. Do you get the exact same result for both DLLs? Are the DLLs > > >> located in the exact same directory as the EXE? > > >> > > >>
Inline... [quoted text, click to view] "Steve B." <SteveB@discussions.microsoft.com> wrote in message
news:D10275F3-595F-492F-937C-59897ED12037@microsoft.com...
> Nicole,
>
> I thought I should let you what happened in discussions with MS. It's a
> bit
> confusing to follow but below is one of my replies which I hoped solved
> the
> problem. MS replied to my questions - if interested in Q's let me know
>
> Note: are we running out of posting space
>
> Steve
>
> ******************
> From: Steve
>
> I think success but, in a slightly different way. I divided your e-mail
> into Parts I and II (see below)
>
> Part 1 (MS suggested trying URL vice strong name)
>
> My share: file:////\\servername\pub\* or file:////\\ servername \pub\BIP\*
>
> Initially I tried this and received the error message: "Windows cannot
> access the specified device, path or file may not have the appropriate
> permissions to access item".
Since you've been changing permissions, this might not be reproducible any longer, so it's probably a good idea to ignore that outcome for now. [quoted text, click to view] >
> Part II (MS - try the strong name with his MS VS solution)
>
> No comments - except that I still get the Import error message
Still weird, but nothing I can diagnose based on the information you've provided so far. [quoted text, click to view] >
> My Solution ??
>
> In my original message to MS Help and, while driving home yesterday, I
> thought about why does the exe and dll's only run on my machine and that
> of
> the other user's machine only (lets call him user1). So, this morning I
> right clicked on the the exe and dll's on the shared pub drive and went to
> the file properties -> security tab. To my surprise the names for user1
> and
> myself and, a couple of other people, had Full Control check marks next to
> them, while the item "Everyone" had only partial control check marks.
> So, at
> this point, I gave the "Everyone" line item Full Control check marks. I
> then
> tested two typical users with Parts I and II and they both parts WORKED! -
> no
> error message.
Unfortunately, without knowing the exact permission set granted by these "partial control check marks", it's hard to say what the problem may have been. [quoted text, click to view] > The exe ran and also linked to the ADONet dll(s)
>
> However, this success raises a couple of more Questions
>
> 1. What did I do when I gave Everyone Full Control of BIP exe and dll's?
You granted at least one permission that is required for accessing the DLLs but that was not previously granted to the user. [quoted text, click to view] > I
> don't have a problem with it and I think it's a good thing that all users
> have full control.
You probably should, and it's probably not. <g> With full control, all the users can delete or modify the assemblies, by accident or on purpose. In addition, any malware running under these users' accounts will also be able to modify the assemblies, thereby potentially infecting the other users' machines. [quoted text, click to view] > I'm just wondering how user1 and I got full control? My
> IT person?
The permissions were probably inherited from the a folder in the parent directory hierarchy. I'm guessing that the permissions were proably set at the time of creation of the relevant folder(s). [quoted text, click to view] > 2. Did this procedure of giving Full Control really solve my problem?
> Why?
> Or, is it just understood policy?
Since you haven't provided the details of the old permission set, I can only guess that the users didn't have permissions to read and/or execute the assemblies in question. [quoted text, click to view] > 3. Can you point somewhere I can learn about the security tab?
It's not just a tab. What you're touching is the NTFS permissions on the files. Since you're working via a share, there may also be share permissions involved in the permission grant. If you're completely unfamiliar with these topics, it might be a good idea to talk to your IT folks. They should be able to introduce you to the topic as well as help troubleshoot your file permission issues without granting inappropriate permissions to users. If you want to read up on the topics of NTFS and share permissions, a good place to start might be http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerHelp/86987829-3f74-412f-abb8-c8b22b07257d.mspx. [quoted text, click to view] > Does the
> security tab settings override .Net CAS settings (doesn't seem right and
> that's why I never thought of it)? I guess I'm confused at the
> interfacing
> between CAS and the security tab
There's not relationship between the two. NTFS permissions and CAS permissions are granted under two completely separate security systems (the Windows security system and the .NET Framework security system). They do not interact. However, your code is constrained by both at runtime. i.e.: An assembly cannot do anything that falls outside the Windows permissions granted to the user or the CAS permissions granted to the code. [quoted text, click to view] > 4. Should I use the URL method (file://..server...\Pub\BIP\*) in Part I
> or
> the Strong Name method in Part II for the BIP program security policy? The
> programmer in me says to use the Strong Name method but the URL method is
> quick and easy plus I'll be creating more ADONet dll's in future (have 60
> users). Or, does Part I incorporate Strong Names anyways? The BIP
> program
> will never be deployed except to the local Pub share (doing regular VS
> Release compile outputs to \\... \Pub\BIP\)
If there's any chance that an unauthorized user might modify or add assemblies under the BIP folder (as they can now given the full control permissions you granted), the URL method should definitely not be used. Then again, even if they can't, a more secure approach would involve a dual membership condition code group defined by both the URL and the strong name public key. That's probably the approach I would take (using the same signing key for all the assemblies). However, before choosing a final approach, it might be a good idea to check in with the IT team to see if there isn't already a policy dictating the approach that should be taken for this sort of deployment scenario. [quoted text, click to view] > 5. Very important question - How do I set security policy level for the
> BIP
> program itself without ever going to each individual machine and setting
> BIP
> security policy? Can I do something like set policy at the Enterprise
> level?
Yes, but the policy still needs to be deployed, even though it doesn't have to involve manual policy application at each workstation. Some of the deployment options are listed at http://msdn.microsoft.com/library/en-us/dnnetsec/html/entsecpoladmin.asp, but you should probably choose one in conjunction with your IT staff since they're more likely to know what's possible/easy on their network. [quoted text, click to view] >
>
> "Steve B." wrote:
>
>> Nicole,
>>
>> Thank You Nicole for sticking with me
>>
Don't see what you're looking for? Try a search.
|
|
|
