I'm trying to patch a .NET DLL file using the Quick Patch project of InstallShield. The DLL needs to be registered for COM Interoperation.
When I patch the file, the dll seems to be replaced correctly in the GAC, but when I try to access it from my application I get an error indicating that the application cannot connect to the DLL.
I think that it is not being registered properly for COM interop, but I'm not sure about it.
Any idea of what should I do to make it work?
Thanks,
You probably have to run regasm(it's in .NET framework directory) with correct params to register for com interop. Also the DLL file is usually built with certain COM visible options selected. Been a long time since I dealt with that nightmare though, so can't remember all the details.
http://msdn.microsoft.com/en-us/library/tzat5yw6(v=vs.80).aspx
Related
I'm working on a project that targeting .NET 4.0 Framework. I added a reference to a third party dll file and call its methods in my code and have no error. But when I build the project it gave me The type or namespace error with blue underline on the methods of the dll. Using .NET Reflector I checked dll .NET Version of mscorlib.dll it is 4.0.0.0. My application Target .NET Version is 4.0 then Why I'm getting this error.
What I have done.
Remove all references to the library. Clean the project. Restart the project. again add the references. Not good in English please guide me. Stuck in it last 4 days.
Check if you have privileges to access the dll file. Then try running Visual Studio as administrator. If it does not help try to build the solution as 64x/86x not Any CPU.
So in my application, I have an actor that uses Pinvoke to call some functions defined in a win32 dll. I also have a front end webservice that calls these actors.
When I run this locally, everything works perfectly. The win32 dll is found and loaded correctly and my actors can call functions from there.
However, when I deploy my solution to Azure, I just get an internal server error when the actor tries to load the dll. Theres no descriptive error so I think that the actor either can't find the dll or can't find one of its dependencies.
I already tried using dependency walker to figure out the dependencies. Most were typical windows binaries with the exception of vcruntime140.dll. I added this to the VS project as a resource file by right clicking on the Project and then navigating to Add>Existing Item and then editing the "Copy to Output Directory" property of the resource in the solution explorer to "Copy always". Is this the right way deploying a native dll to service fabric? I'm also running in release mode so there shouldn't be any debug dll's needed.
Some extra information - My project was initially ported over from a web api project and I was able to successfully call functions in the win32 dll when hosting my web api on Azure in release mode.
Let me know if I need to provide some extra information
So I figured it out. For people who may stumble upon this later, here is how:
When I used dependency walker, I saw that I had immediate dependencies on vcruntime140.dll and msvcp140.dll. However, by digging deeper, I noticed that msvcp140.dll has an additional dependency on concrt140.dll. When I copied this over to my server's bin folder, I didn't get an internal server error anymore and I was able to call into my win32 dll.
All of these are visual studio c++ redistributable binaries that are usually found here "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\redist\x64\Microsoft.VC140.CRT".
I have a software that is coded in C#. It depends on two(!) third party dll which require Visual C++ 2008 and Visual C++ 2005 redistribute. Originally the installer was built in InnoSetup with all "vs200x_sp1_vcredist_x??.exe" embedded and run on install time. However since it lacks of some advanced features we decided to migrate to Wix Toolset.
The problem is, MSI was running in a more restricted environment, so I didn't figure out what is the best way to require those redistributable file being executed properly. I was tried to use merge modules instead but it didn't work - I can see that the files were installed but dependency walker shows that dll is still not link to the right version.
I think that WinSxS makes things worse at least in this case, since the software keep failing with some error message regarding "Windows Side by Side configiration (14001)" when I use the merge module approach.
So the question is:
Are there any way to build a MSI that runs a exe that install some prerequisites? I wouldn't mind those prerequisites being downloaded or just embedded.
I know that WinSxS information is stored in the manifest of the dll. So if I was permitted to remove the manifest information by the third party company, and use dynamic dll loading instead the problem could be resolved. However is this legitimate? Since I will then need to embedded the Microsoft dlls directally in the msi.
I have noticed one of the dll's manifest says its required version is "9.0.21022.8" but the one in my MSM file is "9.0.30729.6161". Is this the issue? If so can I resolve the issue by I modifying the manifest to allow the right version? I don't think this will cause the dll not working, anyway.
The msi file should install only your software. If you need to install pre-requisites, you should use a bootstrapper for it. Bootstrapper's responsibility is to install pre-requisites and it's not a task of your msi.
If you see that wix bootstrapper is complex you can try on a simple bootstrapper like the dotnet installer bootstraper. you can download it from
http://dblock.github.io/dotnetinstaller/
Not sure if anyone else is having this issue.
I am attempting to create a windows forms library control. I need the control to run in an x86 environment. So, the first thing I do is go into the properties of the project and switch the platform target to x86.
I try running the application and I get the lovely error message referencing the assembly I am trying to create and stating: An attempt was made to load a program with an incorrect format.
I have not added any references nor any code, just trying to create a control in x86.
I am using a windows 7 64bit machine with VS2012 trying to write the app in .NET 4.5. I have to do the project in x86 because I am using some OCX that are x86 only.
Has anyone run into this?
go into the properties of the project and switch the platform target to x86
Well, that worked. Instead of a confusing COM exception (typically "Class not registered" which has several possible reasons) you get an early .NET exception that tells you that you are using the library wrong.
To test your library project, you needed to create an EXE project that had a reference to the library project. What you forgot to do is change the Platform target setting on that EXE project. Which matters because only the EXE project can determine what the bitness for the process will be. It is the one that loads first, a library project has no say. It can only veto the choice, the BadImageFormatException is that veto.
So you have to change the Platform target setting for the EXE project to x86 as well.
I have a Visual C++ 6 project that is creating a COM DLL. This is an old project that I have not used in years but I came back to it recently to update some functionality of the DLL. The issue I am having is that when I try to manually register the DLL (using regsvr32) that is created by the project, I get no response whatsoever. It does not say it succeeds and it does not say it fails. I have verified that the DLL is not being added to the registry. I have never seen a situation with regsvr32 when it would not show any confirmation message.
Also, the DLL is set to self-register in the project and when it attempts to do this, it also does not show a message.
I have not touched this project in a long time, but the last time I did touch it, it worked without issue. Now I come back to it, and all of the sudden I am having this problem. It is as if the DLL being created by the Visual C++ project is not compatible with the current version of Windows. I have updated the development software to SP6 but it has not changed the situation.
I ran Depends on regsvr32 when it was pointing to the created DLL, and it shows this message:
LoadLibraryExW("C:\Source32\BIS\Projects\ALFA\DigiPixSvc\DigiPixObj\Debug\DigiPixObj", 0x00000000, LOAD_WITH_ALTERED_SEARCH_PATH) returned NULL. Error: The operating system cannot run %1 (182).
Can anyone please tell me why this is happening and what I can do to correct it?
Disclaimer: since I don't have VS 6.0 installed anymore, I'll have to use some Google searches to give you the exact steps for the VC 6.0 dialogs - so some of this information may be inaccurate. I believe it's correct - it's really what you'd do in the current IDE, just for VC 6.0.
Before you go through the trouble of debugging your DLL, make sure you run it through Dependency Walker to verify that all your dependencies are on your machine. Don't run Dependency Walker on regsvr32 - what matters is whether your DLL has its dependencies. If they're missing, regsvr32 won't be able to load the DLL.
To see if your DLL is getting loaded by regsvr32 when you try to register it, you need to debug through the DLLRegisterServer() function and see what happens there - this is one of the 4 entry points a COM DLL must have and regsvr32 calls this function when the DLL is about to be registered. In order to do this, you'll have to set regsvr32 as the startup program of your project and pass the full path to your debug-built DLL as a command-line parameter to regsvr32.
Bring up Project Properties for your project.
Go to the Debug tab.
Make sure the General category is selected.
Enter the full path to regsvr32 in the Executable for debug session textbox.
Enter the full path to the debug version of your DLL in the Program arguments textbox. Make sure you have a PDB file for your DLL so you can see symbol information during debugging.
Put a breakpoint on the first line in DLLRegisterServer(). The code in this function may be long or short, depending on how it was created: generated by a wizard, written by a developer, etc.
Start debugging.
Your breakpoint should be hit and you should be able to step through the registration code and see at which point it fails.