|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
How to limmit who can call my assemblyVery simply, I have two assemblies, A and B where A calls methods on B. I
want to set it up so that only assembly A can call assembly B. I am sure I have seen something out there on how to do this but now that I need, to, I can't seem to find anything. All I can remember is I need to strongly type the assemblies. Can someone point me to the info I need? The more detailed scenario, for those who are interested is this: I have a client-side custom authentication assembly and a server assembly that actually does the authentication against the database. There is a third assembly, an interface assembly the defines the types know to both. I want to ensure that everyone who uses these authentication services does so through the client assembly and cant write anything that can hit the server assembly directly. My idea to do this is set it up so that only the client and server dlls may access the interface dll upon which they both depend. Does this make sense? Thanks in advance, --Ken Hello Kenneth,
I'd suggested to look at CAS http://msdn2.microsoft.com/en-us/library/h846e9b3.aspx KB> Very simply, I have two assemblies, A and B where A calls methods on KB> B. I want to set it up so that only assembly A can call assembly B. KB> I am sure I have seen something out there on how to do this but now KB> that I need, to, I can't seem to find anything. All I can remember KB> is I need to strongly type the assemblies. Can someone point me to KB> the info I need? KB> KB> The more detailed scenario, for those who are interested is this: I KB> have a client-side custom authentication assembly and a server KB> assembly that actually does the authentication against the database. KB> There is a third assembly, an interface assembly the defines the KB> types know to both. I want to ensure that everyone who uses these KB> authentication services does so through the client assembly and cant KB> write anything that can hit the server assembly directly. My idea KB> to do this is set it up so that only the client and server dlls may KB> access the interface dll upon which they both depend. Does this make KB> sense? KB> KB> Thanks in advance, --Ken KB> --- WBR, Michael Nemtsev [C# MVP] :: blog: http://spaces.live.com/laflour "At times one remains faithful to a cause only because its opponents do not cease to be insipid." (c) Friedrich Nietzsche Michael,
Thanks for the advice. I have looked through the CAS stuff a few times. But CAS is a big subject, so maybe it is in there somewhere and I just haven't found it yet. Can you be more specific maybe about what exactly I am looking for? As I have said, I have looked at CAS and it seems to be about controlling my codes access to system resources and things outside of my code. I am looking for the opposite. I want to control who accesses my code. Basically I want strongly named assembly A and ONLY assembly A to be able to call me. Show quote "Michael Nemtsev" <nemt***@msn.com> wrote in message news:1799a79b3c494f8c8e3c199d875ec@msnews.microsoft.com... > Hello Kenneth, > > I'd suggested to look at CAS > http://msdn2.microsoft.com/en-us/library/h846e9b3.aspx > > KB> Very simply, I have two assemblies, A and B where A calls methods on > KB> B. I want to set it up so that only assembly A can call assembly B. > KB> I am sure I have seen something out there on how to do this but now > KB> that I need, to, I can't seem to find anything. All I can remember > KB> is I need to strongly type the assemblies. Can someone point me to > KB> the info I need? > KB> KB> The more detailed scenario, for those who are interested is this: > I > KB> have a client-side custom authentication assembly and a server > KB> assembly that actually does the authentication against the database. > KB> There is a third assembly, an interface assembly the defines the > KB> types know to both. I want to ensure that everyone who uses these > KB> authentication services does so through the client assembly and cant > KB> write anything that can hit the server assembly directly. My idea > KB> to do this is set it up so that only the client and server dlls may > KB> access the interface dll upon which they both depend. Does this make > KB> sense? > KB> KB> Thanks in advance, --Ken > KB> --- > WBR, > Michael Nemtsev [C# MVP] :: blog: http://spaces.live.com/laflour > > "At times one remains faithful to a cause only because its opponents do > not cease to be insipid." (c) Friedrich Nietzsche > > You can cheat a bit...
Make all your classes internal, and add this attribute to assemblyinfo.cs : [assembly:InternalsVisibleToAttribute("AssemblyB, PublicKey=32ab4ba45e0a69a1")][assembly:InternalsVisibleToAttribute("AssemblyC, PublicKey=32ab4ba45e0a69a1")][assembly:InternalsVisibleToAttribute("AssemblyD, PublicKey=32ab4ba45e0a69a1")]Using this code, assmblies B C and D will be able to access internal classes. Note the CAS is a better solution, but I agree with you that it is quite a pain... "Kenneth Baltrinic" <no.direct.repl***@nowhere.xyz> a écrit dans le message de news: OgAiL8oFHHA.***@TK2MSFTNGP04.phx.gbl...Show quote > Michael, > > Thanks for the advice. I have looked through the CAS stuff a few times. > But CAS is a big subject, so maybe it is in there somewhere and I just > haven't found it yet. Can you be more specific maybe about what exactly I > am looking for? > > As I have said, I have looked at CAS and it seems to be about controlling > my codes access to system resources and things outside of my code. I am > looking for the opposite. I want to control who accesses my code. > Basically I want strongly named assembly A and ONLY assembly A to be able > to call me. > > "Michael Nemtsev" <nemt***@msn.com> wrote in message > news:1799a79b3c494f8c8e3c199d875ec@msnews.microsoft.com... >> Hello Kenneth, >> >> I'd suggested to look at CAS >> http://msdn2.microsoft.com/en-us/library/h846e9b3.aspx >> >> KB> Very simply, I have two assemblies, A and B where A calls methods on >> KB> B. I want to set it up so that only assembly A can call assembly B. >> KB> I am sure I have seen something out there on how to do this but now >> KB> that I need, to, I can't seem to find anything. All I can remember >> KB> is I need to strongly type the assemblies. Can someone point me to >> KB> the info I need? >> KB> KB> The more detailed scenario, for those who are interested is this: >> I >> KB> have a client-side custom authentication assembly and a server >> KB> assembly that actually does the authentication against the database. >> KB> There is a third assembly, an interface assembly the defines the >> KB> types know to both. I want to ensure that everyone who uses these >> KB> authentication services does so through the client assembly and cant >> KB> write anything that can hit the server assembly directly. My idea >> KB> to do this is set it up so that only the client and server dlls may >> KB> access the interface dll upon which they both depend. Does this make >> KB> sense? >> KB> KB> Thanks in advance, --Ken >> KB> --- >> WBR, >> Michael Nemtsev [C# MVP] :: blog: http://spaces.live.com/laflour >> >> "At times one remains faithful to a cause only because its opponents do >> not cease to be insipid." (c) Friedrich Nietzsche >> >> > > Ah ha!
Steve, Thanks, that was what I was looking for. I knew I had seen it before but obviously I didn't remember it well enough to be able to find it. Investigating that, I have followed the trail to the StrongNameIdentityPermission attribute which I presume is what you mean when you said "CAS has a better solution?" Very cool. Again thanks! --Ken Show quote "Steve B." <steve_beauge@com.msn_swap_msn_and_com> wrote in message news:eqOZWGuFHHA.1248@TK2MSFTNGP03.phx.gbl... > You can cheat a bit... > Make all your classes internal, and add this attribute to assemblyinfo.cs > : > [assembly:InternalsVisibleToAttribute("AssemblyB, > PublicKey=32ab4ba45e0a69a1")][assembly:InternalsVisibleToAttribute("AssemblyC, > PublicKey=32ab4ba45e0a69a1")][assembly:InternalsVisibleToAttribute("AssemblyD, > PublicKey=32ab4ba45e0a69a1")]Using this code, assmblies B C and D will be > able to access internal classes. > > Note the CAS is a better solution, but I agree with you that it is quite a > pain... > > > > "Kenneth Baltrinic" <no.direct.repl***@nowhere.xyz> a écrit dans le > message de news: OgAiL8oFHHA.***@TK2MSFTNGP04.phx.gbl... >> Michael, >> >> Thanks for the advice. I have looked through the CAS stuff a few times. >> But CAS is a big subject, so maybe it is in there somewhere and I just >> haven't found it yet. Can you be more specific maybe about what exactly >> I am looking for? >> >> As I have said, I have looked at CAS and it seems to be about controlling >> my codes access to system resources and things outside of my code. I am >> looking for the opposite. I want to control who accesses my code. >> Basically I want strongly named assembly A and ONLY assembly A to be able >> to call me. >> >> "Michael Nemtsev" <nemt***@msn.com> wrote in message >> news:1799a79b3c494f8c8e3c199d875ec@msnews.microsoft.com... >>> Hello Kenneth, >>> >>> I'd suggested to look at CAS >>> http://msdn2.microsoft.com/en-us/library/h846e9b3.aspx >>> >>> KB> Very simply, I have two assemblies, A and B where A calls methods on >>> KB> B. I want to set it up so that only assembly A can call assembly B. >>> KB> I am sure I have seen something out there on how to do this but now >>> KB> that I need, to, I can't seem to find anything. All I can remember >>> KB> is I need to strongly type the assemblies. Can someone point me to >>> KB> the info I need? >>> KB> KB> The more detailed scenario, for those who are interested is >>> this: I >>> KB> have a client-side custom authentication assembly and a server >>> KB> assembly that actually does the authentication against the database. >>> KB> There is a third assembly, an interface assembly the defines the >>> KB> types know to both. I want to ensure that everyone who uses these >>> KB> authentication services does so through the client assembly and cant >>> KB> write anything that can hit the server assembly directly. My idea >>> KB> to do this is set it up so that only the client and server dlls may >>> KB> access the interface dll upon which they both depend. Does this make >>> KB> sense? >>> KB> KB> Thanks in advance, --Ken >>> KB> --- >>> WBR, >>> Michael Nemtsev [C# MVP] :: blog: http://spaces.live.com/laflour >>> >>> "At times one remains faithful to a cause only because its opponents do >>> not cease to be insipid." (c) Friedrich Nietzsche >>> >>> >> >> > >  |
|||||||||||||||||||||||
Other interesting topics