I have an issue with generating Interop by using tool TlbImp.exe
The input dll is 64 bits, but output Interop is 32 bits.
I do not have control over the input dll, it is given by third part.
I have downloaded dumpbin feature and test both dlls.
A. Command:
#"C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\TlbImp.exe" "C:\Program Files\SAP\SAP Business One DI API\DI API 90\SAPbobsCOM90.dll" /out:"%CD%\SAPbobsCOM.dll"
B. Input 64 bit dll dumpbin:
Dump of file C:\Program Files\SAP\SAP Business One DI API\DI API 90\SAPbobsCOM90.dll
PE signature found
File Type: DLL
FILE HEADER VALUES
8664 machine (x64)
6 number of sections
59C18858 time date stamp Tue Sep 19 23:12:56 2017
0 file pointer to symbol table
0 number of symbols
F0 size of optional header
2022 characteristics
Executable
Application can handle large (>2GB) addresses
DLL
OPTIONAL HEADER VALUES
20B magic # (PE32+)
C. Output Interop dll dumpbin:
Dump of file C:\Users\dariuszg\Desktop\dllki 64 bitowe\Interop.SAPbobsCOM.dll
PE signature found
File Type: DLL
FILE HEADER VALUES
14C machine (x86)
3 number of sections
5A5628D1 time date stamp Wed Jan 10 15:53:05 2018
0 file pointer to symbol table
0 number of symbols
E0 size of optional header
2102 characteristics
Executable
32 bit word machine
DLL
OPTIONAL HEADER VALUES
10B magic # (PE32)
D. I have tried to modify the command I am using for the way like this:
#"C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\TlbImp.exe" "C:\Program Files\SAP\SAP Business One DI API\DI API 90\SAPbobsCOM90.dll" /out:"%CD%\Interop.SAPbobsCOM.dll" /namespace:SAPbobsCOM /machine:X64
but then I am receiveing an error like this:
TlbImp : error TI2010 : A single valid machine type compatible with the input type library must be specified.
Please let me know how I can overgo this error ?
I would like to produce 64 bits Interop dll from 64 bits library. I believe it is possible. In case thre is no least chance to do it without changing input dll please let me know as well this. Then I would need to report third party company. But before I would be sure I can't overgo this.
I have done also the question: Generate 64 bit Interop issue but I feel I had not give enough informations or somehow I would deploy this question as it is more clear I hope. If the admin have a problem with that please delete the other one and leave this. Thanks.
I have similar issue when run tlbimp on Windows 32 bit on 64 bit COM dll.
When I run the same command on Windows 64 bit interop generation succeeds.
TlbImp : Type library imported to [cut]\x64bin\Interop.[cut].dll
TlbImp versions are the same: Microsoft (R) .NET Framework Type Library to Assembly Converter 4.6.1055.0
Looks like a Microsoft bug to me.
Related
I am having an issue after updating to the newest version of MSBbuild (16.5.0+d4cbfca49) on Windows Server 2012 R2.
When I run a build in a deep folder structure (up to 150 chars in length), the build fails because a project reference cannot be found. It turns out that the reference path is more than 260 chars long. Strangely the same project can be built with and older MSBuild version (15.9.21+g9802d43bc3).
Another observation is that if the project is moved to a shallower folder structure with shorter paths, the build works smooth.
The long path registry key is set but it seems it does not help. Any ideas please?
Given the following:
the 32-bit DLL code file of some old Firefox plugin (i.e. a DLL containing among other a Typelib, XSD and XSL entries), without source code or debug info, originally coded in C++ and compiled with Visual Studio,
the name and parameters of an exported function/method in this DLL (a function of the Firefox plugin, accessable in JS code),
Visual Studio Community 2013 running on Windows 7,
experience in C++ development, but not with COM or Firefox,
experience with debugging Intel assembler code,
a code license which does not prohibit disassembling the DLL,
I would like to do this: Load the DLL into some C++ code, and step on CPU level into the code of the function to find out what it exactly does.
Can you give me any hint on where to start and how get this done? I guess the DLL may need some Firefox-specific initialization before I can call the function which I would like to debug. Could this be done with the Firefox SDK, without source code and debug info for the DLL? Or may I succeed in "nakedly" loading the DLL, finding the entry point of the - rather simple - function (how?) and calling it?
Thanks for any hints.
If no pdb file or source code, it is hard for you to debug the dll file, since the debugger loads debugging information from the PDB file and uses it to locate symbols or relate current execution state of a program source code. Visual Studio uses PDB files as its primary file format for debugging information during debugging. If no those files, you couldn't debug that library.
Update:
We are dynamically loading a dll to one project using LoadLibrary() function, but if you want to step into your dll file, it really require the pdb file. A simple sample is that you could create and place one pdb file in the same folder as one simple custom dll library project located. I think Visual Studio will automatically search the directory and load them, you could find the information in your Debug modules windows.
The following case is not the same issue as yours, but it also shared us that it would load the pdb file if the dll file was really called by one project/process:
Does winbase::LoadLibrary() load .pdbs?
The program used to do fine. Then I upgrade to Windows 10 and now I have these 2 error when running the program in Visual Studio.
Warning 1 : Cannot find wrapper assembly for type library "Microsoft.mshtml". Verify that (1) the COM component is registered correctly and (2) your target platform is the same as the bitness of the COM component. For example, if the COM component is 32-bit, your target platform must not be 64-bit.
Error 2 : Unable to open module file "C:\Users\jim2\AppData\Local\Temp.NETFramework,Version=v4.0.AssemblyAttributes.vb" : The system cannot find the file specified.
Basically, my code builds fine when I was in windows 7. I upgraded to windows 10 and then I got this error.
I've checked C:\Users\jim2\AppData\Local\Temp\ folder.
There is no file .NETFramework,Version=v4.0.AssemblyAttributes.vb. I don't know how it happened in Windows 7. In Windows 7, before I upgraded, the program compiled just fine.
It seems that this issue is about files that are not there, but searched by project. After deleting it from project the files got created. Now, I still have the same problem.
I guess you are referencing INTERNET EXPLORER which is NOT installed into that Windows 10. The default browser is EDGE and probably the called function of IE is not present in that new browser.
Your question needs more details...
UPDATE:
The Microsoft.mshtml.dll file is a PIA file (from Office). You can try one of these solutions (it may vary sometimes from machine to machine):
1) remove Microsoft.Mshtml.dll reference from your project.
2) Use ADD REFERENCE, NET, select the PIA file
3) In DLL properties, set the COPY LOCAL = TRUE.
But, if the system reports "The module is not signed", you may also try:
1) remove Microsoft.Mshtml.dll reference from your project.
2) Use ADD REFERENCE and choose BROWSE.
3) Point to "C:\Program Files (x86)\Microsoft.NET\Primary Interop Assemblies" (it depends of x32/x64 systems) and select directly the microsoft.mshtml.dll file.
4) Set the COPY LOCAL = TRUE too.
I just want to add to David BS answer.
It seems that the original microsoft.mshtml is gone in windows 10 and deleting and referencing it works. No need to set copy=true, etc.
I am using version 7.0.3300.0
I have downloaded libsvm-3.17 package. Extracted the files. I go to 'tools' folder to try using grid.py to look for suitable c and g with the dataset provided in the package, i.e. heart_scale.
However, the following is what I get
Traceback (most recent call last):
File "C:...\Documents\libsvm-3.17\tools\grid.py", line 266, in run
if rate is None: raise RuntimeError('get no rate')
RuntimeError: get no rate
worker local quit.
Can someone help me figure out how to solve this problem.
Thank you very much.
You may need to scale the data in advance. I got the same problem and it sorted out after I scaled the data. Hope this help.
Firstly, if you are a newbie in libsvm, I would recommend you to try easy.py instead of grid.py. Secondly, before executing anything you have to compile libsvm, for compiling follow instructions given in README file (You must ensure nmake.exe, cl.exe, link.exe are in system path), here is what it says:
Windows binaries are in the directory `windows'. To build them via
Visual C++, use the following steps:
Open a DOS command box (or Visual Studio Command Prompt) and change to libsvm directory. If environment variables of VC++ have not
been set, type
"C:\Program Files\Microsoft Visual Studio 10.0\VC\bin\vcvars32.bat"
You may have to modify the above command according which version of
VC++ or where it is installed.
Type
nmake -f Makefile.win clean all
(optional) To build shared library libsvm.dll, type
nmake -f Makefile.win lib
Another way is to build them from Visual C++ environment. See details
in libsvm FAQ.
Once you have it installed you can start working with easy.py and grid.py.
This is what I tried on both a 64 bit and a 32 bit machine and grid.py works fine.
I have added the default install directories, if your installation directories are different modify accordingly.
Open command prompt and type
C:\Program Files (x86)\Microsoft Visual Studio xx\VC\bin\amd64\vcvars64.bat for 64 bit systems
OR C:\Program Files (x86)\Microsoft Visual Studio xx\VC\bin\vcvars32.bat for 32 bit systems.
Navigate to libsvm directory in the same command prompt and run
C:\Program Files (x86)\Microsoft Visual Studio xx\VC\bin\amd64\nmake.exe -f Makefile.win for 64 bit systems
OR C:\Program Files (x86)\Microsoft Visual Studio xx\VC\bin\nmake.exe -f Makefile.win for 32 bit systems
The binaries should be built successfully in the libsvm-3.xx\windows folder
Run grid.py with your options
Within grid.py the gnuplot.exe is usually set at tmp which never worked for me so I changed the gnuplot executable path in my grid.py to the following:
self.gnuplot_pathname = r'C:\\Program Files (x86)\\gnuplot\\bin\\pgnuplot.exe'
If you use the option -log2p to run grid.py, you will get output get no rate. With grid.py, you can't use -log2p option.(No matches for searching -log2p in grid.py)
You can use -log2p option in gridregression.py.
I am creating a C++/CLI dll that will be loaded into a legacy c++ application. The legacy application does this with a traditional call to LoadLibrary. Both the application and the C++/CLI dll are compiled in 64 bit mode.
When the LoadLibrary call happens, it fails with error 193. This usually means that some non-64bit component is trying to load. When I look at the dll load output in visual studio 2010, I see the the failure is occurring when mscoree.dll is being loaded (to be exact, I see my dll loaded, then mscoree loaded, then mscoree unloaded, then my dll unloaded, then the error returned). Specifically C:\Windows\System32\mscoree.dll is being loaded, when I examine this mscoree.dll, I find that it is targeting I386.
How can I ensure that my application will link against the correct mscoree.dll? I understand this could be done with a manifest, but I can't find any good information about setting one up. The ideal solution would allow compilation in 32bit or 64bit mode and target the correct mscoree.dll.
As a side note, I found an mscoree.dll in a side-by-side folder that I verified is 64bit mode and copied it into my application directory with the hopes that it would pick up that one first. This didnt work and the C:\Windows\System32 version was still loaded.
Thanks,
Max
Output of CorFlags.exe on the C++/CLI dll
Microsoft (R) .NET Framework CorFlags Conversion Tool. Version 4.0.30319.1
Copyright (c) Microsoft Corporation. All rights reserved.
Version : v4.0.30319
CLR Header: 2.5
PE : PE32+
CorFlags : 16
ILONLY : 0
32BIT : 0
Signed : 0
Output of pedump.exe on C:\System32\mscoree.dll
PS C:\Windows\System32> pedump.exe .\mscoree.dll
Dump of file .\MSCOREE.DLL
File Header
Machine: 014C (I386)
Number of Sections: 0004
TimeDateStamp: 4B90752B -> Thu Mar 04 22:06:19 2010
PointerToSymbolTable: 00000000
NumberOfSymbols: 00000000
SizeOfOptionalHeader: 00E0
Characteristics: 2102
EXECUTABLE_IMAGE
32BIT_MACHINE
DLL
...
(pedump goes on from here to describe imports and exports but thats not important here)
Extended loading information
This is the full output from failed load.
Note: The C++/CLI dll is called DsfClr.dll
the output was obtained by running gflags.exe -i [exename] +sls and examining the results in a debugger
http://pastebin.com/FyumUiMN
UPDATE:
Using a tip posted in a below comment by Reuben, I was able to determine that mscoree.dll is indeed targeting AMD64, but pedump is providing invalid information because it is being run in WOW64. That being said I still cannot load this library, if anyone has any suggestions they would be greatly appreciated.
One more thing I have tried: I made a new C# application and referenced the C++/CLI dll, then, in the main() function, I instantiated a class in the C++/CLI dll. This caused an access violation exception before the main() function is called. When I remove the instantiation, the main function runs fine. My guess is that the instantiation is causing a delay load of my C++/CLI assembly, which causes the same load error I was seeing from the native assembly.
In case anyone runs across this error, it turned out that it was caused by my native libraries use of boost::threading. The boost::threading library uses some weird compilation settings. The result is a static library that is incompatible with clr or mixed-mode binaries. Of course, visual studio has no idea of this, so it happily links boost in and crashes when the dll is loaded.
The solution is to dynamically link in boost::threading. The easiest way to do this is to define BOOST_THREAD_DYN_LINK in your project settings. Once I defined that, the dll loaded fine.
A quick google search of C++/CLI boost threading will give plenty more information about this error
I just has a similar scenario.
LoadLibrary failed with 193.
My DLL is a managed C++/CLI DLL called from a native application with LoadLibrary.
However I only get the error on win7 systems. It loads fine on win10. The date of this original question suggests it was win7.
I narrowed it down to a thread_local class.
It appears win7 only supports basic types such as C pointers as thread_local. Anything more complex, even std::shared_ptr which win10 accepts, generates error 193 on Dll load.
For the record, the compiler is VS2015, and the code style is c++11.