I think the answer to this one is: you shouldn't do it that way. If a C# programmer sees an int variable he won't expect it to change unless he passes it as ref to a method.
The simple technical solution is
class WrappedInt {
public int i;
public WrappedInt(int i) { this.i = i; }
}
class A {
private WrappedInt p;
public A(WrappedInt pv) { p = pv; }
public void DoPlusPlus() { p.i++; }
}
WrappedInt i = new WrappedInt(5);
A a = new A(i);
a.DoPlusPlus();
You can extend this to a generic boxing class that is implicitly castable to and from its inner type relatively easily. I'm not going to show that*, though, because I think this is the wrong road to go down.
But this seems like a strange thing to be doing. If your A class modifies the state of the application, it should do so in a more explicit and obvious way. Give A an instance of the global state (or data model or whatever i represents a piece of) and have it update that directly:
class State {
public int i;
public int otherStateVariable;
}
class A {
State state;
public A(State state) { this.state = state; }
public void DoPlusPlus { state.i++; }
}
In a real scenario the state or data model would expose properties that would notify other layers and so on.
Of course the best by far is if A can be written with no external dependencies and definitely with no external
writable dependencies (those are what really make an application hard to maintain), but I'm guessing you already thought of trying to do that.
*: Edit: I posted it as a
Tip/Trick[
^] instead.