elhacker.net cabecera Bienvenido(a), Visitante. Por favor Ingresar o Registrarse
¿Perdiste tu email de activación?.

 

 


Tema destacado: (TUTORIAL) Aprende a emular Sentinel Dongle By Yapis


+  Foro de elhacker.net
|-+  Programación
| |-+  Programación General
| | |-+  .NET (C#, VB.NET, ASP) (Moderador: kub0x)
| | | |-+  Es posible obtener el código de un paquete de NuGet?
0 Usuarios y 1 Visitante están viendo este tema.
Páginas: [1] Ir Abajo Respuesta Imprimir
Autor Tema: Es posible obtener el código de un paquete de NuGet?  (Leído 2,246 veces)
z3nth10n


Desconectado Desconectado

Mensajes: 1.583


"Jack of all trades, master of none." - Zenthion


Ver Perfil WWW
Es posible obtener el código de un paquete de NuGet?
« en: 20 Febrero 2017, 23:32 pm »

Hola buenas,

esto es una pregunta muy noob, quizás no tenga ni respuesta, pero pongo la mano en el fuego a decir que alguno me dará una respuesta más que convincente aunque sea diciendo que no... La duda es bien simple, veréis, yo tengo una API que funciona con una versión (o una Plataforma de destino, según Visual Studio 2015) que es la: "Unity 3.5 .net Full Class Library", que básicamente funciona con .NET 3.5... (Luego está la versión "Unity 3.5 .net Subset Class Library" que para el que no lo sepa, sigue siendo .NET 3.5, pero con las librerías de 2.0, de algún modo los de Unity se las han ingeniado para capar en dicha versión algunas (no se si todas) las librerias que incluía la nueva versión 3.5, dejando solo disponible las de la versión anterior que vienen a ser las de la .NET 2.0)

Estaba viendo algo que se llama NamedPipes que es muy interesante para comunicar dos aplicaciones de .NET entre sí... Y bueno, me he descargado un source que utiliza clases de .NET 4.0, que es como comprensible no se encuentra entre las referencias de mi código. Ojeando por internet he descubierto que existen unas cosas que se llaman NuGet Packages, y en concreto he descubierto este:

http://www.nuget.org/packages/TaskParallelLibrary/1.0.2856

Que bueno, habla por si solo, añade unas cuantas clases que a mi me hacen falta para la lo de las NamedPipes:

https://www.codeproject.com/Articles/864679/Creating-a-Server-Using-Named-Pipes

Este script es el que digo que usa unas clases (Tasks y ConcurrentDictionary entre otras) que no están disponibles en .NET 3.5 a no ser que se utilice el paquetito de NuGet...

Para mi ahora mismo es como magia, pero mi duda es, se puede extraer el código del mismo? A lo mejor estoy diciendo una barbaridad, porque no se ni como funcionan, lo digo, porque mirad lo que pasa al instalar:



Tengo dos opciones o bien hacer que sea compatible con la versión que utilizo de .NET o bien descargandome el source del mismo, que no se si estas opciones son posibles por otra parte.

El error es claro, pero la solución no tanto.

Quizás seguramente acabe cediendo y buscando otro snippet para lo del NamedPipes, pero ya tengo curiosidad de ver al menos cuales son mis opciones.

Un saludo.


« Última modificación: 22 Febrero 2017, 12:49 pm por Ikillnukes » En línea


Interesados hablad por Discord.
Eleкtro
Ex-Staff
*
Desconectado Desconectado

Mensajes: 9.885



Ver Perfil
Re: Es posible obtener el código de un paquete de NuGet?
« Respuesta #1 en: 22 Febrero 2017, 05:07 am »

mi duda es, se puede extraer el código del mismo? A lo mejor estoy diciendo una barbaridad, porque no se ni como funcionan

Hola. Un paquete de NuGet no es más que un archivo comprimido (.zip) el cual suele contener una serie de ensamblados .NET (dlls) que se referencian de forma automatizada a tu proyecto, así que no, no hay código que puedas analizar... a menos que le hagas un Reflection a los ensamblados en cuestión.

Muchos de los paquetes de NuGet suelen estar también publicados en GitHub (donde puedes ver el código fuente, como ya sabes de sobra), pero lamentablemente este no parece ser el caso con el autor de ese paquete, un tal @Omer Mor: https://github.com/OmerMor?tab=repositories sin embargo, ahí en su perfil de GitHub puedes encontrar su e-mail personal donde puedes intentar pedirle el código fuente.

El error que te indica en la consola de NuGet es autodescriptivo, sin embargo, supuestamente no debería ser así... cuando el propio autor afirma que su librería funciona najo .NETFx 3.5 xD. Así que no sé que decirte.



@Nukes, en mi opinión estos posts que ultimamente publicas con problemas son... a ver, son problemas, pero es que no mencionas cual es el problema real, y así no se te puede ofrecer ayuda cualificada. Me refiero, un tio puede venir y ayudarte a que soluciones la instalación de ese paquete NuGet, ¿pero de que te servirá eso realmente?... si el problema principal que te ha llevado a querer implementar las NamedPipes en una supuesta versión no soportada de .NET Framework es un problema bien distinto.

Empieza por aclarar lo siguiente: ¿Qué necesitas llevar a cabo?, comunicarte con otro proceso de forma local (Interprocess Communication), o comunicarte con otro proceso de forma remota (Network Interprocess Communication), y a partir de ahí se podrá empezar a decirte tus opciones...

De todas formas te puedo decir que para comunicarte con otro ensamblado .NET de forma local no necesitas usar las Named Pipes, puedes usar bloques de memoria compartida (Memory-Mapped Files), mírate el namespace System.IO.MemoryMappedFiles, además te puedo mostrar por privado una clase completa de mi framework de pago ElektroKit para facilitarte las tareas de comunicación. Y para comunicarte con otro ensamblado .NET de forma remota, en lugar de Named Pipes puede utilizar simple y llanamente un Socket: https://code.msdn.microsoft.com/CSSocketCommunication-089f0e86

¡Saludos!


« Última modificación: 22 Febrero 2017, 09:21 am por Eleкtro » En línea



z3nth10n


Desconectado Desconectado

Mensajes: 1.583


"Jack of all trades, master of none." - Zenthion


Ver Perfil WWW
Re: Es posible obtener el código de un paquete de NuGet?
« Respuesta #2 en: 22 Febrero 2017, 10:32 am »

Hola. Un paquete de NuGet no es más que un archivo comprimido (.zip) el cual suele contener una serie de ensamblados .NET (dlls) que se referencian de forma automatizada a tu proyecto, así que no, no hay código que puedas analizar... a menos que le hagas un Reflection a los ensamblados en cuestión.

Muchos de los paquetes de NuGet suelen estar también publicados en GitHub (donde puedes ver el código fuente, como ya sabes de sobra), pero lamentablemente este no parece ser el caso con el autor de ese paquete, un tal @Omer Mor: https://github.com/OmerMor?tab=repositories sin embargo, ahí en su perfil de GitHub puedes encontrar su e-mail personal donde puedes intentar pedirle el código fuente.

*****, siempre se me escapa algo, gracias por revisarlo por mi. :silbar:

@Nukes, en mi opinión estos posts que ultimamente publicas con problemas son... a ver, son problemas, pero es que no mencionas cual es el problema real, y así no se te puede ofrecer ayuda cualificada.

A ver, es de tonto si no postease el problema principal, que como tu dices es ese... Peero, preferia resolverlo por mi mismo, y dejar esto como duda alternativa y tonta, que has resuelto más que bien, ya te digo... Siempre hay 2 o 3 opciones que se me escapan. :P

Empieza por aclarar lo siguiente: ¿Qué necesitas llevar a cabo?, comunicarte con otro proceso de forma local (Interprocess Communication), o comunicarte con otro proceso de forma remota (Network Interprocess Communication), y a partir de ahí se podrá empezar a decirte tus opciones...

De todas formas te puedo decir que para comunicarte con otro ensamblado .NET de forma local no necesitas usar las Named Pipes, puedes usar bloques de memoria compartida (Memory-Mapped Files), mírate el namespace System.IO.MemoryMappedFiles, además te puedo mostrar por privado una clase completa de mi framework de pago ElektroKit para facilitarte las tareas de comunicación. Y para comunicarte con otro ensamblado .NET de forma remota, en lugar de Named Pipes puede utilizar simple y llanamente un Socket:

Y ya con esto terminas de rematar el post (en el buen sentido, me refiero jaja), me pondré a mirar esto, no te lo he pedido, pero se agradece tu esfuerzo extra por indicarme el buen camino que he de seguir, puesto que si, mi problema esencial era ese... Voy a mirar también que versión de FW usa estas clases, pq me voy a tener que poner a trabajar con backports un pelin...

Lo del ElektroKit es un gesto muy bonito, pero prefiero esperarme a la proxima vez que me quede trancado que con mucha suerte será esta tarde lo más seguro jejeje

Un saludo.
En línea


Interesados hablad por Discord.
Páginas: [1] Ir Arriba Respuesta Imprimir 

Ir a:  

WAP2 - Aviso Legal - Powered by SMF 1.1.21 | SMF © 2006-2008, Simple Machines