[217] Code Analysis Woes with [InternalsVisibleTo]

Hello,

I have the following test fixture:


public class Test_BasicFormInteraction
{
private BaseDialogControl mDialogControl;
private ITestDialogController mDialogController;
private TestDialogForm mDialogForm;
private ITestDialog mTestDialog;
private TestDialogData mTestDialogData;

//

public void Setup()
{
// use of members mDialogControl, mDialogController,
etc
}

BaseDialogControl (the first member's type) is accessed via the
relationship, and is hence (not yet) recognised by
ReSharper. That's ok and has been the case with builds up to 216.

But now, RS reports all members that are used in Setup() to be unknown.
It seems that with build 217, code analysis stops for all members
because the first one's (friend-internal) type cannot be resolved. In
addition, the whole class is not recognised as a unit test fixture (no
test running icons are displayed).

If I comment out the first member, code analysis runs again, this time
for all other members, whose types are known. If I then recomment in the
unknown type, only the type itself is reported to be unknown, but all
members (including the one with the unknown type) are handled correctly,
i.e., can be normally used. Also, the class is now correctly identified
as a unit test fixture.

Cheers,

Christian

3 comments
Comment actions Permalink

In 216, we do support InternalVisibleTo attribute when referencing assembly
with it. (InternalVisibleTo from source code is not yet supported).

I'm unable to reproduce your behavour.
Please could you send me the sample solution with project and the dll, which
cause this problem?

My address is Eugene.Pasynkov (at) jetbrains.com

--
Eugene Pasynkov
Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
"Christian Eitner" <ChristianREMOVE.Eitner@THISanton-paar.com> wrote in
message news:MPG.1e53d0c3d00c13bc989686@193.81.230.101...

Hello,

>

I have the following test fixture:

>


public class Test_BasicFormInteraction
{
private BaseDialogControl mDialogControl;
private ITestDialogController mDialogController;
private TestDialogForm mDialogForm;
private ITestDialog mTestDialog;
private TestDialogData mTestDialogData;

>

//

public void Setup()
{
// use of members mDialogControl, mDialogController,
etc
}

>

BaseDialogControl (the first member's type) is accessed via the
relationship, and is hence (not yet) recognised by
ReSharper. That's ok and has been the case with builds up to 216.

>

But now, RS reports all members that are used in Setup() to be unknown.
It seems that with build 217, code analysis stops for all members
because the first one's (friend-internal) type cannot be resolved. In
addition, the whole class is not recognised as a unit test fixture (no
test running icons are displayed).

>

If I comment out the first member, code analysis runs again, this time
for all other members, whose types are known. If I then recomment in the
unknown type, only the type itself is reported to be unknown, but all
members (including the one with the unknown type) are handled correctly,
i.e., can be normally used. Also, the class is now correctly identified
as a unit test fixture.

>

Cheers,

>

Christian



0
Comment actions Permalink

Dear Eugene,

In article <dscbsj$v6j$1@is.intellij.net>, Eugene.Pasynkov@jetbrains.com
says...

In 216, we do support InternalVisibleTo attribute when referencing assembly
with it. (InternalVisibleTo from source code is not yet supported).


I don't quite understand which kind of support should already be
existing. What does 'when referencing assembly with it' mean?

My assemblies are signed with a strong name key, and in the
AssemblyInfo.cs file of assembly Foo I use

[assembly: InternalsVisibleTo("Bar, PublicKey=1234")]

Still, in Assembly Bar, RS (up to and including build 217) marks the
internal types of Foo as non-accessible and does not provide
Intellisense for them.

Please could you send me the sample solution with project and the dll, which
cause this problem?


I'm very sorry, but non-disclosure agreements prevent me from sending
you code owned by the company I'm working for, and I cannot quite pull
off the time to stick together a sample solution.

Cheers,

Christian

0
Comment actions Permalink

Huh, I see!
I should read MSDN deeper, since I thought that AssemblyName in attribute
parameter cannot contain key part.

--
Eugene Pasynkov
Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
"Christian Eitner" <ChristianREMOVE.Eitner@THISanton-paar.com> wrote in
message news:MPG.1e53e624f2e1a18c989687@193.81.230.101...

Dear Eugene,

>

In article <dscbsj$v6j$1@is.intellij.net>, Eugene.Pasynkov@jetbrains.com
says...

>> In 216, we do support InternalVisibleTo attribute when referencing
>> assembly
>> with it. (InternalVisibleTo from source code is not yet supported).
>

I don't quite understand which kind of support should already be
existing. What does 'when referencing assembly with it' mean?

>

My assemblies are signed with a strong name key, and in the
AssemblyInfo.cs file of assembly Foo I use

>

[assembly: InternalsVisibleTo("Bar, PublicKey=1234")]

>

Still, in Assembly Bar, RS (up to and including build 217) marks the
internal types of Foo as non-accessible and does not provide
Intellisense for them.

>
>> Please could you send me the sample solution with project and the dll,
>> which
>> cause this problem?
>

I'm very sorry, but non-disclosure agreements prevent me from sending
you code owned by the company I'm working for, and I cannot quite pull
off the time to stick together a sample solution.

>

Cheers,

>

Christian



0

Please sign in to leave a comment.