This questions is a follow up on an answer by Paul Alexander to the question "Should interop assemblies be signed?".
Depending on how complex your Interop assemblies are - you can generate the proxy code into a separate .CS/.VB file and compile it directly into your assembly. Then you won't have to worry about strong name issues.
How would I go about generating the interop proxy code for a COM library into C# source code?
I guess it could be done with tlbimp and then extracting the source with Reflector. Has anyone done this or is there a simpler way?
Take a look at the following MSDN article:
How to: Create Wrappers Manually (Talks about how to create your interop assembly manually.)
Once you've got the interop assembly, use a tool like Reflector to disassemble it and generate the raw C# source. Reflector.FileDisassembler makes this really easy.
Now you can include the generated C#/VB sources directly into your assembly.
I do not know simpler way, and extract interface descriptions via Reflector. However in VS 2010 Microsoft will do this for you automatically.
Related
I am creating a complex class with AssemblyBuilder that Im later creating objects from. There is however uncertainties in how this class is really contructed. So is there any way to write this dynamicly created class to a cs file for inspection?
I can get the dll file written to disk but I need the cs file.
You can decompile managed .NET dll to C# code using
DotPeek by JetBrains (free, sources are closed)
ILSpy open source project (MIT license sources are available at github)
Reflector by Red Gates (Paid tool, sources are closed)
JustDecompile by Telerik (free with open source decompilation engine available at github Apache License)
There is also a Microsoft's ildasm tool.
If you need to write custom tool you can download open-source code and give it a try.
Do you have a requirement to use AssemblyBuilder? I'm asking because AssemblyBuilder wont allow you to see the generated class without using a decompiler and if the class you´re generating is quite complicated, the decompiled code wont be of good quality.
You are almost in the same situation if you use Reflection.Emit because it generates low level IL.
If you really need to see the source code that you're generating dynamically your best option is CodeDom. Here's an example How to: Create a Class Using CodeDOM
You might be able to kill two bird with one stone with Roslyn (aka ".NET Compiler Platform"). You'll need the package Microsoft.CodeAnalysis.CSharp.
First, you can use the SyntaxFactory class to generate syntax nodes, which you can combine into larger structures (members, methods, classes, namespaces, compilation units).
You can also get a nicely formatted representation of your syntax nodes with ToString() or ToFullString() (with correct indentation and line breaks and everything), which is what you were originally looking for.
There are quite a few tutorials online on how to use this API (like 1, 2), and there's the Roslyn Quoter website that can convert a piece of C# code into SyntaxFactory calls.
Second, you can then use the resulting CSharpSyntaxNode to create a CSharpSyntaxTree, which you can compile into IL with the help of CSharpCompilation (after all, Roslyn is the reference C# compiler).
If you want, you can even emit the generates assembly into a stream, get the assembly's binary data from there, and load your newly created assembly into your currently executing assembly, and dynamically instantiate the types you just defined.
You need to use the .NET reflection.
Ildasm.exe cannot help you because it will not create the .cs file you need.
So either the ILSpy is the open-source .NET assembly browser and decompiler from the SharpDevelop team or dotPeek from Jetbrains.
Depending on the platform you may also check Mono Cecil. Cecil is a library written by Jb Evain to generate and inspect programs and libraries in the ECMA CIL format.
If you need speed JustDecompile from Telerik is a free tool for .NET assembly browsing and decompiling that claims to be 10x faster than competitors.
All these tools lets you take an existing compiled assembly (.dll or .exe) and easily browse the symbols it contains, and then just as easily decompile the assembly language back to readable C# and IL.
I am trying to implement a COM interface in my C# dll for others to consume. I have defined an interface in foo.idl.
I've run foo.idl through tlbimp to produce foo.dll, a .Net assembly. Now to implement my interface, I can reference foo.dll in my dll to implement the interface.
This works perfectly as it stands with one exception: I now have to distribute two dlls instead of one. This actually goes against the requirements of the project I'm working on: deliver one DLL.
Is there a way to merge the tlbimp dll into mine, or any other way to do this (implement a COM interface in C# without the second dll)?
A good disassembler gets the job done, like Reflector. You can simply disassemble the interop assembly and copy the generated C# interface declarations into your source code. Of course you should only do this if the interface declarations and IIDs are stable.
And definitely consider upgrading to VS2010. Its "embed interop types" feature allows you to ship your assembly without the interop assembly.
You could probably cheat by using a .tlb instead of the 'glue' dll.
I'd suggest you create a mixed-mode assembly using MSVC++/CLR
http://msdn.microsoft.com/en-us/library/k8d11d4s(v=vs.100).aspx
Interop (How Do I in Visual C++)
This might have the drawback that you can't use C# in the same assembly. Should you want to add C# code to the mix, you might be able to squeeze out of your tough situation using
IlMerge
For other, possibly interesting, thoughts see my earlier answer:
Is it possible to compile a console application into a single .dll file?
I am trying to read GUID attribute of a C#.net assembly from c++ (VC++ 10).
I should mention that, I don't want to use .net or .net reflection. looking for a pure c++ way.
what is the solution ?
Thanks in advance.
You need to use the Unamanaged Metadata API
and especially the IMetaDataImport::EnumCustomAttributes Method
That's going to be quite a work... Here is a link that gives a good starting point on this (it's C#, but the ideas are exactly the same, and is in fact easier to program in C++): Reading types from assembly
Check out the The .NET File Format MetaSection over at CodeProject.
i understand you don't want to use reflection or .net.
You do however want to get the GUID from a C# dll you have, that was built with .NET.
The common way C# developers make their class libraries available to COM-based developers is to use the tlbexp.exe (type library export) tool to export a type library file.
The COM-developer can then use the .tlb file in their COM code.
When the C# developer builds the dll they either put the Guid manually in the AssemblyInfo level (in .NET) or the compiler will generate the Guid automatically when building the dll.
show how the COM client (C++) is built to use the COM server (C#)
http://msdn.microsoft.com/en-us/library/aa645738%28v=vs.71%29.aspx
note that in this article refers to another tool regasm.exe which registers the dll and can export the tlb at the same time but it is not necessary to register the dll on your system
as a developer you can just use the tlb file
How would I export functions defined in a C# class library, while enabling them to be imported to and called from an unmanaged C++ application/DLL ?
Strictly speaking, you can't just export functions as you would in a classic .dll, as .NET .dll's aren't really .dll's at all. Your only three options are:
Use managed C++
Expose your C# classes as COM objects and consume them from your C++ code
Host the .NET runtime in your C++ project and interact with your C# classes through that.
Your C++ Apllication would have to start by hosting the CLR. There is nothing special required from the .NET DLL.
You would not. Not supported. You can pretty much only export COM objects from a C# class librarly.
You could also make a C++ wrapper for your C# library - a simple Managed C++ DLL that would import .NET methods and export them natively. This adds an additional layer, but it might be useful if C# library is a must have.
Another option is to tweak the compiled assembly to export the functions. A C# compiler cannot do this, but it takes a slight change of MSIL code to get the things done.
Have a look at this article - there're some links on how the stuff works, and a tool to automate it (though I haven't tried it myself).
I am well aware that one can use reflector to browse the content inside an assembly, and one can use FileDisassembler to convert the content into the c# source code with cs projects. But the source code outputted by FileDisassembler may not be able to compile if it has interface with property.
Is the other similar applications that do what FileDisassembler does?
I would not trust Reflector's decompiler.
Many times I have seen it just ignore instruction it did not understand, or just optimized certain sequences away, and changing the meaning the process.
The only trusty way is to use IL.
Regarding more tools, look at the CCI. IIRC, they had a C# source emitter at some stage, but it was removed for some reason.
dotPeek from jetBrains is a good decompiler for c#. http://confluence.jetbrains.net/display/NETPEEK/dotPeek+Early+Access+Program