¿Cómo lidiar con un API / Framework indocumentado en .NET? [cerrado]

Question

Para el trabajo, tengo que codificar con la API de una empresa externa para tratar con su solución de base de datos patentada. Desafortunadamente, la documentación que proporcionan es más una guía de ejemplo que una documentación API adecuada, por lo que es muy escasa en detalles específicos como códigos de error, devoluciones de métodos y excepciones.

Entonces, por ejemplo, una clase tendrá un método .GetErrorCode (), pero no tengo idea de qué significan esos números de error porque no documentaron qué número coincide con qué error. En muchos casos, un método devolverá un Objeto, sin documentación de qué tipo de Objeto realmente devuelve. Les he pedido repetidamente la documentación adecuada, pero parecen pensar que detalles como los anteriores son secretos de propiedad. Entonces, ¿hay alguna herramienta o método que pueda solucionar en torno a mi documentación limitada o, en algunos casos, inexistente?

Tenga en cuenta que estoy usando Visual Studo 2005 y la codificación en C # en .Net.

Y antes de que alguien conteste, " no use la API ", tengo que hacerlo, es para trabajar.

Answer 1

Un escenario desagradable. Odio sugerirlo, pero tal vez reflector es tu amigo si no está ofuscado . Puede haber algunos problemas de IP, pero en este caso la reversión parece ser la única forma viable de descubrir qué es la API. Sin embargo, sospecho (por métodos como .GetErrorCode ()) que esto es una cuña encima de P / Invoke, en cuyo caso incluso el reflector solo le mostrará muchas llamadas externas ...

La otra cosa principal que puedo decir es: escriba lotes de pruebas unitarias que cubran cómo está tratando de usarlo ... de esa manera, si adivina mal y algo cambia, sabrá temprano.

Answer 2

Si no puedo obtener muestras de código o hablar con un desarrollador original, generalmente recurro a Reflector para ver el código subyacente. Es lento e ineficiente, pero a veces eso es todo lo que puede hacer.

Answer 3

Depende de tu situación. Si está pagando por la API, debe seguir presionando a la compañía para obtener una mejor documentación sobre cómo usar la API.

Si eso no funciona, lo que haría es comenzar mi propia documentación a medida que me desarrolle. Mantenga un cuaderno, una Wiki personal ( screwturn wiki viene a la mente), o algún tipo de electrónica. documentación. Como mencionaron otras personas, puede usar Reflector para ayudar a llegar a la fuente (si no está ofuscada).

Crear su propia documentación puede no ser lo que estaba buscando, pero si no puede obtener documentación real, al menos cree algo a medida que aprende cosas para que pueda tener algo que lo guíe unos meses (o años) más adelante cuando intentes mantener el código creado con la API.

Answer 4

Las mejores herramientas que vienen a la mente incluyen el teléfono y el correo electrónico. Espero que puedas seguir molestando a las personas hasta que te den más información útil ... :(

Answer 5

Utilice Reflector para ver el código fuente. Debería mostrarle la enumeración del mensaje GetErrorCode.

Reflector, por cierto, es el mejor programa en la historia del universo.