PostSharp

[Guest]

I am trying out an OnMethodBoundaryAspect and when I run Visual Studio's Code Analysis on the assembly there are several code analysis warnings for the generated code.

One, CA1810, relates to the the static class that PostSharp.Laos adds to the assembly and perhaps this one could be suppressed by adding an System.Diagnostics.CodeAnalysis.SuppressMessageAttribute to the code that gets generated. The other warnings arise from our company rules and clearly our rules shouldn't apply to PostSharp's generated code. Although I can individually suppress these messages I'd rather not have to - not least because these warnings would be a surprise to developers maintaining the class who do not want to know about the internal workings of PostSharp.

Therefore I wonder if the generated code could have the System.CodeDom.Compiler.GeneratedCodeAttribute applied to it so that code analysis could skip it?

Thanks,
Richard

[gfraiteur]

Good idea.

I have planned it for RC 2, since you are not the first to report the problem.

http://www.postsharp.org/tracker/view.php?id=166

Gael

[dstar]

Was this implemented? I'm getting Code Analysis errors with the latest build and it does not look like the generated static constructors have [CompilerGenerated] attributes.

Thanks

[gfraiteur]

Yes, this was implemented, but it was insufficient.

It is necessary to perform code analysis before postsharp. Richard has sent a solution, but unfortunately I dont find the mail/page again.

Another solution is to disable PostSharp when you perform code analysis. Use the compilation constant SkipPostSharp for the build configuration including code analysis.

Gael

[dstar]

Unfortunately, I write API frameworks and often clients like to run FxCop against the compiled code. A fix that works for me is to create an empty static constructor with with a [CompilerGenerated] from System.Runtime.CompilerServices assembly.

I was just wondering if that could be done automatically. I used Reflector and there are no attributes on the automatically generated static constructors.

Thank you,
Dmitry

[gfraiteur]

You just pointed out a bug, thanks!

Yes, the static constructor should have the [CompilerGenerated] custom attribute.

Could you please file a bug?

Thanks,

Gael

[dstar]

In the last reply in the bug tracker you stated that "... if there is already a static constructor, it is not marked as CompilerGenerated (logically)..."

The code analysis warnings happen in classes that do not have an explicit static constructor. They just have static fields and properties. The fields are initialized inline.

Does it happen because .NET generates a static constructor behind the scenes?

Thanks,
Dmitry

[gfraiteur]

It would help to look at that class using ILDASM.
The class should have the specifier "beforefieldinit" if static fields are initialized "in-line".

You can compare the specifiers before and after postsharp (use the SkipPostSharp compilation symbol to disable postsharp).

Cheers,

Gael

[dstar]

You are correct. Here is the pre-PostSharp class signature reported by ILDASM by one of such classes:

Code: Select all

.class public auto ansi sealed beforefieldinit CompanyName.ProjectName.Api.ApiContext
       extends [mscorlib]System.Object
{
} // end of class CompanyName.ProjectName.Api.ApiContext

Here is the post-PostSharp signature:

.class public auto ansi sealed CompanyName.ProjectName.Api.ApiContext
       extends [mscorlib]System.Object
{
} // end of class CompanyName.ProjectName.Api.ApiContext

The simplest way to reproduce this problem is to define a singleton class such as:

    public sealed class ApiContext
    {
        #region Singleton Instance
        private static readonly ApiContext s_instance = new ApiContext();
        public static ApiContext Current
        {
            get
            {
                return s_instance;
            }
        }
        #endregion

        #region Private Constructor
        private ApiContext()
        {
        }
        #endregion

       #region Instance Methods
       .....
       #endregion
   }


Thanks,
Dmitry

[gfraiteur]

Dmitry,

I have performed unit tests with revision 347, including your sample, and it works correctly.

Gael

[dstar]

The latest 347 revision fixed the problem. Thanks a lot!

Regards,
Dmitry