I suggest you ...

Provide documentation and support for PostSharp SDK

PostSharp SDK is currently undocumented and unsupported. Please provide documentation and commercial support for the SDK.

21 votes
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Admingfraiteur (Admin, PostSharp Technologies) shared this idea  ·   ·  Admin →

    4 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • tomg commented  · 

        We currently have various IL-based customizations in our build process, using Mono.Cecil. It would be great to port these to PS SDK for enhanced performance, reliability and robustness, and to have the core infrastructure maintained by PS. At the moment we only risk using the PS SDK where the features provided by the PS SDK are too onerous to implement ourselves - for example, working with state machines. It's worth noting that we sometimes encounter a weaving scenario that we'd like to implement, but is not practical using our custom Cecil infrastructure; the PS SDK may well make some of those weaving scenarios viable to implement.

        Our customizations using Mono.Cecil include:

        - Injecting a module initializer (ours was implemented before it became a core PS feature).
        - Analysing and reordering specific method calls made from the module initializer. This is a vital part of our runtime semantic assembly resolution mechanism, which automatically provides the equivalent of semantic binding redirects for our own assemblies without relying upon app.config.
        - Stub rewriting to provide the equivalent of typeof for other code elements to avoid runtime reflection. Notably, this is useful when working with an obfuscator where traditional reflection becomes fragile or restricts the ability of the obfuscator to obfuscate. Versus runtime reflection, it's also more robust wrt refactoring, and is verified at compile time.
        - Performing assembly-wide analysis to detect elements that will be reflected upon by MEF, detect where naming collisions could occur when independent components (ie, plugins) are processed by an obfuscator, and inject ObfuscationAttribute to prevent the obfuscation that could lead to a naming collision.
        - Rewriting calls to NLog.GetCurrentClassLogger() to use the class name prior to obfuscation.
        - Attribute rewriting to support Delegate and Enum generic constraints.
        - Some other stub rewriting, typically to access desirable CIL features that are not supported by C#.

      • Bob Vale commented  · 

        See http://support.sharpcrafters.com/discussions/questions/1147-introduce-memberinterface-without-an-implementation-class

        Is it possible to dynamically add an interface to a class without having an implementing class?

        For example if I have a couple of interfaces:

        public interface IPerson {
        string Name {get;set;}
        }

        [AutoImplementInterface(typeof(IPerson))]
        public class Person {}
        I know I can make AutoImplementInterface a CompositionAspect to introduce the interface in GetPublicInterfaces, however I need a concrete type to provide the implementation with. What I'm looking for is a way to dynamically create this implementation at compile time. I understand that it could get extremely complicated when it comes to methods etc. for now I just want to create autoproperties for each property in the interface and throw a compile exception if the interface includes other items.

        If this is possible I'd also like to be able to introduce the members to the class too.

      Feedback and Knowledge Base