Bien, como fue comentado en la publicación anterior, vamos a comenzar a crear nuestra propia biblioteca de herramientas y elementos de soporte (a algunos les ha dado por llamarlo «Framework» ).
Aprovechando las ventajas de diseño de Visual Studio (por cierto, estoy usando VS2017), el gráfico representa el esquema base de la solución. 
Este esquema lo iremos ampliando con otras bibliotecas a futuro. (Por cierto, son bibliotecas, aunque la mayoría les digan librerías… que librerías son las que venden libros ).
Para facilitar la comprensión del código, la misma solución está desarrollada en paralelo, en C# y en VB. Lo interesante es que son perfectamente intercambiables (y mezclables, puedes usar una dll de un idioma y otra de otro, y funcionarán perfectamente).
Common.
Primero lo primero. O sea, elementos comunes que podrán ser utilizados por cualesquiera de nuestras bibliotecas
En esta biblioteca incluimos toda la implementación de los valores con nombre, a saber:
- INameValue
- NameValue<T>
- NameValueList
Agregamos algunos atributos que seguramente usaremos a futuro (para implementar, por ejemplo, modelos de datos)
- DataFieldAttribute
- DataKeyAttribute
- DataRelationAttribute
- DefaultValueEnum
Y una interfaz que nos permitirá luego diferenciar errores cuando sean propios del sistema (excepciones), o los que implementen esta interfaz, aquellos que deben ser informados al usuario.
- IUserMessageError
Tools
Como segundo proyecto de nuestro entorno de trabajo, creamos la biblioteca de Herramientas, que nos será útil para muchas acciones comunes a cualquier proyecto. En ella, que irá evolucionando seguramente, definiremos aquellos métodos que nos serán útiles repetidas veces.
Lo importante es, darse cuenta a tiempo, cuándo una función que escribimos, podría ser útil en otro caso .
Tenemos en esta biblioteca, las siguientes clases:
- Reflection: de la que hablamos hace unas publicaciones atrás, que nos permite evaluar características de nuestras propias clases.
- Logger: como su nombre indica, esta clase permitirá escribir en un log, sea este un archivo físico o el de Aplicación del Sistema Operativo.
- Interaction: Este es un caso particular… me encontré en más de una ocasión, que cierta funcionalidad implementada en uno de los lenguajes de programación, no tenía correspondencia en el otro. Raro, pero a veces pasa. Como ejemplo, una de las funciones útiles en VB que no existe en C#. CallByName y que en esta clase, podemos implementar. Para mantener coherencia entre distintas versiones de bibliotecas, aun cuando en VB esa función existe como nativa, la mantenemos implementada en esta biblioteca también.
Queda aquí como ejemplo, ambas versiones de esta función, para que quede claro el concepto. Por lo demás, el código está perfectamente comentado. (en inglés, para que sirva a cualquiera que lo desee utilizar, sin barreras de idioma).
En la próxima, una biblioteca que plantea algún desafío interesante, y una herramienta de Visual Studio que nos permite subsanarlo… y la publicación del conjunto completo de código.
public static object CallByName(
object ObjectRef,
string ProcName,
CallType UseCallType,
params object[] Args
)
{
switch (UseCallType)
{
case CallType.Method:
MethodInfo m = ObjectRef.GetType().GetMethod(ProcName);
return m.Invoke(ObjectRef, Args);
case CallType.Get:
PropertyInfo p = ObjectRef.GetType().GetProperty(ProcName);
return p.GetValue(ObjectRef, Args);
case CallType.Let:
case CallType.Set:
{
PropertyInfo pL = ObjectRef.GetType().GetProperty(ProcName);
if (Args == null)
{
pL.SetValue(ObjectRef, null);
}
else
{
pL.SetValue(ObjectRef, Args[0]);
}
return null;
}
}
throw new ArgumentException(string.Format("Invalid CallType {0}", UseCallType));
}
Public Shared Function CallByName(
ObjectRef As Object,
ProcName As String,
UseCallType As CallType,
ParamArray Args As Object()
) As Object
Return Microsoft.VisualBasic.CallByName(
ObjectRef,
ProcName,
UseCallType,
Args
)
End Function
Universidad Net 