La metida de pata continuada, o la saga del SDK de SharePoint

Un pajarito me ha traído un regalo la semana pasada: el nuevo SDK de SharePoint, que todavía no está disponible para los simples mortales (las malas lenguas dicen que aparecerá en junio). Así que, fuera de haberle dado una mirada superficial, esta mañana, para solucionar el primer problema de la semana, he sacado a relucir mi nuevo SDK para ver qué me aconseja… Mejor que no lo hubiera hecho…


Nota: para los que no lo han visto, en alguna oportunidad me encontré 8 errores en 15 líneas de código en un ejemplo del SDK)


Veamos: necesito encontrar el valor de un campo de la Base de Datos de Perfiles de MOSS, y quiero usar el WebService “UserProfileService” por aquello de que usar un impersonador nos lo ha hecho tan difícil en el nuevo SharePoint (gracias señores de Microsoft, mientras más difícil me lo hagan, más puedo pedir de aumento de sueldo). El SDK recomienda (véalo en la versión OnLine, si no me cree http://msdn2.microsoft.com/en-us/library/ms550407.aspx):


UserProfileWebService.localhost.PropertyData[] properties = myService.GetUserProfileByName(“domainname\username”);
for (int i = 0; i < properties.Length; i++)
{
    Console.WriteLine(properties[ i ].Name);
    Console.WriteLine(properties[ i ].Value);
}


En donde “UserProfileWebService” es la instancia local del WebService “UserProfileService”.


Primero que todo, el WebService no tiene nada que se parezca a “localhost”, pero si tiene un “PropertyData”, asi que hay algo que sobra…


Luego, el “PropertyData[]” no posee una propiedad “Value”… Afortunadamente hay dos o tres programadores que hacen las cosas bien en Microsoft, y la Intellisense de Visual Studio me dice que la propiedad es “ValueS“, y no es una simple string, sino que es del tipo “ValueData[]”.


En resumidas cuentas, el ejemplo debería ser:


UserProfileWebService.PropertyData[ ] properties = myService.GetUserProfileByName(“domainname\username”);
for (int i = 0; i < properties.Length; i++)
{
    Console.WriteLine(properties[ i ].Name);

    UserProfileWebService.ValueData[ ] myValues = properties[ i ].Values;
    for (int a = 0; a < myValues.Length; a++)
    {
        Console.WriteLine(” – ” + myValues[ a ].Value);
    }
}


Y aquí se te ocurre la pregunta de paraqué usar un array de valores, si cada propiedad solamente tiene un valor?


Ya se va convirtiendo en costumbre: buscas algo en el SDK de SharePoint, miras con desconfianza, intentas reproducir el ejemplo, no funciona (por supuesto), lo tiras y lo intentas por tu cuenta… hasta que un día bote todo el SDK a un pozo sin fondo, solamente para disfrutar del gozo infinito proporcionado por la liberación de la esclavitud sdkiana (que exagerado…)


Gustavo – http://www.gavd.net/servers/
Escriba un Comentario que me haga reir…

5 comentarios en “La metida de pata continuada, o la saga del SDK de SharePoint”

  1. Cuanta razón Gustavo.

    En mi caso, he experimentado de primera mano todo esto que comentas. Cuando hablo con Carlos Segura, me pasa lo mismo, y veo que somos muchos los que nos quejamos de esto… :'(

    Un SDK (no ese que tienes sortudo!… o quizás no tan sortudo…) y errores tras errores dentro de él.

    Me hace gracia mirar un ejemplo del SDK (sencillido, nada complicado).
    Escribirlo y probar… y ¡zás!… ¡¡¡no funciona!!!.

    Miro, remiro y veo que lo he puesto tal cuál… ¿un error pienso?… bueno, puede ser que este ejemplo de error.

    Me voy a Internet y veo gente que pone en sus blogs “el mismo” ejemplo “fusilado”… y claro… en eso me pregunto:
    – ¿Esta gente lo habrá probado?
    – ¿Les funcionará a ellos y a mí no porque soy tremendamente torpe?
    – ¿Acaso hay dos versiones de SharePoint una la que tiene todos los mortales y otra la que yo tengo?

    Evidentemente, los ejemplos del SDK ¡¡¡no funcionan!!!.

    Y así, nos tenemos que pelear una y otra vez por nuestros propios medios con el SharePoint.

    Es lo que hay… y de momento, el SDK que yo tengo es así, el que ha caído en tus manos, parece ser así… y… ¿nos darán un SDK que recoja fielmente lo que hay en el SharePoint o tendremos que seguir peleándonos?.

    Eso sí, como bien dices y entre tanto dolor de cabeza, eso hace que nuestros puestos y trabajo estén asegurados. 🙂

  2. Hola Jorge… A mi no me molesta tanto que fusilen a diestra y siniestra sin controlar, lo que me molesta, y mucho, es que Microsoft ponga todos esos ejemplo SIN PROBAR SI FUNCIONAN! Si yo cometiera tantos errores, uno detrás de otro, seria en este momento carpintero, pues ninguna compañía de software me querría contratar… Es tan difícil en una compañía con 10.000 programadores dedicar uno de ellos a que compruebe todos los ejemplos del SDK? O es que Microsoft ha pensado: abrimos el SDK OnLine para que todo el mundo pueda mejorar allí los errores que nosotros cometemos, y de esa forma no nos cuesta nada? En fin, despotricar es delicioso, y despotricar del amado/odiado Microsoft es aun más sabroso… a ver si la próxima versión de SharePoint nos trae una sorpresa.

  3. joder … pobre mi amigo Edin cuando juegue con MOSS y pobre de mi, ya que como cliente de MOSS tengo q consumir toda la info posible. Realmente liberar un producto con este nivel de detalle es un problema muy grande, pero haciendo ingenieria inversa s m ocurren 2 cosas:

    1. ¿Porque “localhost” en UserProfileWebService.localhost.PropertyData[]?, muy simple, el desarrollador que escribía la ayuda desarrollaba con una instancia local de MOSS y sobre la misma creo un cliente y su referencia le creo el namespace “localhost”. Aunque de ahi a llevar este codigo a la ayuda, me parece lo menos profesional que he visto en mucho tiempo…

    2. Esta es buena, nos decis que el SDK sale en junio; pues bien A FUSILAR A MAILS AL EQUIPO DE DESARROLLO DE MOSS PARA QUE ARREGLEN EL SDK. Si hay algo q esta haciendo bien Ms, en estos tiempos es escuchar a la comunidad de desarrolladores, supongo q nuestros amigos de Redmond estarán tan interesados como nosotros en que el producto final nos deje a todos 😀 😀 😀

    La unica pega, es que t toque a ti probarlo :S; aunque gracias por ahorrarnos algunos dolores de cabeza !!!

  4. La verdad es que Gustavo, es así como lo cuentas… el código del SDK NO FUNCIONA,… y eso me temo que es porque NO LO HAN PROBADO.

    Y a esto mismo, añado en este comentario y como continuación de lo que indica Bruno también:

    El código de los namespaces es desastroso (me callaré muchos detalles porque no es cuestión de calentar al personal). Yo igual lo haría igual de mal o peor, yo que se, pero de una empresa como Microsoft, encontrarse con código “extraño” e inservible y que no pasaría ni de coña el control de herramientas como FxCop es increible.
    Y eso sí, podemos hacer ingeniería inversa para ver como son los namespaces (lo recomiendo si quereis llorar) y poder saber como hacer tal o tal cosa,… pero entonces… ¿para que queremos un SDK si como dice Gustavo y como quería transmitir yo NO FUNCIONA?. Y es que claro… no funciona porque creo como Gustavo, que NADIE lo ha probado, porque si no, no se les hubiera ocurrido haber sacado semejante chapuza.

    Respecto a que en otros sitios lo fusilen, es un tema que lo trato porque así la gente sabrá que si ven algo en el SDK que no funciona y buscan en Internet la “ecuación” correcta, igual se encuentran con páginas Web dónde descaradamente han fusilado algo… que TAMPOCO han probado como para mostrar a la Comunidad lo listos que son esas personas… y claro,… demuestran todo lo contrario y lo cara duras que son.

    En fin… como la mayoría de los mortales yo sólo quiero un ¡SDK QUE FUNCIONE!. 🙂
    De momento, me conformo con pasarme muchas horas delante del PC probando una y otra clase para hacer esta o aquella cosa.
    Eso sí, se aprende mucho así.

    P.D.: el equipo de SharePoint saben de estas quejas, pero me temo que ese equipo no está formado por los profesionales de Microsoft más adecuados… igual esto que digo es duro, pero blanco y en botella leche, y si no, que espabilen.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *