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