whether .net framework required to run a .tlb file generated from c#?
You have to:
make sure the classes that you want to use in your VB app are ComVisible
make sure the classes that you want to use in your VB app have a Guid assigned to it
it is best practice to create an interface for those classes
create a tlb file from the assembly using regasm
The .NET framework (runtime) needs to be installed. It is not that regasm will 'compile' your assembly into another language or something that does not need the .NET runtime. A runtime callable wrapper is created, so that you can invoke the .NET assembly as from VB6, which means the .NET runtime is still required.
In VB.Net you can use it normally. In previous version use Runtime Callable Wrapper. More information is here in this KB article.
Related
I don't know if what I want to do is even possible. I have two C# DotNet DLLs: Parent.DLL and Child.DLL. Both are built with Visual Studio 2010 using .NET Framework 4.
Parent.DLL makes use of routines in Child.DLL. However, at runtime, Parent.DLL and Child.DLL will be in different directories.
Is there a way for Parent.DLL to dynamically load and use Child.DLL at runtime?
I came across this example for use in a console app that is dynamically loading a DotNet DLL and I'm trying to adapt it for use by a DotNet DLL. However, the reference it requires is not recognized when added to the project:
using System.Runtime.Loader;
Is what I am trying to do even possible? Do I need a later version of DotNet?
The phrase you are looking for is reflection. Reflection in the .NET framework allows for dynamically loading in DLL's into the calling assembly assuming they are written in the .NET framework and the methods you are trying to call are public. MSDN has good documentation on it as was already mentioned previously here.
I was using a DLL in C# and called a method which returned me a C# object of the DBConnection class. My question is, if the DLL don’t know which language it will be used on, how can it return an object of a C# class?
Not all DLLs are created equal. Some are COM-specific. Some are not. Some are .Net IL assemblies. Some are not. This DLL is a .Net assembly. The class objects it provides for your are not strictly C# objects. They are .Net objects.
This works out for you because C# is itself built for .Net, and uses .Net objects. If you were using VB.Net, F#, IronPython, C++CLR, or other platform that uses .Net, you'd also be able to use the DLL. But C, Java, VBA etc would have a much harder time.
The .NET assembly is a standard independent of language.
If you write a code in c# it will generate the same "assembly" .NET than VB .NET or F#.
The DLL does not return a "C# Object". The DLL return a .NET object.
I have a .Net Com Dll is it possible to use this dll and create .OCX file in c++ or MFC. If yes what are all the steps which needs to be followed. If any sample code is availabe that would be a great help
You could expose the .NET assembly as COM object using the regasm.exe tool. You could use the [ComVisible(true)] to indicate that all classes should be visible by COM clients when registered. This assembly level attribute could also be set in the properties of the project in Visual Studio. You could also apply it only to some classes that need to be exported. Once the assembly registered as COM object you could instantiate any class from unmanaged clients as with any standard COM object.
There is nothing particularly special about an .ocx file, it is just a DLL. Microsoft came up with that filename extension back in the Visual Basic version 4 days to make it obvious to VB programmers that they had a DLL that contains controls. ActiveX controls as opposed to VBX controls from the 16-bit days.
If you made the .NET assembly [ComVisible] then you already have a COM server that's usable in other projects. Provided you registered it properly, .NET assemblies must be registered with Regasm.exe instead of Regsvr32.exe. Done automatically in a .NET project with the Project + Properties, Build tab, "Register for COM interop" option. And at installation time with a Setup and Deployment project. If you need a type library then use Regasm.exe with the /tlb and /codebase options. Or Tlbexp.exe
If this really needs to be a traditional .ocx, in other words have controls, then you can use a Winforms UserControl or your own class derived from a Winforms control. Winforms automatically implements the plumbing to make classes derived from the Control class function properly in an ActiveX host.
If you're wanting to use a .NET library in normal C++, there are ways, mostly involving COM Interop. Microsoft has a whole section of MDSN dedicated to COM Interop: http://msdn.microsoft.com/en-us/library/6bw51z5z%28v=VS.71%29.aspx.
If the .NET DLL supports COM Interop, use that.
Try using VC++'s #import directive to read the .NET DLL in as a COM object. When compiled, VC++ should output a .tlh file and a .thi file (header and implementation respectively) which will be automatically compiled into your project. But this may or may not work depending on the DLL's construction, dependencies, etc.
Look at creating your own COM Interop .NET wrapper library that marshals calls to the base .NET DLL.
I decided to use tessnet2 library for my Windows Mobile 6 project. Unfortunetly while I am trying to compile it, it throws an error:
The best overloaded method match for 'tessnet2.Tesseract.GetThresholdedImage(System.Drawing.Bitmap, System.Drawing.Rectangle)' has some invalid arguments
The type 'System.Drawing.Rectangle' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
OK, I know. Add reference to the assembly. The problem is, that I did it. I add reference by 'Add Reference' in Solution Explorer (System.Drawing), and I even have it declared as 'using System.Drawing'.
Intellisense works without any problem. When i write 'rect' it automaticlly shows me the list with 'Rectangle' structure on top.
What is the problem? The assembly is added, even intellisense sees it, why doesn't the compiler?
Just looking at it, there's no way this is going to work in the Compact Framework. First off the site explicitly says
Tessnet2.dll needs Visual C++ 2008 Runtime
Well, that means it was built for the desktop. It's not going to work on a WinMo device for many reasons, but suffice it to say that you would have to recompile it for the right processor and using the right runtimes. If it uses anything like inline assembler this is going to make porting it really, really challenging.
If you get the tessract library built, you still can't use the tessnet2 managed library.
It's a Visual Studio 2008 C++/CLI project
This means it's a managed C++ project. Managed C++ is not supported by the COmpact Framework. So you'd have to port that to C# or write a separate P/Invoke wrapper that calls the tessract library functions.
The compact framework and standard framework are 2 different code bases that exposes a similar API. That is why intellisense 'worked' but the compiler 'complained'.
Your 3rd party OCR framework needs to reference the CompactFramework. Download the source for Tessnet2. Replace the referenced framework assemblies with compact framework assemblies. You'll have to browse for them and find them in "C:\Program Files\Microsoft.NET\SDK\CompactFramework\v3.5\WindowsCE".
I have the source code of a C# program. I want to create a DLL out of it which I want to use in C++.
Is it possible to create a native DLL in Visual Studio 2008 which can be used in C++?
native <-> .Net interop is one of my pet disciplines, which is why I needed this as straightforward and reliable as possible.
The result was that I made me an MSBuild task which I just need to drag into a project to allow me to export static methods from pretty much any .Net language. And since the whole marshalling infrastructure works for exports as well, you can do pretty much anything with it that you want (like passing native/managed objects as IUnknown).
The resulting assembly will look to the consuming process like a real DLL, which means you can't have it to scale up to 64bit automatically anymore.
However, since you do have native bits in your application, you already have this issue anyways. ;-)
When you do not specifiy the CPU target in your C# project, my task will emit a warning that it created a folder for all targets (x86,x64 and Itanium), and there you'll have *.dll and *.pdb for each platform.
If you want the program to be native, and not managed, you'll need to port it to C++, instead of using C#.
That being said, you can compile it in C# into a library, and use it from C++ by using C++/CLI. This just requires that you compile the files that use the C# library with the /clr flag. This provides C++ access to the .NET framework, and lets you use libraries made in C# directly from C++.
Alternatively, you can use .NET's COM interop to expose the C# class(es) as COM objects, and then use those from native C++.
It is possible in Visual Studio 2008, but you're not going to be able to write it using C#.
To create a native DLL, you'll have to write your code using one of the unmanaged C++ project types.
You can expose the DLL to COM. Have a look here for some examples.
yes you can.
you need to create second project.
the project must be unmanaged (like "visual c++"->class library).
the name of this procedure is "calling from unmanaged code to managed code".
good to read unmanaged to managed (codeproject)
you must be aware, that any computer that using your dll must have preinstalled DotNet and Visual C++ Redistributable Package