Hi, John, By writing an unmanaged application, I'm actually using only COM interfaces to access .NET Framework classes. For Instance: the _Type interface All the various COM interfaces provide methods to access .NET objects, but, the syntax is different from C#. In my application, I obtain a COM interface pointer for the DefaultDomain (after loading the version 4 CLR), then, use that with the _AppDomain interface to call GetAssemblies. This returns a SAFEARRAY of _Assembly Interface pointers, which I can use to call GetTypes. Also, I can invoke: _AppDomain.Load, with an assembly Display Name, and this succeeds in loading a .NET assembly into the AppDomain. And, it goes on from there. Anyway, once you have an interface pointer to a Type, you can call GetConstructors, which returns a SAFEARRAY of _ConstructorInfo interface pointers. In this case (IPGlobalProperties), which is an abstract class, the GetConstructors method returns a SAFEARRAY with NO interface pointers,...so, it is impossible to invoke the constructor and then call GetIPGlobalProperties with an instance of IPGlobalProperties. ...In C#, you would do this (from the NetStat .NET Framework SDK Code Sample):

IPGlobalProperties ipGlobal = IPGlobalProperties.GetIPGlobalProperties();

I don't have Visual Studio installed on my computer. But, my COM application (which I'm writing in assembly language), I would attempt to invoke GetIPGlobalProperties using: _MethodInfo.Invoke, o

Hi, I'm writing an unmanaged application, and, am using the provided COM interfaces to invoke .NET Framework class methods. Generally, this works well, although the code is tedious to write. IPGlobalProperties is an abstract .NET class, and the GetIPGlobalProperties method is static. I am able to obtain a _MethodInfo interface pointer by invoking _Type.GetMethod_6 on the IPGlobalProperties type. Then, when I attempt to invoke _MethodInfo.Invoke_3, providing a bstr "GetIPGlobalProperties", the application crashes with an access violation. The same thing happens when I call _MethodInfo.QueryInterface, providing the IID for the _MethodBase interface (which succeeds), and, then invoking _MethodBase.Invoke_3. I'm thinking, maybe, I should be calling: _Type.InvokeMember, or something along these lines. Previously in my code, I had no problem obtaining a NetworkInformationPermission object by calling its constructor, and providing a NetworkInformationAccess value of read, so I'm wondering what is the reason for the access violations.

Hi, everyone, For some odd reason, I cannot figure this one out. I'm writing an unmanaged application, in assembly language. Most of the application works fine,...it's really just a big COM application for accessing .NET Framework classes by calling COM interface methods that expose these methods. To summarize: I've done all the set-up. I've loaded the Version 4 CLR and MsCorLib in my Default Domain. I've retrieved COM pointers for several assemblies that I've loaded in the AppDomain (System, System.Core, and System.Web). I've retrieved COM pointers for various types and methods contained within the System Assembly, by first calling, _Assembly.GetTypes, and, then calling various _Type methods. This all works well. Now, I'm at the point when I'd like to access some information from the: System.Net.NetworkInformation Namespace, which is largely contained in System Assembly. I am able to retrieve a _Type pointer to System.Net.NetworkInformation.IPGlobalProperties, and, to NetworkInformationPermission, but, I am failing to get a return from _Type.GetProperty for either of these .NET objects. Do I need to call the constructor on these .NET objects first, before accessing properties and methods ??? Or, am I using the Binding Flags incorrectly ??? I think I've tried every possible combination (of BindingFlags), and I still get a returned pointer with a NULL value. I'd post some code,...but, it really is a large amount of source (most of it is irrelevant to this problem),...and, well,...it's in assembly language.

WHAT ???

I'm posting this just in case someone out there in the galaxy has a similar problem. :-D As it turns out, I had the correct approach, but, I made a simple mistake (an incorrect assumption). If you open the mscorlib Type Library in the OLE/COM Object Viewer, and select one of the COM interfaces, it will produce the IDL code of the interface virtual function table's implemented methods in the correct vtable order. I did this, for example, with the System.Reflection._Assembly interface that exposes the public members of the System.Reflection.Assembly class to unmanaged code. What I didn't notice was that the System.Reflection._Assembly interface was derived from IDispatch, instead of IUnknown, like I was assuming. IUnknown has three methods and IDispatch has four methods (in addition to IUnknown's three methods),...so, my count of the offset to the correct COM method implementation function pointer within the interface vtable was off by 4x4bytes. Embarrassing,... ...Just for some serious overkill, here is the IDL output of the System.Reflection._Assembly interface (from OLE/COM Object Viewer):

[
odl,
uuid(17156360-2F1A-384A-BC52-FDE93C215C5B),
version(1.0),
dual,
oleautomation,
custom({0F21F359-AB84-41E8-9A78-36D110E6D2F9}, "System.Reflection.Assembly")

]
interface _Assembly : IDispatch {
[id(00000000), propget,
custom({54FC8F55-38DE-4703-9C4E-250351302B1C}, "1")]
HRESULT ToString([out, retval] BSTR* pRetVal);
[id(0x60020001)]
HRESULT Equals(
[in] VARIANT other,
[out, retval] VARIANT_BOOL* pRetVal);
[id(0x60020002)]
HRESULT GetHashCode([out, retval] long* pRetVal);
[id(0x60020003)]
HRESULT GetType([out, retval] _Type** pRetVal);
[id(0x60020004), propget]
HRESULT CodeBase([out, retval] BSTR* pRetVal);
[id(0x60020005), propget]
HRESULT EscapedCodeBase([out, retval] BSTR* pRetVal);
[id(0x60020006)]
HRESULT GetName([out, retval] _AssemblyName** pRetVal);
[id(0x60020007),
custom({0F21F359-AB84-41E8-9A78-36D110E6D2F9}, "GetName")]
HRESULT GetName_2(
[in] VARIANT_BOOL copiedName,
[out, retval] _AssemblyName** pRetVal);
[id(0x60020008), propget]
HRESULT FullName([out, retval] BSTR* pRetVal);
[id(0x60020009), propget]
HRESULT EntryPoint([out, retval] _MethodInfo** pRetVal);
[id(

Super Lloyd, So, are you the only one here ??? Nobody has a clue as to where the mscorlib header files might be hiding ??? Dang, .NET Framework programmers,...:cool: I did find this blog about something similar: .Net Annoyances, 2004 The author says: "System.Object is defined in the mscorlib assembly. There is no mscorlib.h header file, and there is no mscorlib.idl to generate a C header file either. In order to get at this stuff I had to load up the binary type library file and export it as IDL." The simplest way to get back into assembly language programming is downloading: The MASM32 SDK

Assembly language is interesting. You can do almost anything,...it's like cheating. But, for the novice assembly programmer (like me) it's very error-prone. The biggest advantage is that it's extremely convenient to address anything in memory. This is why hackers prefer assembly language for their malicious code. Also, if you want total control over the precision of your data when implementing floating point calculations,...you'd want to write those procedures in assembly. Years ago, when I first discovered IDA Pro, which is a 32-bit disassembler, I realized that I was going to have to learn to read assembly language so that I could understand the output of IDA. So, I got a text book on the subject (there is only one text book on MASM Assembly Programming), and used it as a reference,...but, it is almost totally obsolete. The Intel® 64 and IA-32 Architectures Software Developer Manuals are by far the best source of information about the assembly language instruction sets.

Hi, Super Lloyd, Yeah,...you understood essentially what I was getting at. The question is basically a COM question (since the .NET Framework classes, types, methods and attributes are 'exposed' to unmanaged applications through the associated COM interfaces). The idea behind the application is to see how difficult it is to use the .NET Framework assembly types and methods from a MASM assembly language application. And, actually, I didn't come up with the original concept,...I'm just writing a test app to demonstrate that the code does in fact work correctly. I assume that it's not impossible, because you could do the same thing in C++, using Visual Studio. The big problem with us assembly programmers is that we don't have all the header files that come with Visual Studio to rely on when we write our source, so we have to prototype everything from scratch (usually using the SDK header files, or files we can download from the Internet), and converting the syntax to that of an assembly language include file (the equivalent of a C or C++ header file), which is pretty simple. And, yes,...you were right about the type library (mscorlib.tlb). You can launch the OLE/COM ObjectViewer (which I think is included with Visual Studio), and, scroll down to the type libraries. A COM type library is supposed to be registered for COM activation (similar to the registry entries for a COM Server Dll) and has entries in the registry, which indicate its location on your computer. So, I can open up the type library and view its various interfaces in IDL format. I assume that the type library was created with Tlbexp.exe (Type Library Exporter), and so the order of implementation addresses for the various functions in the selected interface virtual function table should be the same as in the .NET Framework assembly. This has been working pretty well so far. I can call the method of a COM interface that corresponds to its .NET class, and retrieve the data requested without any difficulty. But, I'm uncertain, at this point how to reference the various .NET Framework types that I will need to supply as calling parameters to corresponding COM Interface methods, so that I can actually call [COM Visible] .NET methods in my unmanaged application. If you use an Intermediate Language decompiler, like ILSpy, you can open up mscorlib, and compare the actual .NET Framework class (for instance:

You should have a good sense of humor to read this question. I'm writing an unmanaged project to host the .NET Framework CLR (version 4), and execute some of it's code. I'm writing the application in assembly language (but, you don't have to understand assmbly language to understand this question), and I don't have Visual Studio installed on my computer. Anyway, I've got all the preliminaries working correctly. I've called Enumerate Installed Runtimes, and called ICLRMetaHost.GetRuntime which causes the CLR (version 4) to be loaded but not initialized,...and then, called, ICLRRuntimeHost.Start method successfully. When viewing the process with ProcessExplorer, I see the clr.dll (version 4) being loaded into the virtual address space. Next, I call ICLRRuntimeInfo:GetInterface to retreive a pointer to the ICorRuntimeHost interface, and use that pointer to call ICorRuntimeHost:GetDefaultDomain. Then, I call IUnknown:QueryInterface to retreive the DefaultDomain (IID_AppDomain) interface pointer. At this point, mscorlib.dll or one of its variants (mscorlib.ni.dll) is loaded by the CLR into the address space. What I need now is to enumerate through some of the basic .NET types and methods, to retrieve addresses. And, what I need to do this, and don't have are definitions for the vtables of the interfaces of, for instance, [_Assembly](https://msdn.microsoft.com/en-us/library/system.runtime.interopservices._assembly
(v=vs.100).aspx) which expose the public members of the System.Reflection.Assembly class to unmanaged code. These are huge COM interfaces, and, to execute their methods correctly, one must know the offset of the method (function pointer) from the address of the interface virtual function table. To actually call these interface methods in assembly you don't even have to prototype the function (although doing so makes your code much more readable and understandable), all you have to is push the appropriate parameters onto the stack, and call the function with the function pointer. So, finally,...my question: where can I find the interface definition files, for mscorlib COM interfaces like: System.Runtime.InteropServices._Assembly, or, System._AppDomain interface, or, especially,

Richard Deeming and Dave Kreskowiak, Hey, thanks for the information. Yeah, I should have mentioned either 32-bit or 64-bit versions (my app is a 32-bit version running on WOW64). More than anything, I'm just curious,...

Hi, I'm wondering if any of you know what is the maximum number of .NET Framework CLR Runtimes that can be installed on a computer ? I'm writing an application, that loads a specific Runtime, and, the first function I wrote enumerates through the installed Runtimes, using the ICLRMetaHost, IEnumUnknown, and ICLRRuntimeInfo interfaces. This function works correctly (I have two installed runtimes on my computer). Thanks for any information.

"You're going to find that this doesn't hold true for all managed assemblies." ...Yeah, Dave,...that was my assumption from day one,...but, by examining the results I get from using that information, and modifying it as necessary, I'll get a workable method. Why is the Registry a Hierarchical Database Instead of a Relational One?, Raymond Chen, 2011

Well, I did a lot more searching for this information. Ironically, I found an excellent article right here at CodeProject, that describes the necessary registry entries for a .NET Framework assembly. Building COM Servers in .NET, Lim Bio Liong, 2006 The information is buried way down towards the end of the article. It looks like this:

[HKEY_CLASSES_ROOT\ManagedCOMLocalServer_Impl01.SimpleCOMObject]
@="ManagedCOMLocalServer_Impl01.SimpleCOMObject"

[HKEY_CLASSES_ROOT\ManagedCOMLocalServer_Impl01.SimpleCOMObject\CLSID]
@="{E1FE1223-45C2-4872-9B1E-634FB850E753}"

[HKEY_CLASSES_ROOT\CLSID\{E1FE1223-45C2-4872-9B1E-634FB850E753}]
@="ManagedCOMLocalServer_Impl01.SimpleCOMObject"

[HKEY_CLASSES_ROOT\CLSID\{E1FE1223-45C2-4872-9B1E-634FB850E753}
\InprocServer32]
@="mscoree.dll"
"ThreadingModel"="Both"
"Class"="ManagedCOMLocalServer_Impl01.SimpleCOMObject"
"Assembly"="ManagedCOMLocalServer_Impl01, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=94ff3289282b08f3"
"RuntimeVersion"="v1.1.4322"

[HKEY_CLASSES_ROOT\CLSID\{E1FE1223-45C2-4872-9B1E-634FB850E753}
\InprocServer32\1.0.0.0]
"Class"="ManagedCOMLocalServer_Impl01.SimpleCOMObject"
"Assembly"="ManagedCOMLocalServer_Impl01, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=94ff3289282b08f3"
"RuntimeVersion"="v1.1.4322"

[HKEY_CLASSES_ROOT\CLSID\{E1FE1223-45C2-4872-9B1E-634FB850E753}\ProgId]
@="ManagedCOMLocalServer_Impl01.SimpleCOMObject"

[HKEY_CLASSES_ROOT\CLSID\{E1FE1223-45C2-4872-9B1E-634FB850E753}
\Implemented Categories\{62C8FE65-4EBB-45E7-B440-6E39B2CDBF29}]

Nevermind

DRUGODRF, This is a great question. My initial thinking is that this is exactly the kind of situation that COM was developed for. However, if you already have working DLLs that are adequate for your purposes, then re-writing the Communication components in COM, would be extremely time consuming. I think the answer to your question depends on the output of the compiler used for whatever language employed, and the complexity (and compatibility of the type systems) of the communication class that you have designed. My coding experience is mainly C++ and Assembly language,...and, so, I have no idea how a Visual Basic compiler would implement your component. But, I think that if the dependent libraries for your component exist on both computers, then it doesn't really matter if you use MFC or not,...the code execution will jump to the location address specified in the import table of your DLL for the invoked function. But, the primary concern here is: just how reliable is this way of remote communication ???

Member 9899644, Sorry for not replying to your post, I completely forgot about it. It sounds as though you are just learning about COM and it's associated functionality. This can be very difficult, because, typically, all you need to do is ignore one aspect of the creation and activation paradigm, and the whole thing just fails to operate as expected (and, you have no idea why). When I was first trying to understand COM (syntax and the reasons it was designed in such a way), I found that reading Don Box's book: Essential COM was extremely helpful. You need an overview, and you need to understand why COM does what it does, and, to read some example source code. As I recall, there are some excellent articles right here on the CodeProject about registering a COM server. Also, you don't mention how your COM client activates the object,...this is typically done with CoCreateInstance. This is an excellent introductory series to COM: The COM Macro-Architecture Topology, ...and,...COM Macro Architecture Topology - Servers, ...and,...COM Macro Architecture Topology - Clients, and,...COM IDs & Registry Keys in a Nutshell. ...Also, Michael Dunn has an excellent series on COM: Introduction to COM - What It Is and How to Use It., and,... Introduction to COM Part II - Behind the Scenes of a COM Server Several incredibly informative articles about COM are written by: Lim Bio Liong Understanding The COM Single-Threaded Apartment Part 1, ...and,...Understanding The COM Single-Threaded Apartment Part 2 Jeff Glatt als

A pointer is merely an address. In 32-bit Windows, it is a DWORD value. It's not even guaranteed that the address is valid, or that some data exists at that address. A safe way to 'delete' your pointer, is just to assign it a value of zero. That way, you can check first before attempting to use it.

Hi, Member 9899644, Your post provides no real information about your simple com exe server. It is impossible to diagnose your problem. There are so many possibilities for error that I'm not even going to try to guess.

DAVE, Thanks,...I'll read through the source code. This is very encouraging.

PETE, Thanks for the response. I assumed that it was possible, but, very inconvenient. I'll have to do some more research. Just out of curiosity,...how exactly do you know it is possible ???