Aop RealProxy: Millennium-based BUGC # examples of simple Aop literacy and ORM entity-class attribute Interception

Last night, a CYQ. when testing the V5Beta version, the Data framework enthusiast sent me a question saying that F5 is normal and an error will be reported when running the exe directly. So after a night's research, he will have today's blog post.

 

When you run a piece of code and software, you find that: Debug is normal, and F5 runs normally under Release. Only Release runs abnormally after prepare. What do you think?

 

This problem has never been found in my mind, so I think about it first. Baidu first: I found that there are not many information on the Internet, and sometimes there are several VC ++ messages, for C #,None.

 

 

 

When I sent the code to a friend and asked him to try it out, I found that the 64-bit Windows 7 player of the other party was running normally, and the flexibility improved to another level.

 

In the face of this magical spirit Bug, I spent N hours tossing and finding a Bug that cannot be debugged, because it is normal under F5, that is hard work.

 

What is the difference? The title has been sold out, which is related to the RealProxy of Aop.

 

With AOP alone, there are not many people in the garden, and there are not many estimates, so it is meaningless to go deep, simple and difficult, so I had to simply pass through the scene.

 

How did I find the problem in Aop RealProxy?

In this general method, some pop-up information is inserted in the code segment to narrow down the error code segment and finally find it.

 

To reduce nonsense, here we will talk about two points:

 

1: Which codes have problems and where have problems?

I have written an article in the past: C # examples of simple Aop literacy and ORM entity-class property interception. I can understand AOP first, but it is problematic, that is, today's problem.

The detailed error code and comment error points are provided here. The code is usually a little long and not easy to read:

View Code

Using System;
Using System. Reflection;
Using System. Runtime. Remoting. Activation;
Using System. Runtime. Remoting. Messaging;
Using System. Runtime. Remoting. Proxies;

Internal class AopAttribute: ProxyAttribute
{
Public override implements albyrefobject CreateInstance (Type serverType)
{
AopProxy proxy = new AopProxy (serverType );
Return (proxy. GetTransparentProxy () as your albyrefobject );
}
}
Internal class AopProxy: RealProxy
{

Public AopProxy (Type serverType): base (serverType)
{

}

Public override IMessage Invoke (IMessage msg)
{
IMessage message3;
If (msg = null)
{
Return msg;
}
If (msg is IConstructionCallMessage)
{
IConstructionReturnMessage message = base. InitializeServerObject (IConstructionCallMessage) msg );
RealProxy. SetStubData (this, message. ReturnValue );
Return message;
}
If (! (Msg is IMethodCallMessage ))
{
Return msg;
}
IMethodCallMessage mcm = msg as IMethodCallMessage;
Try
{
Object [] args = mcm. Args;
Message3 = new ReturnMessage (mcm. MethodBase. Invoke (base. GetUnwrappedServer (), args), args, args. Length, mcm. LogicalCallContext, mcm );
}
Catch (Exception exception)
{
Throw new Exception (exception. Message );
}
Return message3;
}

}
[AopAttribute]
Public class Users: ContextBoundObject
{
Public Users ()
{

}
Int I = 0; // when any member variable is called by Aop, an error "the object is not referenced to the object instance" is reported"
Public void Test ()
{
Try
{
I = 1;
}
Catch (Exception err)
{
System. Windows. Forms. MessageBox. Show (err. Message );
}
}

 

There are usually a lot of code testing and analysis methods. I have found that as long as the Aop object involves internal member variables, an error will be reported when running the Release compiler.

 

2: how to solve the problem. 

After a variety of unsolvable methods, I found that there is another way to write RealProxy, which can solve this problem. The Code is as follows:

View Code
Class AopAttribute: ProxyAttribute
{

Public override implements albyrefobject CreateInstance (Type serverType)
{
AopProxy realProxy = new AopProxy (serverType, base. CreateInstance (serverType ));
Return realProxy. GetTransparentProxy () as your albyrefobject;

}
}
Class AopProxy: RealProxy
{
MethodInfo method;
Export albyrefobject _ target = null;
Public AopProxy (Type serverType, externalbyrefobject target)
: Base (serverType)
{
_ Target = target;
Method = serverType. GetMethod ("Set", BindingFlags. NonPublic | BindingFlags. Instance );
}
Public override IMessage Invoke (IMessage msg)
{
If (msg! = Null)
{
If (msg is IConstructionCallMessage)
{
IConstructionCallMessage constructCallMsg = msg as IConstructionCallMessage;

RealProxy defaultProxy = RemotingServices. GetRealProxy (_ target );

// If the following step is not performed, _ target is still a transparent proxy without directly instantiating the proxy object,
// In this case, the object is not directly constructed.
DefaultProxy. InitializeServerObject (constructCallMsg );

// This class is a RealProxy, which can be transparent through the GetTransparentProxy Function
Return System. Runtime. Remoting. Services. EnterpriseServicesHelper. CreateConstructionReturnMessage (constructCallMsg, (MarshalByRefObject) GetTransparentProxy ());

}
Else if (msg is IMethodCallMessage)
{
IMethodCallMessage callMsg = msg as IMethodCallMessage;
Object [] args = callMsg. Args;

// System. Windows. Forms. MessageBox. Show (callMsg. MethodBase. ToString ());

If (callMsg. MethodName. StartsWith ("set _") & args. Length = 1)
{
Method. Invoke (_ target, new object [] {callMsg. MethodName. Substring (4), args [0]}); // calls the attribute
}
Return RemotingServices. ExecuteMessage (_ target, callMsg );
}
}
Return msg;
}

 

 

3: Debug, Release, and F5. What are the secrets?

I don't understand either. This involves more underlying problems. It's not in my scope. People who know it can leave a message to everyone to answer.

 

Summary:

 

In the world of programming, flexibility is always everywhere, but finding the cause of it and finding a way to solve such events is a must for every code builder.
As to why such a spiritual event exists, we can investigate the cause within the scope of our research. In other fields of our own research, we have done it.

 

 

Finally, in the busy days of the Weibo genie series software, I finally took the time to finish an article, which is not easy.