C#, attributes, and reverse engineering

[neutronic]

I have stumbled accross an interesting thing.

In my current project we are using Enterprise Services in DotNet and C#.

When I got to reverse engineer my C# code,  EA does not pick up the class, that is sprinkled with Enterprise Services attributes.

Code bit:
[System.EnterpriseServices.Transaction(TransactionOption.NotSupported, Isolation=TransactionIsolationLevel.Serializable, Timeout=30)]
     [ComponentAccessControl]      // Enable object level acess checks
     [SecureMethod]                        // Enable Method level access checks
     public class MyServicedComponent : ServicedComponent

[SecurityRole("PrivateFunction")]
           public System.Data.DataTable GetStuff(int id)
           {
                          return null;
                 
           }

Is this a known thing, or am I doing something wrong?

EA simply does not reverse engineer it as C#, and when using the Java tool, it does create a class but the attributes become the method if I remember correctly.

It would be awsome if somebody could tell me how to get around this, short of removing all the attributes.

[DMT]

It would be nice to know if there is any support for FORWARD engineering of c# attributes as well...of if it's planned, perhaps using tagged values.

[benc]

Hi Neutronic,

Using your sample code (and inserting the missing open and close braces {}, for the class), I was unable to replicate the error.  I was using Build 611 on XP.

The class was created, though the attributes were omitted (the ability to import the attributes is a planned addition to EA).  Perhaps there's a step I'm missing in trying to reproduce the error .. let me know.

DMT: Forward engineering C# attributes will soon be a possibility with code generation templates.  Yes, attributes will be represented using tagged values.  You will be able test for the existence of a particular tagged value and customize the code accordingly.

I hope this will prove useful.

Regards,
Ben

[neutronic]

Interesting I went back and made another attempt and again ti failed, but armed with your information I started removing and inserting bits of code in the file.

If I removed all the comments I found that the code was reverse engineered fine. Thus my original assumption was wrong.

I believe now, that the reason it was not reverse engineered was an inline comment in the "using"
section of the source code

Example:

using System.Runtime.InteropServices;      // This is only used to force the introp guid to be the one specified in the interface/class attribute

namespace MDCH.EnterprisePortal.Applications.LotStatusReport.BusinessObjects
{
     /// <summary>
     /// This is a Serviced component security wrapper for the  object.
     /// For comment on the


This is not a big deal and very easy to avoid

Thanks.