Search Results

Search found 60 results on 3 pages for 'postsharp'.

Page 1/3 | 1 2 3  | Next Page >

  • PostSharp causes error with .Net 4.0 when building

    - by Kev Hunter
    When trying to build a project which used PostSharp 1.5 on our Ci Server we get the following error; C:\Program Files\PostSharp 1.5\PostSharp-1.5.targets (261,5): error: Unhandled exception: PostSharp.CodeModel.BindingException: Cannot find the type 'System.Action`2' in assembly 'System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. at PostSharp.CodeModel.AssemblyEnvelope.GetTypeDefinition(String typeName, BindingOptions bindingOptions) at PostSharp.CodeModel.TypeRefDeclaration.GetTypeDefinition(BindingOptions bindingOptions) at PostSharp.CodeModel.TypeSpecDeclaration.GetTypeDefinition(BindingOptions bindingOptions) at PostSharp.Extensibility.Tasks.IndexGenericInstancesTask.Execute() at PostSharp.Extensibility.Project.ExecutePhase(String phase) at PostSharp.Extensibility.Project.Execute() at PostSharp.Extensibility.PostSharpObject.ExecuteProjects() at PostSharp.Extensibility.PostSharpObject.InvokeProject(ProjectInvocation projectInvocation) at PostSharp.MSBuild.PostSharpRemoteTask.Execute(PostSharpTaskParameters parameters, TaskLoggingHelper log) It has previously worked on .net 3.5. What's the best way to fix this?

    Read the article

  • PostSharp, Obfuscation, and IL

    - by Simon Cooper
    Aspect-oriented programming (AOP) is a relatively new programming paradigm. Originating at Xerox PARC in 1994, the paradigm was first made available for general-purpose development as an extension to Java in 2001. From there, it has quickly been adapted for use in all the common languages used today. In the .NET world, one of the primary AOP toolkits is PostSharp. Attributes and AOP Normally, attributes in .NET are entirely a metadata construct. Apart from a few special attributes in the .NET framework, they have no effect whatsoever on how a class or method executes within the CLR. Only by using reflection at runtime can you access any attributes declared on a type or type member. PostSharp changes this. By declaring a custom attribute that derives from PostSharp.Aspects.Aspect, applying it to types and type members, and running the resulting assembly through the PostSharp postprocessor, you can essentially declare 'clever' attributes that change the behaviour of whatever the aspect has been applied to at runtime. A simple example of this is logging. By declaring a TraceAttribute that derives from OnMethodBoundaryAspect, you can automatically log when a method has been executed: public class TraceAttribute : PostSharp.Aspects.OnMethodBoundaryAspect { public override void OnEntry(MethodExecutionArgs args) { MethodBase method = args.Method; System.Diagnostics.Trace.WriteLine( String.Format( "Entering {0}.{1}.", method.DeclaringType.FullName, method.Name)); } public override void OnExit(MethodExecutionArgs args) { MethodBase method = args.Method; System.Diagnostics.Trace.WriteLine( String.Format( "Leaving {0}.{1}.", method.DeclaringType.FullName, method.Name)); } } [Trace] public void MethodToLog() { ... } Now, whenever MethodToLog is executed, the aspect will automatically log entry and exit, without having to add the logging code to MethodToLog itself. PostSharp Performance Now this does introduce a performance overhead - as you can see, the aspect allows access to the MethodBase of the method the aspect has been applied to. If you were limited to C#, you would be forced to retrieve each MethodBase instance using Type.GetMethod(), matching on the method name and signature. This is slow. Fortunately, PostSharp is not limited to C#. It can use any instruction available in IL. And in IL, you can do some very neat things. Ldtoken C# allows you to get the Type object corresponding to a specific type name using the typeof operator: Type t = typeof(Random); The C# compiler compiles this operator to the following IL: ldtoken [mscorlib]System.Random call class [mscorlib]System.Type [mscorlib]System.Type::GetTypeFromHandle( valuetype [mscorlib]System.RuntimeTypeHandle) The ldtoken instruction obtains a special handle to a type called a RuntimeTypeHandle, and from that, the Type object can be obtained using GetTypeFromHandle. These are both relatively fast operations - no string lookup is required, only direct assembly and CLR constructs are used. However, a little-known feature is that ldtoken is not just limited to types; it can also get information on methods and fields, encapsulated in a RuntimeMethodHandle or RuntimeFieldHandle: // get a MethodBase for String.EndsWith(string) ldtoken method instance bool [mscorlib]System.String::EndsWith(string) call class [mscorlib]System.Reflection.MethodBase [mscorlib]System.Reflection.MethodBase::GetMethodFromHandle( valuetype [mscorlib]System.RuntimeMethodHandle) // get a FieldInfo for the String.Empty field ldtoken field string [mscorlib]System.String::Empty call class [mscorlib]System.Reflection.FieldInfo [mscorlib]System.Reflection.FieldInfo::GetFieldFromHandle( valuetype [mscorlib]System.RuntimeFieldHandle) These usages of ldtoken aren't usable from C# or VB, and aren't likely to be added anytime soon (Eric Lippert's done a blog post on the possibility of adding infoof, methodof or fieldof operators to C#). However, PostSharp deals directly with IL, and so can use ldtoken to get MethodBase objects quickly and cheaply, without having to resort to string lookups. The kicker However, there are problems. Because ldtoken for methods or fields isn't accessible from C# or VB, it hasn't been as well-tested as ldtoken for types. This has resulted in various obscure bugs in most versions of the CLR when dealing with ldtoken and methods, and specifically, generic methods and methods of generic types. This means that PostSharp was behaving incorrectly, or just plain crashing, when aspects were applied to methods that were generic in some way. So, PostSharp has to work around this. Without using the metadata tokens directly, the only way to get the MethodBase of generic methods is to use reflection: Type.GetMethod(), passing in the method name as a string along with information on the signature. Now, this works fine. It's slower than using ldtoken directly, but it works, and this only has to be done for generic methods. Unfortunately, this poses problems when the assembly is obfuscated. PostSharp and Obfuscation When using ldtoken, obfuscators don't affect how PostSharp operates. Because the ldtoken instruction directly references the type, method or field within the assembly, it is unaffected if the name of the object is changed by an obfuscator. However, the indirect loading used for generic methods was breaking, because that uses the name of the method when the assembly is put through the PostSharp postprocessor to lookup the MethodBase at runtime. If the name then changes, PostSharp can't find it anymore, and the assembly breaks. So, PostSharp needs to know about any changes an obfuscator does to an assembly. The way PostSharp does this is by adding another layer of indirection. When PostSharp obfuscation support is enabled, it includes an extra 'name table' resource in the assembly, consisting of a series of method & type names. When PostSharp needs to lookup a method using reflection, instead of encoding the method name directly, it looks up the method name at a fixed offset inside that name table: MethodBase genericMethod = typeof(ContainingClass).GetMethod(GetNameAtIndex(22)); PostSharp.NameTable resource: ... 20: get_Prop1 21: set_Prop1 22: DoFoo 23: GetWibble When the assembly is later processed by an obfuscator, the obfuscator can replace all the method and type names within the name table with their new name. That way, the reflection lookups performed by PostSharp will now use the new names, and everything will work as expected: MethodBase genericMethod = typeof(#kGy).GetMethod(GetNameAtIndex(22)); PostSharp.NameTable resource: ... 20: #kkA 21: #zAb 22: #EF5a 23: #2tg As you can see, this requires direct support by an obfuscator in order to perform these rewrites. Dotfuscator supports it, and now, starting with SmartAssembly 6.6.4, SmartAssembly does too. So, a relatively simple solution to a tricky problem, with some CLR bugs thrown in for good measure. You don't see those every day!

    Read the article

  • PostSharp, Obfuscation, and IL

    - by Simon Cooper
    Aspect-oriented programming (AOP) is a relatively new programming paradigm. Originating at Xerox PARC in 1994, the paradigm was first made available for general-purpose development as an extension to Java in 2001. From there, it has quickly been adapted for use in all the common languages used today. In the .NET world, one of the primary AOP toolkits is PostSharp. Attributes and AOP Normally, attributes in .NET are entirely a metadata construct. Apart from a few special attributes in the .NET framework, they have no effect whatsoever on how a class or method executes within the CLR. Only by using reflection at runtime can you access any attributes declared on a type or type member. PostSharp changes this. By declaring a custom attribute that derives from PostSharp.Aspects.Aspect, applying it to types and type members, and running the resulting assembly through the PostSharp postprocessor, you can essentially declare 'clever' attributes that change the behaviour of whatever the aspect has been applied to at runtime. A simple example of this is logging. By declaring a TraceAttribute that derives from OnMethodBoundaryAspect, you can automatically log when a method has been executed: public class TraceAttribute : PostSharp.Aspects.OnMethodBoundaryAspect { public override void OnEntry(MethodExecutionArgs args) { MethodBase method = args.Method; System.Diagnostics.Trace.WriteLine( String.Format( "Entering {0}.{1}.", method.DeclaringType.FullName, method.Name)); } public override void OnExit(MethodExecutionArgs args) { MethodBase method = args.Method; System.Diagnostics.Trace.WriteLine( String.Format( "Leaving {0}.{1}.", method.DeclaringType.FullName, method.Name)); } } [Trace] public void MethodToLog() { ... } Now, whenever MethodToLog is executed, the aspect will automatically log entry and exit, without having to add the logging code to MethodToLog itself. PostSharp Performance Now this does introduce a performance overhead - as you can see, the aspect allows access to the MethodBase of the method the aspect has been applied to. If you were limited to C#, you would be forced to retrieve each MethodBase instance using Type.GetMethod(), matching on the method name and signature. This is slow. Fortunately, PostSharp is not limited to C#. It can use any instruction available in IL. And in IL, you can do some very neat things. Ldtoken C# allows you to get the Type object corresponding to a specific type name using the typeof operator: Type t = typeof(Random); The C# compiler compiles this operator to the following IL: ldtoken [mscorlib]System.Random call class [mscorlib]System.Type [mscorlib]System.Type::GetTypeFromHandle( valuetype [mscorlib]System.RuntimeTypeHandle) The ldtoken instruction obtains a special handle to a type called a RuntimeTypeHandle, and from that, the Type object can be obtained using GetTypeFromHandle. These are both relatively fast operations - no string lookup is required, only direct assembly and CLR constructs are used. However, a little-known feature is that ldtoken is not just limited to types; it can also get information on methods and fields, encapsulated in a RuntimeMethodHandle or RuntimeFieldHandle: // get a MethodBase for String.EndsWith(string) ldtoken method instance bool [mscorlib]System.String::EndsWith(string) call class [mscorlib]System.Reflection.MethodBase [mscorlib]System.Reflection.MethodBase::GetMethodFromHandle( valuetype [mscorlib]System.RuntimeMethodHandle) // get a FieldInfo for the String.Empty field ldtoken field string [mscorlib]System.String::Empty call class [mscorlib]System.Reflection.FieldInfo [mscorlib]System.Reflection.FieldInfo::GetFieldFromHandle( valuetype [mscorlib]System.RuntimeFieldHandle) These usages of ldtoken aren't usable from C# or VB, and aren't likely to be added anytime soon (Eric Lippert's done a blog post on the possibility of adding infoof, methodof or fieldof operators to C#). However, PostSharp deals directly with IL, and so can use ldtoken to get MethodBase objects quickly and cheaply, without having to resort to string lookups. The kicker However, there are problems. Because ldtoken for methods or fields isn't accessible from C# or VB, it hasn't been as well-tested as ldtoken for types. This has resulted in various obscure bugs in most versions of the CLR when dealing with ldtoken and methods, and specifically, generic methods and methods of generic types. This means that PostSharp was behaving incorrectly, or just plain crashing, when aspects were applied to methods that were generic in some way. So, PostSharp has to work around this. Without using the metadata tokens directly, the only way to get the MethodBase of generic methods is to use reflection: Type.GetMethod(), passing in the method name as a string along with information on the signature. Now, this works fine. It's slower than using ldtoken directly, but it works, and this only has to be done for generic methods. Unfortunately, this poses problems when the assembly is obfuscated. PostSharp and Obfuscation When using ldtoken, obfuscators don't affect how PostSharp operates. Because the ldtoken instruction directly references the type, method or field within the assembly, it is unaffected if the name of the object is changed by an obfuscator. However, the indirect loading used for generic methods was breaking, because that uses the name of the method when the assembly is put through the PostSharp postprocessor to lookup the MethodBase at runtime. If the name then changes, PostSharp can't find it anymore, and the assembly breaks. So, PostSharp needs to know about any changes an obfuscator does to an assembly. The way PostSharp does this is by adding another layer of indirection. When PostSharp obfuscation support is enabled, it includes an extra 'name table' resource in the assembly, consisting of a series of method & type names. When PostSharp needs to lookup a method using reflection, instead of encoding the method name directly, it looks up the method name at a fixed offset inside that name table: MethodBase genericMethod = typeof(ContainingClass).GetMethod(GetNameAtIndex(22)); PostSharp.NameTable resource: ... 20: get_Prop1 21: set_Prop1 22: DoFoo 23: GetWibble When the assembly is later processed by an obfuscator, the obfuscator can replace all the method and type names within the name table with their new name. That way, the reflection lookups performed by PostSharp will now use the new names, and everything will work as expected: MethodBase genericMethod = typeof(#kGy).GetMethod(GetNameAtIndex(22)); PostSharp.NameTable resource: ... 20: #kkA 21: #zAb 22: #EF5a 23: #2tg As you can see, this requires direct support by an obfuscator in order to perform these rewrites. Dotfuscator supports it, and now, starting with SmartAssembly 6.6.4, SmartAssembly does too. So, a relatively simple solution to a tricky problem, with some CLR bugs thrown in for good measure. You don't see those every day!

    Read the article

  • PostSharp, Obfuscation, and IL

    - by simonc
    Aspect-oriented programming (AOP) is a relatively new programming paradigm. Originating at Xerox PARC in 1994, the paradigm was first made available for general-purpose development as an extension to Java in 2001. From there, it has quickly been adapted for use in all the common languages used today. In the .NET world, one of the primary AOP toolkits is PostSharp. Attributes and AOP Normally, attributes in .NET are entirely a metadata construct. Apart from a few special attributes in the .NET framework, they have no effect whatsoever on how a class or method executes within the CLR. Only by using reflection at runtime can you access any attributes declared on a type or type member. PostSharp changes this. By declaring a custom attribute that derives from PostSharp.Aspects.Aspect, applying it to types and type members, and running the resulting assembly through the PostSharp postprocessor, you can essentially declare 'clever' attributes that change the behaviour of whatever the aspect has been applied to at runtime. A simple example of this is logging. By declaring a TraceAttribute that derives from OnMethodBoundaryAspect, you can automatically log when a method has been executed: public class TraceAttribute : PostSharp.Aspects.OnMethodBoundaryAspect { public override void OnEntry(MethodExecutionArgs args) { MethodBase method = args.Method; System.Diagnostics.Trace.WriteLine( String.Format( "Entering {0}.{1}.", method.DeclaringType.FullName, method.Name)); } public override void OnExit(MethodExecutionArgs args) { MethodBase method = args.Method; System.Diagnostics.Trace.WriteLine( String.Format( "Leaving {0}.{1}.", method.DeclaringType.FullName, method.Name)); } } [Trace] public void MethodToLog() { ... } Now, whenever MethodToLog is executed, the aspect will automatically log entry and exit, without having to add the logging code to MethodToLog itself. PostSharp Performance Now this does introduce a performance overhead - as you can see, the aspect allows access to the MethodBase of the method the aspect has been applied to. If you were limited to C#, you would be forced to retrieve each MethodBase instance using Type.GetMethod(), matching on the method name and signature. This is slow. Fortunately, PostSharp is not limited to C#. It can use any instruction available in IL. And in IL, you can do some very neat things. Ldtoken C# allows you to get the Type object corresponding to a specific type name using the typeof operator: Type t = typeof(Random); The C# compiler compiles this operator to the following IL: ldtoken [mscorlib]System.Random call class [mscorlib]System.Type [mscorlib]System.Type::GetTypeFromHandle( valuetype [mscorlib]System.RuntimeTypeHandle) The ldtoken instruction obtains a special handle to a type called a RuntimeTypeHandle, and from that, the Type object can be obtained using GetTypeFromHandle. These are both relatively fast operations - no string lookup is required, only direct assembly and CLR constructs are used. However, a little-known feature is that ldtoken is not just limited to types; it can also get information on methods and fields, encapsulated in a RuntimeMethodHandle or RuntimeFieldHandle: // get a MethodBase for String.EndsWith(string) ldtoken method instance bool [mscorlib]System.String::EndsWith(string) call class [mscorlib]System.Reflection.MethodBase [mscorlib]System.Reflection.MethodBase::GetMethodFromHandle( valuetype [mscorlib]System.RuntimeMethodHandle) // get a FieldInfo for the String.Empty field ldtoken field string [mscorlib]System.String::Empty call class [mscorlib]System.Reflection.FieldInfo [mscorlib]System.Reflection.FieldInfo::GetFieldFromHandle( valuetype [mscorlib]System.RuntimeFieldHandle) These usages of ldtoken aren't usable from C# or VB, and aren't likely to be added anytime soon (Eric Lippert's done a blog post on the possibility of adding infoof, methodof or fieldof operators to C#). However, PostSharp deals directly with IL, and so can use ldtoken to get MethodBase objects quickly and cheaply, without having to resort to string lookups. The kicker However, there are problems. Because ldtoken for methods or fields isn't accessible from C# or VB, it hasn't been as well-tested as ldtoken for types. This has resulted in various obscure bugs in most versions of the CLR when dealing with ldtoken and methods, and specifically, generic methods and methods of generic types. This means that PostSharp was behaving incorrectly, or just plain crashing, when aspects were applied to methods that were generic in some way. So, PostSharp has to work around this. Without using the metadata tokens directly, the only way to get the MethodBase of generic methods is to use reflection: Type.GetMethod(), passing in the method name as a string along with information on the signature. Now, this works fine. It's slower than using ldtoken directly, but it works, and this only has to be done for generic methods. Unfortunately, this poses problems when the assembly is obfuscated. PostSharp and Obfuscation When using ldtoken, obfuscators don't affect how PostSharp operates. Because the ldtoken instruction directly references the type, method or field within the assembly, it is unaffected if the name of the object is changed by an obfuscator. However, the indirect loading used for generic methods was breaking, because that uses the name of the method when the assembly is put through the PostSharp postprocessor to lookup the MethodBase at runtime. If the name then changes, PostSharp can't find it anymore, and the assembly breaks. So, PostSharp needs to know about any changes an obfuscator does to an assembly. The way PostSharp does this is by adding another layer of indirection. When PostSharp obfuscation support is enabled, it includes an extra 'name table' resource in the assembly, consisting of a series of method & type names. When PostSharp needs to lookup a method using reflection, instead of encoding the method name directly, it looks up the method name at a fixed offset inside that name table: MethodBase genericMethod = typeof(ContainingClass).GetMethod(GetNameAtIndex(22)); PostSharp.NameTable resource: ... 20: get_Prop1 21: set_Prop1 22: DoFoo 23: GetWibble When the assembly is later processed by an obfuscator, the obfuscator can replace all the method and type names within the name table with their new name. That way, the reflection lookups performed by PostSharp will now use the new names, and everything will work as expected: MethodBase genericMethod = typeof(#kGy).GetMethod(GetNameAtIndex(22)); PostSharp.NameTable resource: ... 20: #kkA 21: #zAb 22: #EF5a 23: #2tg As you can see, this requires direct support by an obfuscator in order to perform these rewrites. Dotfuscator supports it, and now, starting with SmartAssembly 6.6.4, SmartAssembly does too. So, a relatively simple solution to a tricky problem, with some CLR bugs thrown in for good measure. You don't see those every day! Cross posted from Simple Talk.

    Read the article

  • Remove PostSharp reference after build?

    - by Simon
    Is is possible to get postsharp to remove references to the postsharp assemblies during a build? I have an exe i needs to have a very small footprint. I want to use some of the compile time weaving of postsharp but dont want to have to deploy PostSharp.dll with the exe.

    Read the article

  • Adding PostSharp to new projects, when it's installed for some projects in solution.

    - by Michael Freidgeim
    Recently I've posted my experience with installation of PostSharp Once PostSharp  is installed in  solution's packages folder for some project(s), I often need to add PostSharp to another project in the same solutionSection "Adding PostSharp to your project using PostSharp HQ" of documentation described the process quite well.I only want to add that the  actual location of  PostSharp HQ ( if it was installed from NuGet) is[solution root ]packages\PostSharp.2.1.7.15\tools\Release\PostSharp.HQ.exe.Also you need to ensure that the project is checked out,i.e. not readOnly.

    Read the article

  • Where is PostSharp.Public 1.5 DLL ?

    - by jfneis
    Fellows, I'm going crazy with looks like a really stupid problem. I'm trying to build a simple example using PostSharp as a log AOP utility. I've not installed PostSharp, and I don't want to, I want to reference the necessaries DLLs, change my .csproj and see everything working. Change the project and add references was kind of easy, byt just after adding the LogAttribute to a method I got two errors: Error 1 'Log4PostSharp.LogAttribute' is not an attribute class C:\Dev\LogWithPostsharp\LogWithPostsharpCmd\Program.cs 17 10 LogWithPostsharpCmd Error 2 The type 'PostSharp.Extensibility.MulticastAttribute' is defined in an assembly that is not referenced. You must add a reference to assembly 'PostSharp.Public, Version=1.5.0.0, Culture=neutral, PublicKeyToken=b13fd38b8f9c99d7'. C:\Dev\LogWithPostsharp\LogWithPostsharpCmd\Program.cs 18 22 LogWithPostsharpCmd The first error really looks like consequence of the second, but here is the deal: the PostSharp.Public.* simply doesn't exist in the downloaded .zip. Is there something that I'm not getting? Thank you in advance. Filipe

    Read the article

  • OnExit is not entering via PostSharp in asp.net project.

    - by mark smith
    Hi there, I have setup PostSharp and it appears to be working but i don't get it entering OnExit (i have logged setup to ensure it is working) ... Its a bit tricky to configure with asp.net - or is it just me ... I am using the 1.5 new version I basically have the following in my web.config and i had to add the SearchPath otherwise it can't find my assemblies <postsharp directory="C:\Program Files\PostSharp 1.5" trace="true"> <parameters> <!--<add name="parameter-name" value="parameter-value"/>--> </parameters> <searchPath> <!-- Always add the binary folder to the search path. --> <add name="bin" value="~\bin"/> </searchPath> </postsharp> I have set tracing on but what is strange to me is that it appears to build to the temp directory, maybe this is my issue, i am unsure .. hence i do F5 ... Is it possible to name the Output directory and output file?? As you can see it is editing a DLL in the temp dir so IIS is no longer in control so it doesn't execute it ??? Confused! :-) C:\Program Files\PostSharp 1.5\postsharp.exe "/P:Output=C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\mysitemvc-1.2\c2087140\8ac2dc93\postsharp\App_Web_04ae3ewy.dll" "/P:IntermediateDirectory=C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\mysitemvc-1.2\c2087140\8ac2dc93\postsharp " /P:CleanIntermediate=False /P:ReferenceDirectory=. /P:SignAssembly=False /P:PrivateKeyLocation= /P:ResolvedReferences= "/P:SearchPath=C:\Source Code\Visual Studio 2008\Projects\mysitemvc\mysitemvc\bin," /V /SkipAutoUpdate "C:\Program Files\PostSharp 1.5\Default.psproj" "C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\mysitemvc-1.2\c2087140\8ac2dc93\before-postsharp\App_Web_04ae3ewy.dll" PostSharp 1.5 [1.5.6.627] - Copyright (c) Gael Fraiteur, 2005-2009. info PS0035: C:\Windows\Microsoft.NET\Framework\v2.0.50727\ilasm.exe "C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\mysitemvc-1.2\c2087140\8ac2dc93\postsharp\App_Web_04ae3ewy.il" /QUIET /DLL /PDB "/RESOURCE=C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\mysitemvc-1.2\c2087140\8ac2dc93\postsharp\App_Web_04ae3ewy.res" "/OUTPUT=C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\mysitemvc-1.2\c2087140\8ac2dc93\postsharp\App_Web_04ae3ewy.dll" /SUBSYSTEM=3 /FLAGS=1 /BASE=18481152 /STACK=1048576 /ALIGNMENT=512 /MDV=v2.0.50727

    Read the article

  • Postsharp and log4net and log4postsharp

    - by Fadeproof
    I stumbled upon log4postsharp site which is a great tool that uses postsharp for injecting log4net statements into your code at compile time. The current version of log4postsharp uses Postsharp 1.0 which has some limitations. Does anyone know if there is somewhere a compiled version of log4postsharp that uses Postsharp 1.5 available?

    Read the article

  • PostSharp deployment to build machine- use Setup installation, not NuGet package.

    - by Michael Freidgeim
    PostSharp has well documented different methods of installation. I've chosen installing NuGet packages, because according to  Deploying PostSharp into a Source Repository NuGet is the easiest way to add PostSharp to a project without installing the product on every machine. However it didn't work well for me. I've added PostSharp NuGet package to one project in the solution.  When I wanted to use PostSharp in other project, Visual Studio tab showed that PostSharp is not enabled for this project I've added the NuGet package to the new project, which installed a new version of the package in the new Packages subfolder. When I wanted to refer PostSharp from the third project, I've ended up with another version of PostSharp installed. Additionally multiple versions of Diagnostics were created. It definitely causes confusion and errors.   More problems we experienced on build server. According to Using PostSharp on a Build Server "If you chose to deploy PostSharp in the source repository, it does not need to be installed specifically on the build server. " It didn't work on our build server. I kept getting errors "The "AddIns" parameter is not supported by the "PostSharp21" task." and "The "DisableSystemBindingPolicies" parameter is not supported by the "PostSharp21" task."   From my experience the only way to have the latest version of PostSharp working on the build server is to install it using Setup as described in Deploying PostSharp with the Setup Program     Gael acknowledged the issues with possible version conflicts. see http://support.sharpcrafters.com/discussions/problems/388-the-postsharp21-task-failed-unexpectedly

    Read the article

  • Can Spring.Net function as PostSharp?

    - by Alex K
    A few months back I've discovered PostSharp, and for a time, it was good. But then legal came back with an answer saying that they don't like the licence of the old versions. Then the department told me that 2.0's price was unacceptably high (for the number of seats we need)... I was extremely disapponted, but not disheartened. Can't be the only such framework, I thought. I kept looking for a replacement, but most of it was either dead, ill maintained (especially in documentation department), for academic use, or all of the above (I'm looking at you Aspect.Net) Then I've discovered Spring.Net, and for a time, it was good. I've been reading the documentation and it went on to paint what seemed to be a supperior picture of an AOP nirvana. No longer was I locked to attributes to mark where I wanted code interception to take place, but it could be configured in XML and changes to it didn't require re-compile. Great. Then I looked at the samples and saw the following, in every single usage scenario: // Create AOP proxy using Spring.NET IoC container. IApplicationContext ctx = ContextRegistry.GetContext(); ICommand command = (ICommand)ctx["myServiceCommand"]; command.Execute(); if (command.IsUndoCapable) { command.UnExecute(); } Why must the first two lines of code exist? It ruins everything. This means I cannot simply provide a user with a set of aspects and attributes or XML configs that they can use by sticking appropriate attributes on the appropriate methods/classes/etc or editing the match pattern in XML. They have to modify their program logic to make this work! Is there a way to make Spring.Net behave as PostSharp in this case? (i.e. user only needs to add attributes/XML config, not edit content of any methods. Alternatively, is there a worthy and functioning alternative to PostSharp? I've seen a few question titled like this on SO, but none of them were actually looking to replace PostSharp, they only wanted to supplement its functionality. I need full replacement.

    Read the article

  • PostSharp , PDB Debugging and Referenced Assemblies ...

    - by Anil Bisnoi
    When using PostSharp with a Referenced Assembly with proper PDB info( checked with chkmatch), it seems strange that the debug info gets lost by VStudio build and post compile process and I get the following error by using chkmatch to compare the assembly after the vstudio build. Error: Debug information not found in the executable. So it doesn't step into for debugging into this assembly. Does Post Sharp properly writes back the Assemblies without destroying the PDB location offset info as I saw no valid offset info in the written back into DLL by PostSharp using Hex Editor and What's the workaround for this ? Thx Anil Bisnoi

    Read the article

  • Error when compiling c# project in VS2012 when using Postsharp

    - by Thewads
    I am currently working on a project where we were wanting to add PostSharp functionality. I have set up my Postsharp attribute as so [Serializable] public class NLogTraceAttribute : OnMethodBoundaryAspect { private readonly string _logLevel; ILogger logger; public NLogTraceAttribute(string logLevel) { _logLevel = logLevel; logger = new Logger("TraceAttribute"); } public override void OnEntry(MethodExecutionArgs args) { LogAction("Enter", args); } public override void OnExit(MethodExecutionArgs args) { LogAction("Leave", args); } private void LogAction(string action, MethodExecutionArgs args) { var argumentsInfo = args.GetArgumentsInfo(); logger.Log(_logLevel, "{0}: {1}.{2}{3}", action, args.Method.DeclaringType.Name, args.Method.Name, argumentsInfo); } } and trying to use it as [NLogTrace(NLogLevel.Debug)] However when compiling the project I am getting the following error: Error 26 Cannot serialize the aspects: Type 'NLog.Logger' in Assembly 'NLog, Version=2.0.0.0, Culture=neutral, PublicKeyToken=5120e14c03d0593c' is not marked as serializable.. Any help would be appreciated

    Read the article

  • Enterprise Library Logging / Exception handling and Postsharp

    - by subodhnpushpak
    One of my colleagues came-up with a unique situation where it was required to create log files based on the input file which is uploaded. For example if A.xml is uploaded, the corresponding log file should be A_log.txt. I am a strong believer that Logging / EH / caching are cross-cutting architecture aspects and should be least invasive to the business-logic written in enterprise application. I have been using Enterprise Library for logging / EH (i use to work with Avanade, so i have affection towards the library!! :D ). I have been also using excellent library called PostSharp for cross cutting aspect. Here i present a solution with and without PostSharp all in a unit test. Please see full source code at end of the this blog post. But first, we need to tweak the enterprise library so that the log files are created at runtime based on input given. Below is Custom trace listner which writes log into a given file extracted out of Logentry extendedProperties property. using Microsoft.Practices.EnterpriseLibrary.Common.Configuration; using Microsoft.Practices.EnterpriseLibrary.Logging.Configuration; using Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners; using Microsoft.Practices.EnterpriseLibrary.Logging; using System.IO; using System.Text; using System; using System.Diagnostics;   namespace Subodh.Framework.Logging { [ConfigurationElementType(typeof(CustomTraceListenerData))] public class LogToFileTraceListener : CustomTraceListener {   private static object syncRoot = new object();   public override void TraceData(TraceEventCache eventCache, string source, TraceEventType eventType, int id, object data) {   if ((data is LogEntry) & this.Formatter != null) { WriteOutToLog(this.Formatter.Format((LogEntry)data), (LogEntry)data); } else { WriteOutToLog(data.ToString(), (LogEntry)data); } }   public override void Write(string message) { Debug.Print(message.ToString()); }   public override void WriteLine(string message) { Debug.Print(message.ToString()); }   private void WriteOutToLog(string BodyText, LogEntry logentry) { try { //Get the filelocation from the extended properties if (logentry.ExtendedProperties.ContainsKey("filelocation")) { string fullPath = Path.GetFullPath(logentry.ExtendedProperties["filelocation"].ToString());   //Create the directory where the log file is written to if it does not exist. DirectoryInfo directoryInfo = new DirectoryInfo(Path.GetDirectoryName(fullPath));   if (directoryInfo.Exists == false) { directoryInfo.Create(); }   //Lock the file to prevent another process from using this file //as data is being written to it.   lock (syncRoot) { using (FileStream fs = new FileStream(fullPath, FileMode.Append, FileAccess.Write, FileShare.Write, 4096, true)) { using (StreamWriter sw = new StreamWriter(fs, Encoding.UTF8)) { Log(BodyText, sw); sw.Close(); } fs.Close(); } } } } catch (Exception ex) { throw new LoggingException(ex.Message, ex); } }   /// <summary> /// Write message to named file /// </summary> public static void Log(string logMessage, TextWriter w) { w.WriteLine("{0}", logMessage); } } }   The above can be “plugged into” the code using below configuration <loggingConfiguration name="Logging Application Block" tracingEnabled="true" defaultCategory="Trace" logWarningsWhenNoCategoriesMatch="true"> <listeners> <add listenerDataType="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.CustomTraceListenerData, Microsoft.Practices.EnterpriseLibrary.Logging, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" traceOutputOptions="None" filter="All" type="Subodh.Framework.Logging.LogToFileTraceListener, Subodh.Framework.Logging, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" name="Subodh Custom Trace Listener" initializeData="" formatter="Text Formatter" /> </listeners> Similarly we can use PostSharp to expose the above as cross cutting aspects as below using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Reflection; using PostSharp.Laos; using System.Diagnostics; using GC.FrameworkServices.ExceptionHandler; using Subodh.Framework.Logging;   namespace Subodh.Framework.ExceptionHandling { [Serializable] public sealed class LogExceptionAttribute : OnExceptionAspect { private string prefix; private MethodFormatStrings formatStrings;   // This field is not serialized. It is used only at compile time. [NonSerialized] private readonly Type exceptionType; private string fileName;   /// <summary> /// Declares a <see cref="XTraceExceptionAttribute"/> custom attribute /// that logs every exception flowing out of the methods to which /// the custom attribute is applied. /// </summary> public LogExceptionAttribute() { }   /// <summary> /// Declares a <see cref="XTraceExceptionAttribute"/> custom attribute /// that logs every exception derived from a given <see cref="Type"/> /// flowing out of the methods to which /// the custom attribute is applied. /// </summary> /// <param name="exceptionType"></param> public LogExceptionAttribute( Type exceptionType ) { this.exceptionType = exceptionType; }   public LogExceptionAttribute(Type exceptionType, string fileName) { this.exceptionType = exceptionType; this.fileName = fileName; }   /// <summary> /// Gets or sets the prefix string, printed before every trace message. /// </summary> /// <value> /// For instance <c>[Exception]</c>. /// </value> public string Prefix { get { return this.prefix; } set { this.prefix = value; } }   /// <summary> /// Initializes the current object. Called at compile time by PostSharp. /// </summary> /// <param name="method">Method to which the current instance is /// associated.</param> public override void CompileTimeInitialize( MethodBase method ) { // We just initialize our fields. They will be serialized at compile-time // and deserialized at runtime. this.formatStrings = Formatter.GetMethodFormatStrings( method ); this.prefix = Formatter.NormalizePrefix( this.prefix ); }   public override Type GetExceptionType( MethodBase method ) { return this.exceptionType; }   /// <summary> /// Method executed when an exception occurs in the methods to which the current /// custom attribute has been applied. We just write a record to the tracing /// subsystem. /// </summary> /// <param name="context">Event arguments specifying which method /// is being called and with which parameters.</param> public override void OnException( MethodExecutionEventArgs context ) { string message = String.Format("{0}Exception {1} {{{2}}} in {{{3}}}. \r\n\r\nStack Trace {4}", this.prefix, context.Exception.GetType().Name, context.Exception.Message, this.formatStrings.Format(context.Instance, context.Method, context.GetReadOnlyArgumentArray()), context.Exception.StackTrace); if(!string.IsNullOrEmpty(fileName)) { ApplicationLogger.LogException(message, fileName); } else { ApplicationLogger.LogException(message, Source.UtilityService); } } } } To use the above below is the unit test [TestMethod] [ExpectedException(typeof(NotImplementedException))] public void TestMethod1() { MethodThrowingExceptionForLog(); try { MethodThrowingExceptionForLogWithPostSharp(); } catch (NotImplementedException ex) { throw ex; } }   private void MethodThrowingExceptionForLog() { try { throw new NotImplementedException(); } catch (NotImplementedException ex) { // create file and then write log ApplicationLogger.TraceMessage("this is a trace message which will be logged in Test1MyFile", @"D:\EL\Test1Myfile.txt"); ApplicationLogger.TraceMessage("this is a trace message which will be logged in YetAnotherTest1Myfile", @"D:\EL\YetAnotherTest1Myfile.txt"); } }   // Automatically log details using attributes // Log exception using attributes .... A La WCF [FaultContract(typeof(FaultMessage))] style] [Log(@"D:\EL\Test1MyfileLogPostsharp.txt")] [LogException(typeof(NotImplementedException), @"D:\EL\Test1MyfileExceptionPostsharp.txt")] private void MethodThrowingExceptionForLogWithPostSharp() { throw new NotImplementedException(); } The good thing about the approach is that all the logging and EH is done at centralized location controlled by PostSharp. Of Course, if some other library has to be used instead of EL, it can easily be plugged in. Also, the coder ARE ONLY involved in writing business code in methods, which makes code cleaner. Here is the full source code. The third party assemblies provided are from EL and PostSharp and i presume you will find these useful. Do let me know your thoughts / ideas on the same. Technorati Tags: PostSharp,Enterprize library,C#,Logging,Exception handling

    Read the article

  • Postsharp installer bug: .Net 2.0 not presented

    - by HeavyWave
    There is an issue with PostSharp 1.5 and 2.0 that won't let you install it on the Windows 7 machine with the error message ".NET Framework 2.0 is not present on this computer". To work around the issue you have to run the installer while being logged in with Administrator account. Not Admin group and not "run as Administrator", you have to be logged in with the Administrator account. Hope that helps, if someone has the same issue.

    Read the article

  • PostSharp OnMethodBoundaryAspect

    - by José F. Romaniello
    I'm working on an aspect with postsharp 1.5 and OnMethodBoundaryAspect. I want my aspect have the following behavior by default: 1-If the attribute is used at class level the aspect is applied only on PUBLIC methods. 2-The user of the aspect can put the aspect in a private or protected method. If I use this [MulticastAttributeUsage( MulticastTargets.Method, TargetMemberAttributes = MulticastAttributes.Public)] the point 1 works, but the case 2 doesn't even build becaue is incompatible. Then I tried to use: AttributeTargetTypeAttributes = MulticastAttributes.Public; in the constructor of the aspect, but doesn't work. Thank you very much in advance.

    Read the article

  • PostSharp OnExceptionAspect not working as expected

    - by Rune Sundling
    Created a simple class to test out the OnExceptionAspect in PostSharp. [Serializable] [AttributeUsage(AttributeTargets.Method | AttributeTargets.Class)] public class ExceptionSwallower : OnExceptionAspect { public override void OnException(MethodExecutionEventArgs eventArgs) { eventArgs.FlowBehavior = FlowBehavior.Return; base.OnException(eventArgs); } } Added the attribute to a method [ExceptionSwallower] public void SomeMethod() { throw new Exception(); } and invoked it. However, the exception is not actually swallowed, which seems odd. I haven't been able to find any similar problems, so I expect there is some minor thing I haven't gotten right. Anyone?

    Read the article

  • PostSharp when using DataContractSerializer?

    - by Dan Bryant
    I have an Aspect that implements INotifyPropertyChanged on a class. The aspect includes the following: [OnLocationSetValueAdvice, MethodPointcut("SelectProperties")] public void OnPropertySet(LocationInterceptionArgs args) { var currentValue = args.GetCurrentValue(); bool alreadyEqual = (currentValue == args.Value); // Call the setter args.ProceedSetValue(); // Invoke method OnPropertyChanged (ours, the base one, or the overridden one). if (!alreadyEqual) OnPropertyChangedMethod.Invoke(args.Location.Name); } This works fine when I instantiate the class normally, but I run into problems when I deserialize the class using a DataContractSerializer. This bypasses the constructor, which I'm guessing interferes with the way that PostSharp sets itself up. This ends up causing a NullReferenceException in an intercepted property setter, but before it has called the custom OnPropertySet, so I'm guessing it interferes with setting up the LocationInterceptionArgs. Has anyone else encountered this problem? Is there a way I can work around it? I did some more research and discovered I can fix the issue by doing this: [OnDeserializing] private void OnDeserializing(StreamingContext context) { AspectUtilities.InitializeCurrentAspects(); } I thought, okay, that's not too bad, so I tried to do this in my Aspect: private IEnumerable<MethodInfo> SelectDeserializing(Type type) { return type.GetMethods(BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.Public).Where( t => t.IsDefined(typeof (OnDeserializingAttribute), false)); } [OnMethodEntryAdvice, MethodPointcut("SelectDeserializing")] public void OnMethodEntry(MethodExecutionArgs args) { AspectUtilities.InitializeCurrentAspects(); } Unfortunately, even though it intercepts the method properly, it doesn't work. I'm thinking the call to InitializeCurrentAspects isn't getting transformed properly, since it's now inside the Aspect rather than directly inside the aspect-enhanced class. Is there a way I can cleanly automate this so that I don't have to worry about calling this on every class that I want to have the Aspect?

    Read the article

  • Suppressing PostSharp Multicast with Attribute

    - by Dan Bryant
    I've recently started experimenting with PostSharp and I found a particularly helpful aspect to automate implementation of INotifyPropertyChanged. You can see the example here. The basic functionality is excellent (all properties will be notified), but there are cases where I might want to suppress notification. For instance, I might know that a particular property is set once in the constructor and will never change again. As such, there is no need to emit the code for NotifyPropertyChanged. The overhead is minimal when classes are not frequently instantiated and I can prevent the problem by switching from an automatically generated property to a field-backed property and writing to the field. However, as I'm learning this new tool, it would be helpful to know if there is a way to tag a property with an attribute to suppress the code generation. I'd like to be able to do something like this: [NotifyPropertyChanged] public class MyClass { public double SomeValue { get; set; } public double ModifiedValue { get; private set; } [SuppressNotify] public double OnlySetOnce { get; private set; } public MyClass() { OnlySetOnce = 1.0; } }

    Read the article

  • Postsharp duplicate attribute?

    - by yodaj007
    Can anyone explain why I'm getting this compile error? Duplicate 'Rad.Core.Aop.MethodArgumentValidation' attribute E:\Scripting\Rad.Core\Properties\AssemblyInfo.cs This is the code: [assembly: Rad.Core.Aop.MethodArgumentValidation(AttributeTargetTypes="Rad.*", AttributePriority=1)] [assembly: Rad.Core.Aop.MethodArgumentValidation(AttributeTargetTypes = "Rad.Core.Aop.*", AttributePriority = 2, AttributeExclude=true)] Here is the declaration of the aspect: [Serializable] [AttributeUsage(AttributeTargets.Assembly | AttributeTargets.Class | AttributeTargets.Method | AttributeTargets.Property)] [MulticastAttributeUsage(MulticastTargets.Method, AllowMultiple=true)] public class MethodArgumentValidationAttribute : OnMethodInvocationAspect { ... } It looks like I'm following this example: http://www.sharpcrafters.com/blog/post/multicasting-of-custom-attributes.aspx Can anyone help?

    Read the article

  • AssemblyLoadException in postsharp, problem with arguments from referenced DLLs?

    - by RodH257
    I'm just starting out with postsharp/AOP. I want to make some instrumentation for C# to track the usage of some addins that I write for a peice of software. I am trying to use the OnMethodBoundaryAspect class to take note of the values of some of the parameters when the method is called. Those parameters are types which are referenced in an external DLL. When I add my attribute to the method, the project won't build, I get the following error Error 2 Unhandled exception (2.0.5.1204, 64 bit, CLR 2.0, Release): PostSharp.CodeModel.AssemblyLoadException: Error while loading the assembly "C:\Program Files\Autodesk\Revit Structure 2011\Program\RevitAPI.dll": Could not load file or assembly 'revitapi, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515) The REvitAPI.dll is the file with the type in it. I've also tested just adding the attribute to the project but not applying it to any methods, this also causes the error. So it appears its not related to the method parameter types itself, but merely the existence of this DLL. Has anyone come across this issue before, or can anyone point me in the right direction of where to get some more info on this?

    Read the article

  • Is this fix to "PostSharp complains about CA1800:DoNotCastUnnecessarily" the best one?

    - by cad
    This question is about "is" and "as" in casting and about CA1800 PostSharp rule. I want to know if the solution I thought is the best one possible or if it have any problem that I can't see. I have this code (named OriginaL Code and reduced to the minimum relevant). The function ValidateSubscriptionLicenceProducts try to validate a SubscriptionLicence (that could be of 3 types: Standard,Credit and TimeLimited ) by casting it and checking later some stuff (in //Do Whatever). PostSharp complains about CA1800:DoNotCastUnnecessarily. The reason is that I am casting two times the same object to the same type. This code in best case will cast 2 times (if it is a StandardLicence) and in worst case 4 times (If it is a TimeLimited Licence). I know is possible to invalidate rule (it was my first approach), as there is no big impact in performance here, but I am trying a best approach. //Version Original Code //Min 2 casts, max 4 casts //PostSharp Complains about CA1800:DoNotCastUnnecessarily private void ValidateSubscriptionLicenceProducts(SubscriptionLicence licence) { if (licence is StandardSubscriptionLicence) { // All products must have the same products purchased List<StandardSubscriptionLicenceProduct> standardProducts = ((StandardSubscriptionLicence)licence).SubscribedProducts; //Do whatever } else if (licence is CreditSubscriptionLicence) { // All products must have a valid Credit entitlement & Credit interval List<CreditSubscriptionLicenceProduct> creditProducts = ((CreditSubscriptionLicence)licence).SubscribedProducts; //Do whatever } else if (licence is TimeLimitedSubscriptionLicence) { // All products must have a valid Time entitlement // All products must have a valid Credit entitlement & Credit interval List<TimeLimitedSubscriptionLicenceProduct> creditProducts = ((TimeLimitedSubscriptionLicence)licence).SubscribedProducts; //Do whatever } else throw new InvalidSubscriptionLicenceException("Invalid Licence type"); //More code... } This is Improved1 version using "as". Do not complain about CA1800 but the problem is that it will cast always 3 times (if in the future we have 30 or 40 types of licences it could perform bad) //Version Improve 1 //Minimum 3 casts, maximum 3 casts private void ValidateSubscriptionLicenceProducts(SubscriptionLicence licence) { StandardSubscriptionLicence standardLicence = Slicence as StandardSubscriptionLicence; CreditSubscriptionLicence creditLicence = Clicence as CreditSubscriptionLicence; TimeLimitedSubscriptionLicence timeLicence = Tlicence as TimeLimitedSubscriptionLicence; if (Slicence == null) { // All products must have the same products purchased List<StandardSubscriptionLicenceProduct> standardProducts = Slicence.SubscribedProducts; //Do whatever } else if (Clicence == null) { // All products must have a valid Credit entitlement & Credit interval List<CreditSubscriptionLicenceProduct> creditProducts = Clicence.SubscribedProducts; //Do whatever } else if (Tlicence == null) { // All products must have a valid Time entitlement // All products must have a valid Credit entitlement & Credit interval List<TimeLimitedSubscriptionLicenceProduct> creditProducts = Tlicence.SubscribedProducts; //Do whatever } else throw new InvalidSubscriptionLicenceException("Invalid Licence type"); //More code... } But later I thought in a best one. This is the final version I am using. //Version Improve 2 // Min 1 cast, Max 3 Casts // Do not complain about CA1800:DoNotCastUnnecessarily private void ValidateSubscriptionLicenceProducts(SubscriptionLicence licence) { StandardSubscriptionLicence standardLicence = null; CreditSubscriptionLicence creditLicence = null; TimeLimitedSubscriptionLicence timeLicence = null; if (StandardSubscriptionLicence.TryParse(licence, out standardLicence)) { // All products must have the same products purchased List<StandardSubscriptionLicenceProduct> standardProducts = standardLicence.SubscribedProducts; //Do whatever } else if (CreditSubscriptionLicence.TryParse(licence, out creditLicence)) { // All products must have a valid Credit entitlement & Credit interval List<CreditSubscriptionLicenceProduct> creditProducts = creditLicence.SubscribedProducts; //Do whatever } else if (TimeLimitedSubscriptionLicence.TryParse(licence, out timeLicence)) { // All products must have a valid Time entitlement List<TimeLimitedSubscriptionLicenceProduct> timeProducts = timeLicence.SubscribedProducts; //Do whatever } else throw new InvalidSubscriptionLicenceException("Invalid Licence type"); //More code... } //Example of TryParse in CreditSubscriptionLicence public static bool TryParse(SubscriptionLicence baseLicence, out CreditSubscriptionLicence creditLicence) { creditLicence = baseLicence as CreditSubscriptionLicence; if (creditLicence != null) return true; else return false; } It requires a change in the classes StandardSubscriptionLicence, CreditSubscriptionLicence and TimeLimitedSubscriptionLicence to have a "tryparse" method (copied below in the code). This version I think it will cast as minimum only once and as maximum three. What do you think about improve 2? Is there a best way of doing it?

    Read the article

  • asp.net mvc log4postsharp

    - by mike
    Hi Iam trying to use log4post sharp for logging purposes, As far as Iam aware I have followed the instructions to get this up and running, I have not installed postsharp, rather I got the library files and midified my cs proj file to target those file, I have also tried installing postsharp on my machine. In either case I end up with this error Error 5 The plug-in "Log4PostSharp" required by the type "Log4PostSharp.LogAttribute" was not found. I have tried googling this and it seems there is no trace of this issue anywhere on the web. One difference between my implementation with other examples is that the postsharp dll that they use is PostSharp.public, mine is just PostSharp. I have tried searching for the former dll but cannot find it anywhere, the download only contains PostSharp.dll. I feel this may be the issue as I have followd all the insturctions to the letter to get this up and running. Any Ideas People?

    Read the article

1 2 3  | Next Page >