For example, I have the following code defined in assembly A:
public abstract class Message
{
public int ID { get; internal set; }
public Message Parent { get; internal set; }
}
From assembly B, I need to do the following:
instanceOfMessage.ID = MethodToGetUniqueIDNumber();
instanceOfMessage.Parent = MethodToGetParent(); // Returns null /w no parent
Currently, I’m using the InternalsVisibleTo compiler option to get around this:
[assembly:InternalsVisibleTo ("AssemblyB")]
// Namespace stuff here
public class Message
{
public int ID { get; internal set; }
}
It kind of feels yicky having to mess with a compiler option to make this work. So, my questions are:
- Is it okay to use InternalsVisibleTo in this situation?
- Should I just make the property(s) public and hope no one changes anything?
- Should I even be doing this at all?
My end goal is that someone, likely just my team and I, should be able to use a Message, but enforce that properties like ID never get changed from outside the classes that manage them. However, we still need to be the ones to create the instances of the messages and such.
My end goal is that my team and I should be able to inherit from Message in a third assembly, Assembly C. Assembly C only knows about Assembly A. Assembly B gets dynamically loaded later on. C will use interfaces provided by A to send messages to B.
One common approach in this type of situation would be to actually use an interface for the message, and then implement the interface within AssemblyB.
This allows your messages to be created, but not modified later, as you can still have full control over the implementation.
Then your other assembly can just implement this with a private class, and return the appropriate message, without fear of it being able to be modified.