'Inaccessible due to is protection level' messages when building unified assembly with strong name

[Richard Collette]

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:

msbuild /p:KeyPairContainer=DotNetOpenAuthcontainer,PublicKeyFile="c:\code\DotNetOpenAuth.pub" /p:TargetFrameworkVersion=v4.0

I get a bunch of errors similar to:

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.

[Andrew Arnott]

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

--
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 dotnet...@googlegroups.com.
To unsubscribe from this group, send email to dotnetopenid...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/dotnetopenid?hl=en.

[Andrew Savinykh]

I think the issue here is that assemblyinfo.cs has a bunch of these:
[assembly: InternalsVisibleTo("DotNetOpenAuth.Test, PublicKey=0024000004800000940000000602000000240000525341310004000001000100AD093C3765257C89A7010E853F2C7C741FF92FA8ACE06D7B8254702CAD5CF99104447F63AB05F8BB6F51CE0D81C8C93D2FCE8C20AAFF7042E721CBA16EAAE98778611DED11C0ABC8900DC5667F99B50A9DADEC24DBD8F2C91E3E8AD300EF64F1B4B9536CEB16FB440AF939F57624A9B486F867807C649AE4830EAB88C6C03998")]
[assembly: InternalsVisibleTo("DotNetOpenAuth.Core.UI, PublicKey=0024000004800000940000000602000000240000525341310004000001000100AD093C3765257C89A7010E853F2C7C741FF92FA8ACE06D7B8254702CAD5CF99104447F63AB05F8BB6F51CE0D81C8C93D2FCE8C20AAFF7042E721CBA16EAAE98778611DED11C0ABC8900DC5667F99B50A9DADEC24DBD8F2C91E3E8AD300EF64F1B4B9536CEB16FB440AF939F57624A9B486F867807C649AE4830EAB88C6C03998")]

etc.

Of course, if you follow the instruction here http://www.dotnetopenauth.net/developers/contributing/quickstart-environment/ (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...

[Andrew Savinykh]

And also I wanted to point out this:

keypaircontainer is used for the delay-signing with the private key. publickeyfile is passed to ilmerge so that the output can be later delay-signed, this is why you need both, It's explained here:
http://blog.nerdbank.net/2009/06/how-to-get-ilmerge-to-work-with-pfx.html

Was not it you who wrote this blog post?

Andrew.

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:

msbuild /p:KeyPairContainer=DotNetOpenAuthcontainer,PublicKeyFile="c:\code\DotNetOpenAuth.pub" /p:TargetFrameworkVersion=v4.0

I get a bunch of errors similar to:

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.
To post to this group, send email to dotnet...@googlegroups.com.

To unsubscribe from this group, send email to dotnetopenid+unsubscribe@googlegroups.com.

[Andrew Arnott]

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

To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/jZj3E2SnwS4J.

To post to this group, send email to dotnet...@googlegroups.com.

To unsubscribe from this group, send email to dotnetopenid...@googlegroups.com.

[Richard Collette]

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.