I get the following exception when showing a form:
InvalidOperationException was unhandled
Mixed mode assembly is build against version 'v2.0.50727' of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information.
alt text http://img69.imageshack.us/img69/2599/captureya.png
Dont really know why this isnt working. Any help?
I haven't seen the code for LoginForm. But I think you need to set an app.config flag to fall back to .NET 2.0 era bindings...
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0"/>
</startup>
First, what's a mixed mode assembly? A
mixed mode assembly is an assembly
that contains both managed (CIL) and
unmanaged (machine language) code.
Consequently, they are not portable to
other CPU instruction sets, just like
normal C and C++ programs and
libraries.
Next, why use them? The primary
purpose for mixed mode assemblies is
as "glue", to e.g. use a C++ library
class as a base class of a managed
class. This allows the managed class
to extend unmanaged methods, allowing
the managed code to be polymorphic
with respect to existing unmanaged
functions. This is extremely useful in
many contexts. However, as something
like this involves extending a C++
class, it requires that the compiler
know all about the C++ compiler ABI
(name mangling, virtual function table
generation and placement, exception
behavior), and thus effectively
requires native code. If the base
class is within a separate .dll, this
will also require that the mixed mode
assembly list the native .dll as a
dependency, so that the native library
is also loaded when the assembly is
loaded.
The other thing that mixed mode
assemblies support is the ability to
export new C functions so that other
programs can LoadLibrary() the
assembly and GetProcAddress the
exported C function.
Both of these capabilities require
that the shared library loader for the
platform support Portable Executable
(PE) files, as assemblies are PE
files. If the shared library loader
supports PE files, then the loader can
ensure that when the assembly is
loaded, all listed dependent libraries
are also loaded (case 1), or that
native apps will be able to load the
assembly as if it were a native DLL
and resolve DLL entry points against
it.
Source
I had this issue, tried the answer above and it did not work.
After much reading and trial and error and not finding anything that worked I noticed that I had both imported the Mysql dlls and added them in properties. After I removed the import statements it worked.
I know it was removing the import statements because I tested between every change I tried.
Hope that helps somebody.
Related
I've working on project in vs2005, to make compact framework app to be launched under wince 6.0.
In order to do that, I created the new project for the smart device.
creation of a new sda project
then I added a reference EasyModbus.dll.
Prior to this I copied the "EasyModbus.dll" file into the folder with project. Furthermore I added some code intending to Import the methods of this DLL into this project. When typing statement "Imports EasyModbus" I was surprised on having complained about error:
Namespace or type specified in the ImportsEasyModbus doesn't contain any public member or cannot be found. Make sure the namesppace or the type is defined and contains at least one public member. Make sure the imported element doesn't use any aliases
Could anyone kindly provide any suggestions, even very general and vague on possible reasons causing of emerging the error above?
"... Prior to this I copied the "EasyModbus.dll" file into the folder with project. Furthermore I added some code intending to Import the methods of this DLL into this project. ..."
I assume EasyModBus.dll is NOT a .NET CompactFramework library. I am not sure, as you did not rpovide details about "...added some code to import methods...".
If EasyModBus.dll is a native Windows CE and processor compatible DLL, then you normally use [DLLImport("EasyModBus.dll")] and then declare the native functions wrapped in .NET code. Ie:
[DllImport( "user32.dll" )]
[return: MarshalAs(UnmanagedType.Bool)]
public static extern bool EnumWindows( EnumWindowsProc lpEnumProc, IntPtr lParam );
If you can provide the DLL, I can look at and say if it is a .NET or native one.
The Hello World application, I've created in VS2005 targeting compact framework 2.0 normally launches under emulator, also on my PC. Thus I went Build ---> Build DeviceApplication1. The application 'DeviceApplication1.exe' was built. Then I copied it on SD card of target PLC with use of CER-host I reach the desktop of Win CE 6.0 find the application file and tried to launch 'DeviceApplication1.exe', but it failed to launch, though none of error reports have been generated by the Win CE 6.0.
Could anyone kindly take me to understanding, generally, what would be possible reasons of failing the application to launch on actual target device?
I have a project with a custom control overriding a default control from the system.windows.forms namespace. This works fine, but I discovered I needed to modify a DLL this project depends on with some code that needs to know about the existence of this custom class; this code uses the class name of the control to do various things.
As the project depends on the DLL, and circular dependencies are not-a-good-idea, I moved the custom class to a third DLL which is a new project by cut-and-paste, and set the project and library to depend on this new lib, and set this new library to be built first, before the two other projects, and added an assembly reference.
So far so good; I can now import this new namespace and use it in my code. But, now the existing uses of the custom control are broken in any 'designer' based code, as they still point to the default namespace. I've tried adding a reference under Project Properties > Imported namespaces, yet this is insufficient: the code likely needs to contain the explicit line imports <myNamespace>. And while this is no-problem for regular files, when you have a designer file it's important to not manually modify it.
What's the easiest proper way of informing visual studio that any custom control named say X should now be accessed as myNamespace.X?
The procedure as done in the question is correct, with one caveat: Check the .NET version, and if different set the target version to the lowest common denominator. If you use a newer Visual Studio than the original that was used to make the solution, it's likely there's a newer .NET out as well. By default, the latest .NET will be used for new projects. Visual studio will also happily attempt to build the projects with disparate .NET versions, and complain that it can't find references, then surreptitiously hide the version mismatch as a "Warning", even though linking assemblies with different targets is by default impossible.
The designer will then happily accept the custom class even if it's defined in another project.
I'm trying to interact with a .dll which will allow me to receive information from a variety of devices (Eye Gaze to be specific). The .dll is called ETUDriver and can be found at http://www.sis.uta.fi/~csolsp/projects.php however it does not come with an accompanying .h file.
I am struggling to actually load, interact and invoke functions from the .dll. A manual is supplied but it is of no help whatsoever with regards to actually setting up the code to start it off. There are three accompanying example apps (with source code) but only two of these work and one of which is in C# so is not helpful. The one that works however loads up the .dll via MFC and this is not a viable option with my code (which is intended to be used with many other projects and as such can't enforce MFC or any other libraries that are not as standard to projects).
Essentially, within the .dll is a series of classes which I need to create within my code and invoke the relevant functions of that class.
I've tried to use HRESULT hr = CoInitialize(NULL);
hr = CoCreateInstance(__uuidof(ETUDSink), NULL, CLSCTX_INPROC, __uuidof(IETUDSink), (LPVOID*)&pETUDSink);
if(pETUDSink)
{
pETUDSink->Start();
} however it always returns an error saying that the class is not registered. I can't use MFC to call the relevant .rgs file and am completely stuck on how to get this to work otherwise.
Is there a given format to doing this that I am unaware of and has anyone had experience in using the ETUDriver (or is able to get it working in C++ without use of MFC)?
Thank you for any help you can provide on this subject :)
I am not familiar with the specific DLL in question, but it sounds like you did not register the DLL on the target machine. You can do this by running regsvr32.exe or by calling the DLL's exported DllRegisterServer function or by using side-by-side assemblies. You need to do register the DLL on each machine that needs to leverage the COM functionality within it, so when you distribute your application, make sure that your installer registers the DLL if you go the regsvr32.exe route.
You can use the #import directive in Microsoft Visual C++ to load the information contained within the DLL without using a header file or rewriting it yourself based on documentation.
I'm trying to create an D application which uses a (third party) COM .dll so I can scrape a text box of another application so I can sound an error when a certain string shows up.
However the third party doesn't provide .lib, .def or .h files that go with the dll (atleast with the free trial version). I can create the .lib file with the implib tool but I don't see any of the library's functions in the created .lib.
Their (visual c++) samples use the #import directive to link it in however that is of no use for me ...
On a side note how can I get the proper interfaces (in a .di with boilerplate that does the linking) of the dll automatically? I ask so the correctness of the linkage doesn't depend on my (likely to be incorrect) translation of the functions. They do have a webpage which gives all functions but the object model is a bit chaotic to say the least.
From what I know, COM libraries only expose a few functions, required to (un)register the library and to create objects.
You can however view the interfaces and functions in a COM .dll using the OLE/COM Object Viewer. It seems it might be able to output header files (.h). Afterwards, maybe you could use htod as a starting point to converting everything to D interfaces.
The DMD distribution seems to include a .COM sample (chello.d, dclient.d, dserver.d), and at first glance it doesn't look like it would require any LIBs explicitly.
Unfortunately, I've never actually used COM in D, so I can't advise any further. I hope this helps in some way.
While I have yet to actually do COM work myself, I am trying to revive Juno over on Github/he-the-great. Part of the project is tlbimpd which is what will output a D file from a DLL.
I've tested the examples and successfully run tlbimpd. Please do try things out for your use and submit any issues.
I have 2 .net dll's which I expose to COM using REGASM. In order to simplify referencing within a COM client I would like to make these into one file.
I have tried converting both files to IDL and then copying the contents of the Library section of one into the other and then compiling back to .tlb with MIDL. This works fine for the TypeDefs within the second IDL however it seems to fail when it comes to the interfaces I copied in. OLE/COM viewer can see the interface definitions but when I try and use the TLB via COM it cant find the interfaces that I copied in.
I wanted to make sure before I spend too much time on this, that it is actually possible to meagre IDL's in this way.
Could you use ILMerge to first combine the .NET assemblies and then use REGASM on the resulting assembly?
ILMerge is a utility for merging
multiple .NET assemblies into a single
.NET assembly. It works on executables
and DLLs alike and comes with several
options for controlling the processing
and format of the output.
I don't see an obvious way this would fail. You said you merged the library sections but you didn't say you copy-pasted the interface declarations from the other .idl. That would be an obvious, but unlikely, explanation.
One failure mode is when the client app uses the type library to marshal interface pointers across apartment boundaries or out-of-process. That however requires registry keys in HKCR\Interfaces. .NET doesn't create them, you'd have to do that yourself. You'd know if you did, not much of an explanation either.
Ok so it turns out that the issues I was experiencing were not related to merging the idl's.
If you wish to merge to idl's you can do so by simply copying the content of a library section in one idl into another. Then run midl on the merged file to turn it into a tlb.