|
|
|
Community Member
|
|
Hi
I'm a new PostSharp'er and I am interested in using Log4PostSharp with the latest CTP release. I got the code from svn but on compiling I'm encountering a problem due to missing types that are now not available in PostSharp 1.5. The specific type that is missing is the CustomAttributeDictionaryTask. Are there any plans to update this to work with v1.5? If not, can someone point me in the right direction for getting this to work with the CTP.
Thanks
Carel
|
|
|
|
|
Michal Dabrowski
Community Member
|
|
Hi,
I wasn't aware of this issue. I will recompile the Log4PostSharp against the PostSharp 1.5 in few days.
|
|
|
|
|
Gael Fraiteur
SharpCrafters
|
|
Yup, there are some incompatibilities. It may be necessary to maintain two branches of the project.
-gael
|
|
|
|
|
Community Member
|
|
Hi
Could you please notify in this thread when you build it against 1.5?
Thanks
Adiel
|
|
|
|
|
Community Member
|
|
|
I would also be interested in this.
|
|
|
|
|
Community Member
|
|
|
|
|
|
Community Member
|
|
|
|
|
|
Gael Fraiteur
SharpCrafters
|
|
Markell,
Do you want me to give you access to the source repository?
-gael
|
|
|
|
|
Community Member
|
|
Sure, I will be glad to.
How do I commit our modifications?
|
|
|
|
|
Gael Fraiteur
SharpCrafters
|
|
You now have access to <!-- m --><a class="postlink" href="http://code.google.com/p/postsharp-user-plugins">http://code.google.com/p/postsharp-user-plugins</a><!-- m -->.
Use an SVN client (TortoiseSVN) to upload your changes.
Do it this way:
1. Check out the project using the HTTPS protocol (HTTP would give you read-only access).
2. Branch trunk/1.0/Log4PostSharp into trunk/1.5/Log4PostSharp
2. Using WinMerge, merge your changes into your working copy of trunk/1.5/Log4PostSharp.
3. Commit trunk/1.0/Log4PostSharp to the source control.
-gael
|
|
|
|
|
Community Member
|
|
I will surely do so, however, there is one file in PostSharp.Core that have a tiny bug in it, which must be fixed to support our modifications.
Here is the differences as unified diff (mind the spaces):
[size=85]Index: C:/Dev/internal/GenericParameterTypeSignature.cs
===================================================================
--- C:/Dev/internal/GenericParameterTypeSignature.cs (revision 80)
+++ C:/Dev/internal/GenericParameterTypeSignature.cs (revision 83)
@@ -265,7 +265,7 @@
switch ( this.kind )
{
case GenericParameterKind.Method:
- if ( genericMethodArguments == null )
+ if ( genericMethodArguments == null || genericMethodArguments.Length == 0 )
{
reflectionType = null;
}
@@ -276,7 +276,7 @@
break;
case GenericParameterKind.Type:
- if ( genericTypeArguments == null )
+ if ( genericTypeArguments == null || genericTypeArguments.Length == 0 )
{
reflectionType = null;
}
[/size]
Without this fix, using the message formatters we haved added to the LogAttribute crashes the instrumentation process.
Do you want me to commit our changes now anyway?
|
|
|
|
|
Community Member
|
|
OK, I have committed to the trunk.
The final commit log message is:
1. Upgrade to PostSharp 1.5
2. Added LoggerPolicyAttribute and LoggerAttribute
3. Added {inparamvalues} and {outparamvalues}
4. Added LogAttribute.IncludeParamName property.
5. Changed the default values of the LogAttribute properties.
We have changed the default values, so that specifying just [Log] produces reasonable log message. However, the GenericParameterTypeSignature.cs file needs to be fixed, until then using the new version will crash.
Regards,
|
|
|
|
|
Community Member
|
|
|
One more thing. A new project is added to the Log4PostSharp solution - an mstest project unit testing the new attributes - LoggerAttribute and LoggerPolicyAttribute.
|
|
|
|
|
Gael Fraiteur
SharpCrafters
|
|
Thank you for this work!
Please report the problem with GenericParameterTypeSignature.cs to the issue tracker otherwise I'll forget about it.
Thanks,
-gael
|
|
|
|
|
Community Member
|
|
|
|
|
|
Community Member
|
|
Gael, thanks for the fix. Now I know how to do it efficiently.
However, the old code, albeit inefficient, was still legitimate and the fact that it crashed indicates some kind of a problem.
Anyway, we have fixed a bug in the LoggerPolicyAttribute, which prevented it from being multicast on all the types in an assembly. The bug was that we instrumented the special <Module> type, which was not good. It is fixed now, I have committed the fix.
Hope it is OK.
|
|
|
|
|
Gael Fraiteur
SharpCrafters
|
|
|
Gael, thanks for the fix. Now I know how to do it efficiently.
However, the old code, albeit inefficient, was still legitimate and the fact that it crashed indicates some kind of a problem.
No, the code was wrong. Either you pass null to this method, either you pass a valid array of types of the proper size (i.e. the calling code should have passed null instead of EmptyTypeArray). This is by design. Maybe just poorly documented.
Anyway, we have fixed a bug in the LoggerPolicyAttribute, which prevented it from being multicast on all the types in an assembly. The bug was that we instrumented the special <Module> type, which was not good. It is fixed now, I have committed the fix.
Hope it is OK.
It should be.
I could blog about this plug-in being upgraded once you feel it's ready.
-gael
|
|
|
|
|
Community Member
|
|
Oh, I get it now. I guess I was fooled by the fact that passing null did not throw ArgumentNullException and it actually worked in some scenarios. Well, thanks for the explanations.
I think we are through with our modifications. I have just committed several unit tests for the LogAttribute to unit test the new templates.
So, go ahead.
|
|
|
|
|
Gael Fraiteur
SharpCrafters
|
|
Could you post a build to <!-- m --><a class="postlink" href="http://code.google.com/p/postsharp-user-plugins/downloads/list">http://code.google.com/p/postsharp-user ... loads/list</a><!-- m --> before I blog?
Thanks.
-g
|
|
|
|
|
Community Member
|
|
Hi Gael.
I have built and tested everything. However, Log4PostSharp assemblies are not signed at all.
I have never downloaded PostSharp binaries, but I guess that you make them strongly signed as opposed to delay signed as in the source distribution in order to preserve the same public key.
I think the same should be true for the Log4PostSharp assemblies. So, unless I should delay sign them with the PostSharp public key I need a dedicated Log4PostSharp public key. I will build the binaries and you will complete their signing with the private key your will own.
Does it make any sense?
|
|
Contacts
| Terms of Use |
Privacy Policy