Programate algo - Programming Blog/Blog de Programación

Spanish version / Versión en Español Usually, a .NET project consumes standard and third-party libraries from nuget.org . For context, NuGet is .NET's de facto package manager, like npm for Javascript, PyPI for Python, Maven for Java, Conan for C++, and so on. It's common practice for an organization to own a NuGet repository hosted in a binary hosting service such as Artifactory or Nexus . If the organization develops its own libraries, they will be hosted in that particular repository. This way, libraries can be used across different development teams inside the organization, and also beyond it if libraries are chosen to be made public. This is all well and good, but sometimes the hosting service goes down, or it is desirable to tinker with the libraries locally before deploying them. In scenarios like these, it's helpful to have an extra NuGet source that lives in the developer's machine and can be used when building and developing .NET applications. T...

Versión en inglés / English version Típicamente, un proyecto .NET consume bibliotecas estándar y de terceros a través de nuget.org . Contextualizando un poco, NuGet es el gestor de paquetes o ( package manager ) de facto del ecosistema .NET, como npm para Javascript, PyPI para Python, Maven para Java, Conan para C++, etcétera. Es una práctica bastante establecida que las organizaciones tengan un repositorio NuGet privado alojado en un servicio de hosting de binarios como Artifactory o Nexus . Si la organización desarrolla sus propias bibliotecas, las alojará en dicho repositorio. Así, podrán ser reusadas entre distintos equipos de desarrollo dentro de la organización, e incluso fuera de la misma si se opta por hacerlas públicas. Todo esto está muy bien, pero a veces el servicio de alojamiento de binarios se cae, o se desea modificar las bibliotecas localmente antes de desplegarlas. En escenarios así, resulta útil tener una fuente NuGet adicional alojada en la máquina de...

Spanish version / Versión en Español You might have run into this scenario: a Windows application, which uses native/unmanaged C++, works perfectly fine in your development box. But in the productions environment, it crashes and a message like this one appears: Sometimes, that exception can be caught with a try-catch block. But in other cases such as an Access violation, division by zero and similar ones, it can't be caught. Windows offers a specific solution for this: the __try - _except block, but it has some limitations . Specifically, it can only capture SEH exceptions. And those must be enabled on a project basis for this to work. A better alternative, which is the one we'll analyze next, consists in using the SetUnhandledExceptionFilter function from the Kernel32.lib library . This allows us to catch the exception, but how can we get more information? Well, it is possible to obtain a stack trace by using additional functions from the psapi.lib and dbghlp...

Versión en inglés / English version Probablemente se hayan topado con este escenario: una aplicación Windows, que usa C++ nativo/no manejado, funciona perfecto en la máquina de desarrollo. Pero en las máquinas de los clientes a veces sale un message box similar al siguiente: A veces, esa excepción puede capturarse con un bloque try-catch. Pero en ciertos casos como Access violation, división por cero y similares, no se puede capturar. Una alternativa específica de Windows es usar un bloque __try - __except, pero tiene sus limitaciones . Concretamente, sólo puede capturar excepciones de tipo SEH. Y las mismas deben estar habilitadas a nivel proyecto. Una mejor alternativa, que es la que estudiaremos a continuación, consiste en usar la función SetUnhandledExceptionFilter de la biblioteca Kernel32.lib. Esto nos permite capturar la excepción, ¿pero cómo obtener más información? Es posible obtener un stack trace usando unas funciones auxiliares de las bibliotecas psapi.lib ...

Spanish version / Versión en Español Let's say you need your C++ dll to communicate with a third party dll which uses MFC and Windows Messages to send data and notifications. The easiest way out would be to write an MFC application with a dialog which handled those messages. But let's say your C++ dll is at a very low layer and you don't want GUI code there. At least not openly. Well, there is no avoiding the Windows Messages, so we'll be using, at least, the Win32 unmanaged API. So how do we capture Windows Messages without showing a window? Some basic things you should know first: To capture Windows Messages, you must create a window (associated with a HWND) and use its message loop There is one message loop per thread. This implies that the message-handling window must live in the same thread as the message-generating code A window can be created as a Message-Only window , in MSDN jargon. And that's what we'll do Once I learned all of ...

Versión en inglés / English version Supongamos que necesitamos que nuestra dll C++ se comunique con una biblioteca externa que use MFC y Windows Messages para enviar datos y notificaciones. La forma más sencilla de establecer esa comunicación sería escribiendo una aplicación MFC con un diálogo (una clase que herede de CDialog) que maneje los mensajes generados por la biblioteca externa. Pero supongamos que nuestra dll C++ está en una capa de bajo nivel y no queremos meter una interfaz de usuario ahí. Al menos, no abiertamente. No hay forma de evitar los Windows Messages, así que tendremos que usar, mínimamente, la API Win32 nativa. Entonces, ¿Cómo capturamos Windows Messages sin mostrar una ventana? Antes de seguir, debemos saber lo siguiente: Para capturar Windows Messages, hay que crear una ventana (asociada a un HWND) y usar su message loop Hay uno y sólo un message loop por thread. Esto implica que la ventana que atrape los mensajes y su message loop deben vivir ...