While opening a DLL in ILDASM, I am getting an error msg telling the dll has no valid clr header and cannot be disassembled.None of the dll's are getting opened. I am using vs2010 ultimate version. Can any1 help me in this?
You can't disassemble native dll's with ILDASM.
Related
I'm using VB.net 2013 with an FTDI USB-SPI converter and library ftd2xx64.dll.
When I try to reference the library I get the message 'Can't add reference to ftd2xx64.dll. Make sure the file is accessible and is valid COM component.'
I tried regsvf32 and tlbimp also with no success.
I'm going nuts, so any ideas would be awesome!
thanks
You are using the wrong one. FTDI have provided a managed .NET wrapper class for the FTD2XX DLL on the Windows platform. The managed wrapper DLL (FTD2XX_NET.DLL) is provided as a free download... here http://www.ftdichip.com/Support/SoftwareExamples/CodeExamples/CSharp.htm
I've written a DLL that provides methods for extracting data from a MySQL DB and generating a report using the built-in report viewer in VS 2012. The idea is to use this in a VB6 program. I've gone through the following process:
1) Build the DLL in VS with "register for COM interop" selected
2) Placed the DLL and TLB file in the directory of the VB6 program on another machine
3) Used regasm: "regasm Report.dll /tlb: Report.tlb /codebase" (redundant step if I already have the TLB file generated by VS?)
4) Added the TLB file to project references in VB6
The VB6 program builds and executes okay, but when I got to run my report I just get "Automation error: the system cannot find the file specified".
I've gone through the above process for a trivial DLL according to the instructions given here. This worked fine. I suspect that the references used in my DLL (MySQL.Data and Microsoft.ReportViewer.WinForms) may also need to be registered on the VB6 machine. I've been able to do this with MySQL.Data but not the ReportViewer DLL.
If it makes a difference, the DLL was built on a Windows 7 64 bit machine whereas the VB6 machine runs XP 32-bit.
Thanks in advance.
Turned out the problem was that I needed to set the Copy Local property for Microsoft.ReportViewer.Common and copy the relevant DLL files along with my own DLL. Hope this helps anyone with a similar problem.
I am trying to access a VB.NET DLL (.NET FX 4.0) from a VB6 client in a reg-free scenario.
I tried to follow the example from http://msdn.microsoft.com/en-us/library/ms973915.aspx, but with no success. I downloaded (link in the article) the sources and compiled, no success (error message: Run-time error '-2146234341 (8013101b)': Automation error"). Running from VB6 IDE using registered VB.NET DLL works.
I tried other examples where the .NET DLL is created as a COM Class (using "COM Class" template from VS2010), with manifest for referenced DLL embedded or not, but nothing worked for me.
Can somebody provide some simple source code with manifests example of VB.NET DLL (.NET FX v4) used in VB6 client in reg-free scenario?
Thanks much in advance.
Run-time error '-2146234341 (8013101b)': Automation error
Your problem doesn't have anything to do with a manifest, you'll need to fix this one first. The error code is COR_E_NEWER_RUNTIME. In other words, your [ComVisible] class cannot be loaded because it depends on CLR version 4. And the program has already loaded the CLR, version 2 most likely, because another [ComVisible] class asked first. And it asked for version 2.
You'll need an app.exe.config file that forces CLR version 4 to get loaded, even when somebody asks for version 2. It should look like this:
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0"/>
</startup>
</configuration>
Give it the same name as the vb6 exe (like "foo.exe.config" to match "foo.exe") and put it in the same directory as the .exe. If you want to use the VB6 IDE to debug your vb6 code that uses this library then you also need vb6.exe.config in c:\program files\microsoft visual studio\vb98
I am trying to add a VC6 COM DLL to our VS2010RC C# solution. The DLL was compiled with the VC6 tools to create an x86 version and was compiled with the VC7 Cross-platform tools to generate a VC7 DLL.
The x86 version of the assembly works fine as long as the consuming C# project's platform is set to x86. It doesn't matter whether the x64 or the x86 version of the DLL is actually registered. It works with both. If the platform is set to 'Any CPU' I receive a BadImageFormatException on the load of the Interop.<name>.dll.
As for the x64 version, I cannot even get the project to build. I receive the tlbimp error:
TlbImp : error TI0000: A single valid machine type compatible with the
input type library must be specified.
Has anyone seen this issue?
EDIT:
I've done a lot more digging into this issue and think this may be a Visual Studio bug. I have a clean solution. I bring in my COM assembly with language agnostic 'Any CPU' selected. The process architecture of the resulting Interop DLL is x86 rather than MSIL.
May have to make the Interop by hand for now to get this to work.
If anyone has another suggestion let me know.
This issue can be resolved by opening the CSProj file and adding the following node to any of the '(Configuration)|Any CPU' nodes that are missing it:
<PlatformTarget>AnyCPU</PlatformTarget>
If this node is not present TlbImp will default to x86 and cause issues.
hope someone is using Mono & monodevelop...
i'm getting the following error when i try to compile an ASP.NET apps ported from vs.net 2008
Error VBNC99999: Unexpected error: The classes in the module cannot be loaded. (VBNC99999)
This is the only error i get.
I'm using 4 external assembly / dll
AjaxControlToolkit.dll
FusionCharts.dll
MySql.Data.dll
PostBackRitalin.dll
I've added the dll in bin directory, then i've referenced it.
I'm using Mono, because on my "old" computer (acer aspire t2300 buyed in 2007) run with linux & with monodevelop very well.
With windows, visual studio is reeeeeeally slow.. so i decide to pass to mono..
Can somenone know something about that error ?
Thank you very much. Regards !
I can guess a few possible reasons, though it's hard to be sure without more info.
The Mono VB.NET compiler is only a VB8 compiler (VS2005), so if you're using VB9 features that might explain the problem.
One of the libraries you're using might be a mixed-mode binary, and contain native Windows code.
You might have found a bug in the VB compiler. If you think this is the case, you should file a bug report.
Beware that Mono's VB.NET compiler is nowhere near as actively developed and tested as the C# one, and MonoDevelop doesn't have code completion or refactoring for VB either. I generally recommend that VB devs compile on Windows and copy the binaries over to Linux, or learn C#...