Passa ai contenuti principali

COM wrapper for a Managed library

In rari casi ci si può trovare a dover esporre un assembly .Net verso un programma scritto in linguaggio unmanaged. Una delle possibili soluzioni è dotare l'assembly di un'interfaccia COM da poter utilizzare nell'applicativo unmanaged.

Nel video Make Use of Assemblies Written in Any CLS Language
della serie How Do I? videos di Microsoft si affronta un semplice esempio di programma WinForm scritto in C# il cui assembly compilato e registrato come oggetto COM viene poi usato da un programma in Visual C++.

I passi fondamentali:

Lato C# bisogna importare System.Runtime.InteropService. Impostare gli attributi di classe ComVisible(true) e ClassInterface(ClassInterfaceType.AutoDual).

Una volta compilato l'assembly bisogna far girare l'utility .net regasm per creare la type library.
regasm /tlb:PhysServer2.tlb PhysServer2.dll.

Poi copiare l'assembly nella stessa directory dell'eseguibile unmanaged che userà la libreria.

Commenti

Post popolari in questo blog

Log.Net: Conflitto Con CrystalReport per Visual Studio 2010

Situazione: Web Application Asp.Net 4.0, Utilizzo delle librerie di Crystal Report per VS2010. Il progetto web utilizza Log.Net, scaricato dal sito ufficiale. Un problema simile si verifica con applicazioni Windows Form. Problema: Le due librerie vanno in conflitto sia in fase di compilazione ( 1550854 - "Could not load file or assembly 'log4net' or one of its dependencies" Error when building Visual Studio 2010 solution utilizing the Crystal Reports .NET Runtime ), sia una volta installata sulla macchiana target (L'inizializzatore di tipo di 'CrystalDecisions.Shared.SharedUtils' ha generato un'eccezione. Impossibile caricare il file o l'assembly 'log4net, Version=1.2.10.0, Culture=neutral, PublicKeyToken=692fbea5521e1304' o una delle relative dipendenze. La definizione di manifesto dell'assembly specificato non corrisponde al riferimento all'assembly.). Soluzione Spiegata: Il thread in cui ne parlano. A quanto ho ca...

SqlServer di Aruba - Entity Framework 4.0 - Problema dello Schema

Lo schema in MsSql è un elemento intermedio fra il database e le tabelle, lo schema predefinito è dbo e compare nel nome tabella come [dbo].[NomeTabella] .  In fase di generazione di un modello .edmx Entity Framework permette di impostare lo schema tramite la proprietà "Database Schema Name" dell'edmx.  Questo valore però non sarà modificabile a Runtime perchè cablato nei metadati. Il servizio SqlServer di aruba purtroopo crea le tabelle in uno schema che ha lo stesso nome dell'utente (per esempio MSSql123).  Quindi un edmx generato in locale a partire da tabelle definite nello schema dbo non fuzionerà. Vi sono due possibili Soluzioni: In locale definisco le tabelle di sviluppo nello stesso schema in cui saranno sul Sql di Aruba. CREATE SCHEMA  MSSql123 GO CREATE TABLE [MSSql123].NomeTabella] ( ... ......); Impongo che i metadati non vengano inseriti nella dll, ed edito a mano i tre file xml di metadati sostituendo dbo con lo schema in uso su aruba o...

Dotnetnuke non migrerà ad asp .NET MVC

Il grande capo di dnn Shawn Walker ha messo in chiaro che non tenteranno un porting di dnn verso asp .Net MVC, dotnetnuke resterà per sempre su web forms. La scelta è tanto saggia quanto obbligata. Esiste però un modo per estendere DNN o integrarlo con un'applicazione MVC? sembra di si, il completo tutorial in 3 parti direttamnte dai blog ufficiali delgi sviluppatori Dnn: parte1 parte2 parte3 Per completezza qui il famoso post di ScottGu sulla volontà di microsoft di tenere in piedi con uguali risorse sia asp.Net MVC sia WebForms.