|
|
| "Willy Denoyette [MVP]" wrote:
|
| >
| > | > |
| > |
| > | "Andreas Mueller" wrote:
| > |
| > | > DrBonzo wrote:
| > | > > In order to get events back from a DCOM server (an embedded device
| > running
| > | > > Windows CE), I seem to have to turn off security for my process.
To
| > do this,
| > | > > I'm saying:
| > | > >
| > | > > int ret = CoInitializeSecurity(IntPtr.Zero, -1, IntPtr.Zero,
| > IntPtr.Zero, 1,
| > | > > 3, IntPtr.Zero, 0, IntPtr.Zero);
| > | > >
| > | > > in the constructor of the first static member of my 'Main'
executable
| > class.
| > | > > This worked OK in VisualStudio '03 under .NET v1, but no longer
works
| > under
| > | > > VisualStudio '05 under .NET v2. The 'ret' I now get is
0x80010119,
| > which
| > | > > 'Error Lookup's to:
| > | > >
| > | > > Security must be initialized before any interfaces are marshalled
or
| > | > > unmarshalled. It cannot be changed once initialized.
| > | > >
| > | > > As far as I can tell, this is the first line of my code that's
getting
| > | > > executed, so it seems that either the framework or the compiler is
| > doing
| > | > > something hidden from me.
| > | > This is correct, .NET is build on (D)COM and therefore does call
| > | > CoInitializeSecurity itself.
| > | > >
| > | > > Can anyone explain this and/or suggest a work-around?
| > | > >
| > | > >
| > | >
| > | > As this can happen any time, e.g. when .NET wants to load another
| > | > assembly before your call to CoInitializeSecurity, the only
workaround I
| > | > have found is to provide a "shim" application that just calls
| > | > CoInitializeSecurity and then hosts your application using
| > | > AppDomain.ExecuteAssembly().
| > | >
| > | > I have tested this in C# implementation and it works, if the
| > | > CoInitializeSecurity is implemented inside of he shim's app
assembly.
| > | >
| > | > static void main()
| > | > {
| > | > CoInitializeSecurity(..);
| > | > AppDomain.CurrentDomain.ExecuteAssembly("yourapp.exe");
| > | > }
| > | >
| > | > To be on the safe side we have decided to build the shim app using
raw
| > | > unmanaged C++.
| > | >
| > | > HTH,
| > | > Andy
| > | >
| > | > --
| > | > You can email me directly by removing the NOSPAm below
| > | > (e-mail address removed)
| > | >
| > |
| > | Thanks, Andy - I was afraid of something like this.
| > |
| > | I was trying to avoid being verbose, but just for completeness, here's
the
| > | solution structure (simplified):
| > |
| > | Solution: sol
| > | (project/assembly) core
| > | core.cs
| > | UI
| > | UI.cs
| > | exe
| > | (references core & UI)
| > | exe.cs
| > |
| > | exe.cs contains:
| > |
| > | public sealed class Exe {
| > | private static Core _core;
| > | . . .
| > |
| > | and the Core constructor starts off with the CoInitializeSecurity.
| > |
| > | To follow up on Andy's suggestion, I don't suppose it's possible to
mix
| > | languages in the same 'solution', is it?
| > |
| >
| > Did you read my reply?
| > The default CoInitializeSecurity is called by the CLR at the first call
into
| > COM, that is' when the first RCW get's created. That means that you need
to
| > call CoInitializeSecurity as early as you can, and the earliest is in
your
| > Main entry of the program's exe assembly. Note that setting the security
can
| > only be done and is "per process", not per application domain!!, doing
it in
| > a constructor of a dynamically loaded type make little sense unless you
| > disregard the error returned by CoInitializeSecurity.
| >
| > Willy.
| >
| >
| >
|
| Yes, Willy, I read your reply, but I'm apparently confused (basically, I'm
a
| C++ guy and inherited this C# code - this was my legator's 1st C# program
& I
| think he went a bit 'feature wild' - I see no good reason for this to be a
| multi-assembly solution, but I've been too lazy to flatten it). ... so
| what's an "RCW"? ... and how does "application domain" relate to the
| process? ... maybe I need to spend some more time with the dox.
|
| From experimenting with setting breakpoints, I can assure you that the
Core
| constructor gets executed before any Main() in the Exe class, so the 1st
COM
| call is apparently happening before even that, but I don't really
understand
| where.
This is not possible normally, the Main function is the first function
called by the CLR after the main assembly has been loaded (the exe). My
guess is that you are loading the assembly (or assemblies) from unmanaged
code through COM interop, that is, your main program is unmanaged (C++ ??)
and your .NET assemblies are registered as COM servers, right?.
If that's the case, it makes no sense to CoInitializeSecurity in an assembly
(it never does), it's too late, it's up to the main program (the unmanaged
code) to initialize COM security before calling into COM. ( that is creating
an instance of Core).
Willy.
