So you are preparing your first Windows 64-bit image or just dutifully customizing your own machine. You copy your traditional set of DLLs to the System32 folder and execute regsrv32.exe against them. To your horror you receive the error “RegSvr32 The module some.dll failed to load. Make sure the binary is stored at the specified path or debug it to check for problems with the binary or dependent .DLL files. The specified module could not be found.” Has your machine gone insane? The file is plainly there in the System32 folder. Let’s put it under the microscope.

When an application requires mycomobject.dll, Windows will check the application and system folders for this.dll file. If the file is missing you may receive an error and the application may not function properly. Hey, im trying to get a mycomobject.dll file to download can i get some help please. Wednesday, August 1, 2018 6:14 AM. This tutorial is going to show you how to find dll files on your computer.Don't forget to check out our site for more free how-to videos!h. Mycomobject.dll Windows 10 - fasrfrog. My VM SCCM windows 2012 R2 server can't get a sccm-client on my windows 7 VM. I tried client-push and the CCMSetup.exe is running, but eventually stops. The ccmsetup.log gives me GetDPLocations f.

Here is the seemingly insane output you may be seeing:

It is quite obvious the file is exactly where you told regsvr32.exe it is, so why is Windows suddenly blind?

This type of situation generally leads to slamming your forehead on your keyboard several times and wondering why you didn't take up your childhood urge to be a Doctor - you could be golfing right now!

Let's save some wear and tear on your keyboard and, most importantly, your forehead...

Unravelling the Mystery

This error happens on 64-bit Windows when you place a 32-bit DLL in the System32 folder and attempt to register it with 32 or 64-bit regsrv32.exe.

64-bit Regsvr32.exe employs a little trick – when it notices you are trying to register a 32-bit DLL, it silently calls 32-bit Regsvr32.exe for you!

That’s an awesome little fixup by Microsoft and it works great when your files are in any other folder.

We can see this magic happening in Process Monitor:

In the 64-bit command prompt we called 64-bit regsvr32.exe (unpathed references in a 64-bit process will search the path).

64-bit regsrv32.exe noticed that the DLL is 32-bit an automatically called 32-bit regsvr32.exe for us.

Mycomobject.dll Windows 10 Pro

But when 32-bit regsvr32.exe accesses the current working folder %windir%system32, it is automatically redirected to %windir%SysWOW64, where there is no DLL.

You might decide to get smart and leave the DLL in the real System32 folder and fully path regsvr32 at %windir%sysWOW64regsvr32.exe – but you will receive the same error for the exact same reason.

The Solution

The solution is simple, any 32-bit DLLs that are placed in the System32 folder on a 32-bit system must be placed in the SysWOW64 folder and registered there.

Windows Explorer Extensions / Plug-ins

A word of caution, if your DLL is supposed to extend Windows Explorer with a context menu or property pane on some file type extentions (FTEs), Windows 64-bit will allow you to successfully register it, but 64-bit Windows Explorer ignores the registry key where these registrations go because it simply can not load 32-bit DLLs into its 64-bit process.

Stop Scraping Your Knees on the 64-bit Pavement ;)

This is just one of the few reasons we’ve pulled together an eBook called Deploying and Supporting Applications on Windows 64-bit.

It’s exceptionally affordable and I’d be willing to bet it saves you many hours and many knee scrapes!

We previously discussed that COM Interop does not function in .NET Core 1.0. What about .NET Core 2.0? The answer is YES… with limitations.

The first and most obvious is that COM Interop only works with Windows, not other platforms.

The second limitation is that the .NET Core implementation does not include IDispatch, which means that late binding is not supported. Almost 10 years ago, Microsoft introduced the dynamic keyword in C# 4.0, which made late binding with COM and other platforms much easier.

The above code will function in .NET Framework, but in .NET Core 2.0, an exception occurs:

‘System.__ComObject’ does not contain a definition for ‘Visible’

If you look in Task Manager, you’ll see that Excel.exe has indeed started, but the object members cannot be access directly without IDispatch. To work around this, you can use interop techniques that pre-date the dynamic keyword.

Interop assemblies are wrappers that enable .NET Core to interact with COM objects using early binding. Microsoft provides interop assemblies for Office automation on NuGet and elsewhere. Once the assemblies are installed, this code will work:

Aside: For web applications, Office automation is not recommended. Check out the Open XML SDK.

What about your own COM objects? .NET Core projects do not provide a means to reference them directly. However, you can create a .NET Framework 4.x project and add a reference to the COM object. This will create an Interop.MyCOMObject.dll assembly in the obj/Debug folder, which you can then reference directly in the .NET Core project.

A COM object may return other objects that are not part of the type library, and early binding is not an option. This happens often in my Visual FoxPro interop code. You can use reflection to access the object members.

The dynamic keyword makes for more natural code, but you can make reflection less cumbersome than above with your own wrapper methods.

For the adventurous, the Powershell teamhas created their own implementation of IDispatch. I don’t know how reusable this implementation is, but it may be worth a look.

If you’re using in-process (DLL) COM servers, be aware of 32-bit vs 64-bit issues. For web applications, take a look a Rick Strahl’s post on STA components. I don’t know if these techniques are available in .NET Core. In my experience, these issues do not apply with out-of-process (EXE) COM servers, but your mileage may vary.

Mycomobject.dll Windows 10 Free

Lastly, keep in mind that ASP.NET Core 2.0 continues to run on .NET Framework 4.x, in addition to .NET Core. If you’re already restricted to Windows, there aren’t many reasons to prefer .NET Core over the full framework (yet), so it remains the best option for COM Interop. That said, it’s good to know these possibilities exist with .NET Core.

Mycomobject.dll Windows 10 Activation

Microsoft has been choosy about what they bring over to .NET Core. Over time, they have been finding their way towards more parity with .NET Framework. It was recently announced that WinForms/WPF will be coming to .NET Core 3.0. They may find that a lot of existing code relies on late binding. I would not be surprised if IDispatch makes a comeback.