{"id":3338,"date":"2020-09-10T14:23:16","date_gmt":"2020-09-10T12:23:16","guid":{"rendered":"http:\/\/blogs.encamina.com\/desarrollandosobresharepoint\/?p=3338"},"modified":"2020-09-10T16:24:11","modified_gmt":"2020-09-10T14:24:11","slug":"sharepoint-csom-ya-disponible-en-net-standard","status":"publish","type":"post","link":"https:\/\/blogs.encamina.com\/desarrollandosobresharepoint\/sharepoint-csom-ya-disponible-en-net-standard\/","title":{"rendered":"SharePoint CSOM ya disponible en .NET Standard"},"content":{"rendered":"
\"SharePoint<\/div>\n

A finales de junio, se public\u00f3 una versi\u00f3n estable y oficial de uno de los grandes requerimientos de los desarrolladores de Office en los \u00faltimos a\u00f1os: CSOM para .NET Standard<\/strong>, o lo que es lo mismo, la librer\u00eda Cliente para poder acceder a SharePoint. En este art\u00edculo vamos a explicar los motivos de esta demanda y veremos tambi\u00e9n c\u00f3mo empezar a usarlo con un sencillo ejemplo \ud83d\ude42<\/p>\n

<\/p>\n

Historia<\/h1>\n

En estos momentos, hablar de la importancia que tiene que una librer\u00eda en una determinada tecnolog\u00eda, visto desde la perspectiva de cualquier tecn\u00f3logo, puede parecer un sinsentido si no se tiene el contexto, \u00bfy cu\u00e1l es el contexto? La forma en la que desarrolla en los productos Microsoft ha evolucionado mucho en los \u00faltimos a\u00f1os.<\/p>\n

Microsoft dispone de muchos productos que se utilizan en much\u00edsimos clientes como son SharePoint, Dynamics CRM, \u2026 Estos productos, hace no muchos a\u00f1os, se instalaban en la infraestructura de los clientes y el desarrollo se realizaba instalando \u201cartefactos\u201d en dicho servidor. Ahora bien, los tiempos cambian y estos productos ahora son servicios que consumimos en el Cloud, y naturalmente no tenemos acceso al servidor para instalar nada.<\/p>\n

Esto implic\u00f3 un gran cambio en la forma de desarrollar sobre SharePoint. Pasamos de un desarrollo en lenguajes de servidor como C#<\/strong> a especialistas en el FrontEnd<\/strong>. La cuesti\u00f3n no es solo un cambio de tecnolog\u00eda (cambiar C# por Typescript con el frameworks que m\u00e1s rabia nos d\u00e9), sino que muchas de las acciones que se hac\u00edan en los desarrollos, ahora no se pueden hacer.<\/p>\n

Acciones como poder impersonar<\/em> usuarios al estar en el Front. No se pueden hacer procesos \u201cprogramados\u201d\/\u201cbajo demanda\u201d para integraci\u00f3n con otros sistemas (y aunque se pudiera, no ser\u00eda una opci\u00f3n a plantear). Para poder hacer esta funcionalidad ten\u00edamos\u00a0 que utilizar CSOM( Client SharePoint Object Model) o bien directamente llamadas a la API Rest de SharePoint. La problem\u00e1tica en este punto, es que la API Rest de SharePoint<\/strong> no tiene todos los endpoint ni toda la funcionalidad que hay en CSOM y adem\u00e1s, CSOM es mucho m\u00e1s f\u00e1cil de utilizar. En este punto, CSOM fue relativamente importante, tanto para a\u00f1adirlo en API Rest Custom como en el uso de Azure Functions. En las primeras versiones, cuando Azure Functions en su versi\u00f3n 1.0 era .NET Framework y .NET Core estaba en sus primeras versiones (con todas las dudas sobre su evoluci\u00f3n y el camino que iba a seguir), un desarrollador de Office pod\u00eda extender su desarrollo de una forma natural. Conforme aumentaron las versiones de dichos productos y su implantaci\u00f3n fue mayor,\u00a0 poder usar una Azure Function en el contexto de SharePoint se convirti\u00f3 en algo relativamente complejo. Muchos en este punto pensar\u00e9is qu\u00e9 necesidades puede tener\u00a0 hacer uso de SharePoint en una Azure Functions. Imaginad que tengo unos documentos en SharePoint y quiero mandarlos a un almacenamiento m\u00e1s ligero para tenerlo en un hist\u00f3rio como Blob Storage. Para hacer este desarrollo, anta\u00f1o ten\u00edamos dos opciones:<\/p>\n