One of our websites uses the payment gateway HSBC CPI which requires a DLL to be registered (using regsvr32.exe), this DLL is then used inside an asp.net website. The problem is that the DLL is a 32-bit DLL and so it will not register with the the Windows 2008 operating system.
Is there a way we can wrap this 32 bit dll in a C#/.net project so that it's methods are exposed and can be registerd with the OS?
Any help would be very much appreciated.
Related
I have a C# 32-bit COM DLL that talks to a C# 64-bit exe using the 'DllSurrogate' method described in Hosting a .NET DLL as an Out-Of-Process COM Server (EXE).
I need this setup because the 32 bit C# talks to a legacy 32-bit C++ dll.
I thought everything was working fine, but I have just realised that when you create a second instance of the 64-bit exe you do not get a second "DLL Host" (COM Surrogate) process. This is no good for my application.
This is a Windows Desktop application and I need to know that if the user starts it multiple times they all run in their own separate processes. Otherwise, data in the legacy dll might be corrupted and they will certainly run into the 32-bit process memory limitation.
The surrogate is registered using the AppId DllSurrogate key.
The 32-bit class instance is created in the 64-bit exe by a call to CoCreateInstance.
From some Googling it seems that the solution to my problem should involve the REGCLS_SINGLEUSE key from the REGCLS Enumeration. However, I can't see where to supply that key. Also, I note that in this enumeration there is a separate REGCLS_SURROGATE key. I hope that doesn't mean that DLL Surrogate and Single Use are mutually exclusive!
Any ideas would be welcome.
I will refer applications in Windows Store for either Windows 8/8.1 or Windows 10 as UWP applications as Wikipedia does, if I do not mistake it. Windows RT(not WinRT though) is not discussed to avoid confusion.
I wonder what API's no matter public or undocumented that Windows 8/8.1/10 have implemented that Windows Store and UWP applications rely on, so that they cannot be port to Windows 7, which is NT 6 as Windows 8/8.1/10 do.
If nothing much are there, but only due to M$'s market strategy to promote new technology'd Metro, there might have been some 3rd-party runtime/framework for Windows 7 on which Windows Store will work and UWP applications can run, which will surely spend no more effort and cause no more legal or compatibility trouble than Mono or Wine.
Edit: As How does Windows 8 Runtime (WinRT / Windows Store apps / Windows 10 Universal App) compare to Silverlight and WPF? says, it's a layer quite similar to .NET that lies between COM and application, if I didn't misread.
It's not a marketing strategy by the evil M$, and writing things like that makes you look rather juvenile. There's a giant layer of code (arguably an entire operating system within an operating system) that was written to enable Metro/Modern/UWP apps to run in Windows 8, tweaked in 8.1, and further refined in 10. That layer simply isn't there in Windows 7, wasn't backported, isn't going to be backported, and can't reasonably be backported by a third party who lacks access to the undocumented details of the implementation.
There is no conspiracy afoot here. It is a simple matter of new operating systems supporting things that old operating systems don't. The new features that Windows 8/8.1/10 have implemented that Windows Store and UWP applications rely on is the entire notion of a Windows Store and a UWP application.
The version number ("NT 6", as you point out) doesn't matter. All that tells you is they didn't massively rewrite the kernel. You don't have to rewrite the kernel in order to write a new layer on top of it.
If you want to run Metro/Modern/UWP/Store applications, you need to update to a later version of Windows. Alternatively, you can just write a regular Win32 application, which will run on all versions of Windows, including the latest builds of Windows 10.
If run a WCF service application straight out of the box in 64 bit mode with service selected , it works fine an gives me the default data contracts.
If I change app to x86 and build with x86 ( not any CPU ) - and configure IIS 8 application pool for this application to allow 32 bit - it fails. How do I make the WCF Application work in 32 bit ( it must be 32 bit because it needs to be a wrapper for some legacy dlls ) . Note: I haven't referenced the DLLs or anything - it is just straight out of the box default WCF application ( Not a WCF library ) . help :-)
Although I am not sure why it is not working in your case, there are two issues to consider when running in 32-bit mode on 64-bit server:
Setting the platform target in Visual Studio: Setting this to x86 will force the target assembly to be built as a 32-bit application. If the assembly that loads the target assembly is running in a 64-bit process, it will fail to load your assembly
However, you do not have to specify x86 to allow your assembly to be loaded in a 32-bit process. If you specify Any CPU as Platform Target, it can be loaded in either a 32-bit or a 64-bit process.
32-bit IIS process: If your application is running as a web app, (running in an IIS app pool worker process), you’ll want that worker process (w3wp.exe) to be a 32-bit process. That can be specified in the advanced settings of the app pool:
Although is says 'Enable', it actually means “force”, meaning that the app pool worker process will always be launched as a 32-bit process when this setting has a value of True. Setting it to False will launch a 64-bit app pool worker process.
I am writing a program in Go/C for the backend and JavaScript/HTML for the front-end. It is not a web application but it runs a local server which sends data to the client(firefox). The client then displays this data and sends any user interaction back to the server using websockets.
The backend is written partially in C since I have to dynamically load a 32 bit DLL file to communicate with my hardware. The hardware (for which I have aquired both 64 and 32 bit drivers) sends its data via USB to my backend which processes and displays this to the frontend. The hardware, drivers and DLL file are from a third party so my chances of changing any of those are very low.
I use GCC (MinGW) as compiler for the C code since Go and Microsoft's compiler didn't get along very well and I use the 32 bit compiler since I am loading a 32 bit DLL.
The program compiles and runs on my 64 lenovo Thinkpad with Windows 8 professional(running it in legacy mode) but now I wonder if it would be possible to run the same program on a Windows tablet. Unfortunately I don't have a Windows tablet so how can I determine if it will work on a tablet without actually buying one? I know that Microsoft has some sort of emulator but will it work with GCC? Will the processor architecture of the tablet matter? Will the same drivers work? Will the DLL file work?
Yes, if the tablet runs Windows 8. No, if the tablet runs Windows RT. For example,
Surface by Microsoft - the New Tablet PC
Surface Pro specifications
Surface RT specifications
Which Surface is right for you? - SKU Chooser
I have a 3rd party COM component that won't work on Windows 8 but will work perfectly fine if run in Windows 7 compatibility mode on Windows 8. However, I don't want the software to run in compatibility mode, just the COM component. Is it possible?
BTW, it's not possible to get a newer/working version of the COM component.
Thanks
Compatibility mode applies to a whole process at a time. The only way to do what you ask for is to run the COM object in a different container process, either using DCOM (if the COM object's interfaces have the necessary stubs and proxies registered for use as an out-of-process object) or by writing your own remoting layer.