0

I did look at the following question, however, it doesn't resolve my issue. - Unable to register DLL using Regsv32 - error "Dll was loaded but the entry-point DllRegisterServer was not found" Unable to register DLL using Regsv32 - error "Dll was loaded but the entry-point DllRegisterServer was not found"

The problem I am facing is that a new DLL created w/ C# has to literally work within a legacy POS system running in Windows XP .NET 4.0 that was originally created with Visual Basic 6.0, which automatically created all of the proper entry-points (such as DLLRegisterServer) within the DLL assembly. However, these ActiveX COM entries, since they are no longer used, are not created with C# in Visual Studio 2012/2013. So, my question is, How can I create a Windows XP .NET 4.0 (VB backward compatible) ActiveX COM DLL with C# in Visual Studio 2012/2013, to replace the original VB DLL ? Can these entries be entered manually (& successfully compiled) in the C# DLL (i.e., using ???.??? STDAPI DllRegisterServer(void) { return true; }) ?

Community
  • 1
  • 1
Jimmy
  • 1
  • 3
  • What do you mean by "Windows XP .NET 4.0"? – Euro Micelli Dec 26 '14 at 18:48
  • Are you trying to create a DLL in C# or VB.NET that registers using RegSvr32? Or one that you can just drop-in to replace an existing VB6 DLLs without running any kind of "re-registration"? Unfortunately, that's not possible. COM support in .NET is very different from COM support in VB6, and it needs very different registry entries. RegSvr32 doesn't know how to register a .NET DLL. Any C#/VB.NET COM DLL must be registered using RegAsm, at least once. – Euro Micelli Dec 26 '14 at 18:52
  • I understand that I need to re-register (w/ RegSvr32) the new DLL in its original legacy platform (Windows XP). So the registration & registry entries need to remain the same. However, if you are suggesting the RegAsm is the tool to use,... then my new question would be "Will RegAsm work on the legacy platform ?" Please realize that all that I am requested to do is to replace the VB DLL w/ a new C# DLL, however, the original legacy platform remains the same. – Jimmy Dec 26 '14 at 20:48

2 Answers2

1

Your terminology is a little confusing: there is no such thing as "Windows XP .NET 4.0", but it sounds like you want to use .NET 4.0 on Windows XP. That would be OK. Note that your POS must be running Windows XP SP3. Note that .NET 4.5 and above are not supported in Windows XP. Your new DLLs must be compiled under .NET 4.0 or earlier. There are special complications if your POS software already uses .NET for anything else. I'll assume here that you are using .NET 4.0 and that the POS doesn't otherwise depend on .NET.

You do need to install on the POS machines an appropriate version of the .NET runtime (the version under which your DLL has been compiled is the best choice). But after that - yes, of course RegAsm will allow you to register a COM DLL (not RegSvr32 however; RegSvr32 doesn't know how to register a .NET DLL). As I mentioned in a my previous comment, the details in the registry will necessarily be different from the details for the VB6 DLL.

The installers for the different supported .NET runtimes are available from Microsoft. There are two options:

The ".NET 4.0 Client Profile installer" is currently available here: http://www.microsoft.com/en-us/download/details.aspx?id=24872

The "Full .NET installer" is currently available here: http://www.microsoft.com/en-us/download/details.aspx?id=17718

If you can help it, you want to compile your DLL using the ".NET 4.0 Client Profile" option, which is a subset of the whole runtime with only the most commonly used features. The Client Profile is significantly smaller. You will know immediately if your application is compatible with the Client Profile simply by trying to compile it with that option. If you are using something that is not included in the Client Profile, your DLL will fail to compile. In that case, try first to see if you can accomplish the same functionality without using the non-client-profile feature. If you can't, then use the full runtime.

Now the hard part: you don't specify if your DLL exposes a bunch of custom interfaces, whether it only consumes interfaces declared by the application, or a combination of both. You also don't specify how the POS software knows about your DLL and whether it uses Automation (IDispatch) like VBScript would or "custom" interfaces, and you don't say who declares the interfaces. Setting up the appropriate interfaces in C#/VB.NET can be a tricky problem because VB6 doesn't exactly make it easy to look at the details.

You can pull the most critical information from the existing DLL by registering it and looking at the resulting classes via the "OLE View" tool. The rest of the details will depend on how the main POS application uses your DLL. The full details of what to do can be complex and are well outside of the scope of any one single answer in Stack Overflow.

Euro Micelli
  • 33,285
  • 8
  • 51
  • 70
  • The POS provides documentation which explains a couple of mechanisms on how to interface w/ the POS via this VB ActiveX COM DLL (as described in the documentation). The simplest interface was chosen. There are 2 registry entries containing the name of the assembly.method (i.e., dll_name.method_name) to use. Not sure how these got populated. Also the method/function signatures were specified - something along the lines of [void func1(Session s), void func2(Session s)], but I could be wrong. Don't recall the specifics, but can provide more information next week. – Jimmy Dec 28 '14 at 15:22
  • To the best of my recollection, this system is running WinXP & using .NET 4.0. I do need to look at the VB environment to be completely certain. The VB code is compiled & then registered w/ RegSvr32 w/ no additional interfaces needed to be defined. I will follow the advice & will let you know what I find out. – Jimmy Dec 28 '14 at 15:22
0

So basically you are trying to create dotnet based COM component. Set your project property as COM visible and Register your assembly using Regasm

regasm myDotnetCOM.dll

OR 

regasm /codebase myDotnetCOM.dll

Now you can use CreateObject for this COM component.

Sarvesh Mishra
  • 2,014
  • 15
  • 30
  • Ok,... I did set the COM Visible attribute, but I didn't use regasm (but RegSvr32), since I wasn't aware of it. I guess you are suggesting that copying this utility (regasm) into the legacy platform & running it there wouldn't be an issue. I have to try this when I get back next week. – Jimmy Dec 26 '14 at 20:53