I'm building the unified assembly from the current master branch. I can build it fine without specifying an sn key on the command line. When I use the following command line:
OAuth\Messages\SignedMessageBase.cs(18,78): error CS0122: 'DotNetOpenAuth.Messaging.Bindings.IExpiringProtocolMessage' is inaccessible due to its protection l evel [c:\Code\DotNetOpenAuthSrc\dotnetopenid\src\DotNetOpenAuth.OAuth\DotNetOpen Auth.OAuth.csproj]
Tried it in release mode as well with same results.
I suspect your use of the /p parameter is setting a global property that
will end up causing conflicts within the build authoring for the project.
Also, it shouldn't be necessary to specify both a publickeyfile and
keypaircontainer, IIRC.
Those are my only guesses right now.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre
On Tue, May 15, 2012 at 10:32 AM, Richard Collette <
richard.colle...@gmail.com> wrote:
> I'm building the unified assembly from the current master branch. I can
> build it fine without specifying an sn key on the command line. When I use
> the following command line:
> OAuth\Messages\SignedMessageBase.cs(18,78): error CS0122:
> 'DotNetOpenAuth.Messaging.Bindings.IExpiringProtocolMessage' is
> inaccessible due to its protection l
> evel
> [c:\Code\DotNetOpenAuthSrc\dotnetopenid\src\DotNetOpenAuth.OAuth\DotNetOpen Auth.OAuth.csproj]
> Tried it in release mode as well with same results.
> --
> You received this message because you are subscribed to the Google Groups
> "DotNetOpenAuth" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/dotnetopenid/-/ynxJ2CSp20QJ.
> To post to this group, send email to dotnetopenid@googlegroups.com.
> To unsubscribe from this group, send email to
> dotnetopenid+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/dotnetopenid?hl=en.
I think the issue here is that assemblyinfo.cs has a bunch of these: [assembly: InternalsVisibleTo("DotNetOpenAuth.Test, PublicKey=0024000004800000940000000602000000240000525341310004000001000100A D093C3765257C89A7010E853F2C7C741FF92FA8ACE06D7B8254702CAD5CF99104447F63AB05 F8BB6F51CE0D81C8C93D2FCE8C20AAFF7042E721CBA16EAAE98778611DED11C0ABC8900DC56 67F99B50A9DADEC24DBD8F2C91E3E8AD300EF64F1B4B9536CEB16FB440AF939F57624A9B486 F867807C649AE4830EAB88C6C03998")] [assembly: InternalsVisibleTo("DotNetOpenAuth.Core.UI, PublicKey=0024000004800000940000000602000000240000525341310004000001000100A D093C3765257C89A7010E853F2C7C741FF92FA8ACE06D7B8254702CAD5CF99104447F63AB05 F8BB6F51CE0D81C8C93D2FCE8C20AAFF7042E721CBA16EAAE98778611DED11C0ABC8900DC56 67F99B50A9DADEC24DBD8F2C91E3E8AD300EF64F1B4B9536CEB16FB440AF939F57624A9B486 F867807C649AE4830EAB88C6C03998")]
etc.
Of course, if you follow the instruction here http://www.dotnetopenauth.net/developers/contributing/quickstart-envi... (like the, OP did, and by the way both a publickeyfile and keypaircontainer are prescribed to be used in this doco) you are going to change the public key, so all theses InternalsVisibleTo become invalid. No wonder it has accessibility problem afterwards.
I'd still very much like to know a working solution to this problem...
On Monday, May 21, 2012 1:21:35 PM UTC+12, Andrew Arnott wrote:
> I suspect your use of the /p parameter is setting a global property that > will end up causing conflicts within the build authoring for the project. > Also, it shouldn't be necessary to specify both a publickeyfile and > keypaircontainer, IIRC.
> Those are my only guesses right now. > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the death > your right to say it." - S. G. Tallentyre
> On Tue, May 15, 2012 at 10:32 AM, Richard Collette wrote:
>> I'm building the unified assembly from the current master branch. I can >> build it fine without specifying an sn key on the command line. When I use >> the following command line:
>> OAuth\Messages\SignedMessageBase.cs(18,78): error CS0122: >> 'DotNetOpenAuth.Messaging.Bindings.IExpiringProtocolMessage' is >> inaccessible due to its protection l >> evel >> [c:\Code\DotNetOpenAuthSrc\dotnetopenid\src\DotNetOpenAuth.OAuth\DotNetOpen Auth.OAuth.csproj]
>> Tried it in release mode as well with same results.
>> -- >> You received this message because you are subscribed to the Google Groups >> "DotNetOpenAuth" group. >> To view this discussion on the web visit >> https://groups.google.com/d/msg/dotnetopenid/-/ynxJ2CSp20QJ. >> To post to this group, send email to dotnetopenid@googlegroups.com. >> To unsubscribe from this group, send email to >> dotnetopenid+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/dotnetopenid?hl=en.
Yes, Andrew, I did... about 3 years ago. Fortunately source control has
allowed me to forget solutions to previously solved problems of yesteryear.
;)
And yes, regarding those InternalsVisibleTo attributes, I think the ideal
fix for this might be a build step which regenerates these attributes based
on the actual key being used to sign the assemblies. In the meantime, the
easiest way to build your own is to register for skip verification and just
delay sign the assemblies using the original key.
Of course, that doesn't work so well if you use the DLL you build in
production, which leads me to my question: if you need it in production,
why do you need to build your own version?
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre
> On Monday, May 21, 2012 1:21:35 PM UTC+12, Andrew Arnott wrote:
>> I suspect your use of the /p parameter is setting a global property that
>> will end up causing conflicts within the build authoring for the project.
>> Also, it shouldn't be necessary to specify both a publickeyfile and
>> keypaircontainer, IIRC.
>> Those are my only guesses right now.
>> --
>> Andrew Arnott
>> "I [may] not agree with what you have to say, but I'll defend to the
>> death your right to say it." - S. G. Tallentyre
>> On Tue, May 15, 2012 at 10:32 AM, Richard Collette wrote:
>>> I'm building the unified assembly from the current master branch. I can
>>> build it fine without specifying an sn key on the command line. When I use
>>> the following command line:
>>> OAuth\Messages\**SignedMessageBase.cs(18,78): error CS0122:
>>> 'DotNetOpenAuth.Messaging.**Bindings.**IExpiringProtocolMessage' is
>>> inaccessible due to its protection l
>>> evel [c:\Code\DotNetOpenAuthSrc\**dotnetopenid\src\**
>>> DotNetOpenAuth.OAuth\**DotNetOpenAuth.OAuth.csproj]
>>> Tried it in release mode as well with same results.
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "DotNetOpenAuth" group.
>>> To view this discussion on the web visit https://groups.google.com/d/** >>> msg/dotnetopenid/-/**ynxJ2CSp20QJ<https://groups.google.com/d/msg/dotnetopenid/-/ynxJ2CSp20QJ>
>>> .
>>> To post to this group, send email to dotnetopenid@googlegroups.com.
>>> To unsubscribe from this group, send email to dotnetopenid+unsubscribe@*
>>> *googlegroups.com <dotnetopenid%2Bunsubscribe@googlegroups.com>.
>>> For more options, visit this group at http://groups.google.com/** >>> group/dotnetopenid?hl=en<http://groups.google.com/group/dotnetopenid?hl=en>
>>> .
> To post to this group, send email to dotnetopenid@googlegroups.com.
> To unsubscribe from this group, send email to
> dotnetopenid+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/dotnetopenid?hl=en.
At the time I posted the original issue, I had worked around the fact that I could not create an simple registration unsolicited assertion with configuration parameters (this is obviously a vague, non Type specific, recollection). That issue is now supposed to be resolved in 4.1, although now we are using attribute exchange exclusively due to a need for fine grained properties (first/last name) in addition to custom properties.
However, one never knows when they are going to hit a wall in a project and need to correct something quickly to keep things moving. Being able to compile for production use is still reassuring even if there are no current issues to be worked around.
On Tuesday, July 3, 2012 7:00:11 PM UTC-4, Andrew Arnott wrote:
> Yes, Andrew, I did... about 3 years ago. Fortunately source control has > allowed me to forget solutions to previously solved problems of yesteryear. > ;)
> And yes, regarding those InternalsVisibleTo attributes, I think the ideal > fix for this might be a build step which regenerates these attributes based > on the actual key being used to sign the assemblies. In the meantime, the > easiest way to build your own is to register for skip verification and just > delay sign the assemblies using the original key.
> Of course, that doesn't work so well if you use the DLL you build in > production, which leads me to my question: if you need it in production, > why do you need to build your own version? > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the death > your right to say it." - S. G. Tallentyre
> On Tue, Jul 3, 2012 at 3:03 PM, Andrew Savinykh <andrew...@gmail.com>wrote:
>> On Monday, May 21, 2012 1:21:35 PM UTC+12, Andrew Arnott wrote:
>>> I suspect your use of the /p parameter is setting a global property that >>> will end up causing conflicts within the build authoring for the project. >>> Also, it shouldn't be necessary to specify both a publickeyfile and >>> keypaircontainer, IIRC.
>>> Those are my only guesses right now. >>> -- >>> Andrew Arnott >>> "I [may] not agree with what you have to say, but I'll defend to the >>> death your right to say it." - S. G. Tallentyre
>>> On Tue, May 15, 2012 at 10:32 AM, Richard Collette wrote:
>>>> I'm building the unified assembly from the current master branch. I >>>> can build it fine without specifying an sn key on the command line. When I >>>> use the following command line:
>>>> OAuth\Messages\**SignedMessageBase.cs(18,78): error CS0122: >>>> 'DotNetOpenAuth.Messaging.**Bindings.**IExpiringProtocolMessage' is >>>> inaccessible due to its protection l >>>> evel [c:\Code\DotNetOpenAuthSrc\**dotnetopenid\src\** >>>> DotNetOpenAuth.OAuth\**DotNetOpenAuth.OAuth.csproj]
>>>> Tried it in release mode as well with same results.
>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "DotNetOpenAuth" group. >>>> To view this discussion on the web visit https://groups.google.com/d/** >>>> msg/dotnetopenid/-/**ynxJ2CSp20QJ<https://groups.google.com/d/msg/dotnetopenid/-/ynxJ2CSp20QJ> >>>> . >>>> To post to this group, send email to dotnetopenid@googlegroups.com. >>>> To unsubscribe from this group, send email to dotnetopenid+unsubscribe@ >>>> **googlegroups.com <dotnetopenid%2Bunsubscribe@googlegroups.com>. >>>> For more options, visit this group at http://groups.google.com/** >>>> group/dotnetopenid?hl=en<http://groups.google.com/group/dotnetopenid?hl=en> >>>> .
>> To post to this group, send email to dotnetopenid@googlegroups.com. >> To unsubscribe from this group, send email to >> dotnetopenid+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/dotnetopenid?hl=en.
