utiliza tipo tag pero nombres espacio como c# c++ visual-studio mfc atl

c# - tipo - Extensión del espacio de nombres de Shell. DO#. C++, MFC, AT-qué usar?



espacio de nombres c# (6)

Hay una muy buena serie sobre el tema en Code Project: la guía del idiota completo para escribir extensiones de Shell . Ya tiene algunos años, pero sigue siendo relevante. ¡Comenzaría allí!

Necesitamos crear una extensión de espacio de nombres de Shell. Dejé la programación de Windows en 2005, esa vez tuve que crear extensiones de shell simples, pero construí servidores COM muy complejos (en proceso y fuera de proceso) y aplicaciones de escritorio. Usamos las bibliotecas ATL y MFC.

El tiempo ha pasado y ahora necesito volver a la programación de visual studio / windows. Esperaba poder olvidar todo sobre ATL, MFC y C ++, y crear aplicaciones en CLR con C #.

Recuerdo que fue realmente muy difícil encontrar buenos desarrolladores de ATL / MFC, y la mayoría de las veces tuve que hacer todo el trabajo. Así que ahora imagino que, en la era de .NET, será realmente imposible encontrar desarrolladores de ATL / MFC que puedan ayudarme.

Y acabo de ver esto en MSDN Library: http://msdn.microsoft.com/en-us/library/dd758089%28v=VS.85%29.aspx

"Microsoft recomienda no escribir extensiones de Shell administradas y no las considera un escenario compatible". -

Oh no, no, no ... Estaba emocionado y ansioso por usar C #, WindowsForms o incluso WPF, y dicen que no puedo.

Entonces, si quiero crear una aplicación C ++ no administrada de Windows, ¿son las únicas opciones MFC / ATL? ¿Es realmente cierto que en 6 años no ha habido ninguna mejora? Entonces, ¿tengo que usar las mismas tecnologías antiguas?

Ahora estoy buscando una mejor opción en Visual Studio 2010, y parece que para las aplicaciones no administradas de C ++ todavía tenemos que usar MFC o ATL. Mi pregunta es si esta es realmente la única manera.

Y ahora suponemos que tenemos que usar viejas librerías MS, y las extensiones Shell son todas sobre interfaces COM, creo que la mejor opción es ATL.

Pero tal vez necesitamos incluir algunas ventanas y algunos controles de interfaz de usuario. Recuerdo que puede agregar soporte MFC a proyectos ATL o soporte ATL para proyectos MFC. Sé que trabajé con ese tipo de cosas, pero fue hace años. ¿Puedes decirme cuáles fueron las mejores opciones?

Muchas gracias, de un amante de Java y C ++ nostálgico.

Si bien es posible crear extensiones de shell en código administrado, no es una buena idea porque puede entrar en problemas de versiones si varias extensiones usan versiones diferentes de .NET Framework. La razón es que las extensiones de shell se cargan en proceso, y un proceso solo puede cargar una versión del marco.

C ++ con ATL sería mi opción preferida, MFC en segundo lugar. También podrías escribirlo en C, pero eso es mucho trabajo. También es posible que pueda usar Delphi (no administrado) o algunos otros idiomas.

Consulte lo siguiente de nuestra KB para EZNamespaceExtensions.Net , un producto que hace que sea muy fácil desarrollar extensiones de espacio de nombres en .Net.

Las extensiones de espacio de nombres pueden cargarse mediante procesos arbitrarios y, antes de .Net runtime v4.0, el código administrado creado con una versión del tiempo de ejecución .Net no podría ejecutarse en un proceso que ya haya cargado otra versión del tiempo de ejecución.

El último tiempo de ejecución de .Net 4.0 / VS 2010 es totalmente compatible con la carga simultánea en el proceso del tiempo de ejecución de .NET 4.0 (y TODOS los tiempos de ejecución futuros) con tiempos de ejecución .Net más tempranos. Vea el siguiente extracto de http://msdn.microsoft.com/en-us/magazine/ee819091.aspx "Con la posibilidad de tener múltiples tiempos de ejecución en proceso con cualquier otro tiempo de ejecución, ahora podemos ofrecer soporte general para escribir extensiones de shell gestionadas- incluso aquellos que se ejecutan en proceso con aplicaciones arbitrarias en la máquina ".

Incluso si desarrolla su extensión de espacio de nombres usando .Net 3.5 o anterior (VS 2008 o anterior), esto es solo un problema si su extensión de espacio de nombres se distribuirá al público en general. Esto no es un problema en absoluto si su extensión de espacio de nombres se implementará internamente en su empresa o en un entorno controlado similar (como suele ser el caso con las extensiones de espacios de nombres). En este caso, ya que sabe qué versiones del tiempo de ejecución de .Net van a instalarse en las computadoras de su compañía, puede usar la herramienta correspondiente para el desarrollo. Por ejemplo, si las computadoras de su empresa tendrán instalado el tiempo de ejecución .Net 2.0, entonces puede desarrollar con seguridad su extensión de espacio de nombres con Visual Studio 2005. Si las computadoras de su empresa solo tienen instalado el tiempo de ejecución de .Net 1.0 / 1.1, debe usar VS 2002 / VS 2003 o incluso puede usar Visual Studio 2005 mientras apunta al tiempo de ejecución 1.0 / 1.1 al compilar (usando MSBuild o varios archivos de configuración ampliamente disponibles).

DESCARGO DE RESPONSABILIDAD: trabajo para LogicNP Software, los desarrolladores de EZNamespaceExtensions.Net y EZNamespaceExtensionsMFC.

Muchas gracias por todas sus respuestas, todas son personas muy útiles. Solo me gustaría decir lo que finalmente haremos, tal vez podría inspirar a alguien más.

Vamos a implementar el proceso central de nuestra aplicación como una aplicación ejecutable de C #. Esta aplicación estará a cargo de toda la lógica, como las comunicaciones del servidor, incluso las notificaciones del icono de la barra de tareas. De esa forma podemos construir una extensión dll muy ligera, para poder minimizar todo el código ATL.

Esta solución solo necesita una comunicación local entre la extensión dll y el proceso principal. Estamos utilizando la tecnología COM en la extensión DLL, entonces ¿cuál será el punto de usar otra tecnología de comunicación ?. Exportaremos una COM API fuera de proceso en el ejecutable implementado con C #. Y la extensión DLL usará esos objetos COM para obtener todo lo que necesita mostrar en la extensión de shell.

Pero tenemos un pequeño problema.

Soy el único que tiene conocimiento y experiencia en el uso de ATL, los otros desarrolladores de Windows en nuestros equipos son desarrolladores de c #. Y no puedo ayudar en este desarrollo, porque estoy a cargo de otra pieza de nuestro sistema. Tenemos que mostrar resultados en muy poco tiempo, y usted sabe lo difícil que es aprender ATL.

Así que vamos a construir la extensión en C # solo para demostraciones, donde tenemos un entorno controlado. Y luego migraremos la extensión de C # a C ++.

Saludos cordiales, Pedro Ballesteros

Una nota sobre la respuesta de logicnp ya que no tengo representante para hacer comentarios ...

Incluso si usa .net 4.0, Microsoft recomienda no usar código administrado: Microsoft recomienda no escribir extensiones administradas en proceso en Windows Explorer o Windows Internet Explorer y no las considera un escenario compatible.

De: http://msdn.microsoft.com/en-us/library/dd758089%28v=VS.85%29.aspx .

Inicialmente, cuando apareció .net 4.0, creo que había mucha confusión en esto dentro de Microsoft. El artículo de MSDN que enlaza con logicnp en su respuesta, dice que puede usar .net, es un ejemplo de esto.

Todavía puede usar .net para escribir extensiones de proceso, por ejemplo, controladores de vista previa y (creo) manejadores de miniaturas.