Re: [nunit-discuss] CoInitializeSecurity call fails with error code RPC_E_TOO_LATE in NUnit test case

[Simone Busoli]

Hi Seena,

I'm not very familiar with COM but after a quick search I found some information which may be relevant. 

First, NUnit is not calling CoInitializeSecurity, and it turns out that the CLR might be calling it before starting to execute any managed code. See here: http://www.pinvoke.net/default.aspx/ole32/CoInitializeSecurity.html

Second, this feature was already requested long ago but not implemented, on which Charlie might be able to say more. See here: http://sourceforge.net/tracker/index.php?func=detail&aid=921292&group_id=10749&atid=360749

Simone

On Sun, Dec 9, 2012 at 7:45 AM, Seena P V <see...@gmail.com> wrote:

Hi,

I have a COM interop call from my C#(.Net4) assembly, which needs CoinitializeSecurity() method to be called before invoking the assembly method. The method works perfectly through my stand alone console application created in C#. But when i try to invoke same method through NUnit (2.5.9), the CoinitialzeSecurity call fails with the error RPC_E_TOO_LATE.

I believe NUnit calls CoInitializeSecurity internally.Please explain us the reported issue and let us know is there an option to override the security parameters.

Thanks in advance.
Regards,
Seena

--
You received this message because you are subscribed to the Google Groups "NUnit-Discuss" group.
To view this discussion on the web visit https://groups.google.com/d/msg/nunit-discuss/-/oDMLdNJLFMgJ.
To post to this group, send email to nunit-...@googlegroups.com.
To unsubscribe from this group, send email to nunit-discus...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nunit-discuss?hl=en.

[Charlie Poole]

I think the old request was simply left behind when we moved from
SourceForge to Launchpad. I converted all true bugs but not feature
requests, figuring they would come up again if they were really
important.

Charlie

[Charlie Poole]

What's the simplest call to CoInitializeSecurity that results in an
RPC_E_TOO_LATE under NUnit, but not under a standalone app? I'll
experiment with a few ideas.

Also, are you running the tests under Visual Studio? If so, try
running them stand-alone from the command line. You could also try
disabling the VS host process.

Charlie

[Seena P V]

Hi Simone and Charlie,

Thanks for the reply.

I have confirmed that this is not issue with NUnit. I have tried the same method invoke from a Windows Form Project and same error occurs with the CoinitializeSecurity call.

I am using the below call to CoInitializeSecurity:

CoInitializeSecurity(
                                        IntPtr.Zero,
                                        -1,
                                        IntPtr.Zero,
                                        IntPtr.Zero,
                                        SecurityHelper.RpcAuthnLevel.PktPrivacy,
                                        SecurityHelper.RpcImpLevel.Delegate,
                                        IntPtr.Zero,
                                        SecurityHelper.EoAuthnCap.SecureRefs | SecurityHelper.EoAuthnCap.DynamicCloaking,
                                        IntPtr.Zero);

The method is same from my Standalone Console project and NUnit.

Regards,
Seena

[Seena P V]

One correction to the previous update.

I was debugging and executing the Windows Form project. If it is executed directly, the CoInitializeSecurity() returns success from Windows form application.

Seena

[Himanshu Kale]

Did anything come out of this issue? I want to know how I can tell nunit to CoInitializeSecurity a certain way.

Thanks,

Himanshu

[Charlie Poole]

As you see, this feature has a long history of discussion. In the last
iteration (2012), the OP reported that it was not a problem with
NUnit, and we stopped worrying about it. Looking at it now, I see that
her later post implies it really continued to be a problem, but I
missed that at the time.

Assuming you had a way to tell NUnit to do it, such as a command-line
option, exactly what would you want NUnit to do?

> To unsubscribe from this group and stop receiving emails from it, send an
> email to nunit-discus...@googlegroups.com.

> To post to this group, send email to nunit-...@googlegroups.com.

> Visit this group at https://groups.google.com/group/nunit-discuss.
> For more options, visit https://groups.google.com/d/optout.

[Charlie Poole]

I looked back at the old (2004!) request on SourceForge. That user was
very precise about what he wanted done, but you may want different
initialization. In any case, I see some issues:

1. This code would only apply on a windows platform. It could be quite
difficult to include in an assembly intended to run cross-platform.

2. We would probably want to do it in the agent process that runs
tests, not in the gui or console runner.

3. It seems like a fair bit of work for something that has been
requested three times over 12 years!

Charlie

[himanshukale@gmail]

I see. 

I was hoping to get COM security initialized with Multi Threaded Apartment mode (MTAThread )and for the process to impersonate,

"NativeMethods.CoInitializeSecurity(IntPtr.Zero, -1, IntPtr.Zero, IntPtr.Zero, NativeMethods.RpcAuthnLevel.None, NativeMethods.RpcImpLevel.Impersonate, IntPtr.Zero, NativeMethods.EoAuthnCap.None, IntPtr.Zero)"

This would have to be done at the very beginning of the process. My code does it in Main function in C#.

nunit3-console.exe would be the right place if I am correct. It is already being initialized for STAThread model.

https://github.com/nunit/nunit/blob/master/src/NUnitConsole/nunit3-console/Program.cs

Would it be possible to provide minimal settings for Coinitializesecurity and the thread model using console.exe parameters? 

You received this message because you are subscribed to a topic in the Google Groups "NUnit-Discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nunit-discuss/uu9PQMhn3FY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to nunit-discus...@googlegroups.com.

[Charlie Poole]

Well, initializing it in the console runner main would only be useful
to you if your tests were being run in that process. Since the default
is to run tests in a separate process, I think that the nunit-agent
process would really need to be initialized in order to do it
correctly.

Note too that the STAThread attribute on the Main has nothing to do
with the threads on which tests are run. Test threads are entirely
separate from the main thread for either the console runner or the
agent.

You may want to create an issue for this at
https://github.com/nunit/nunit/issues. It's likely to be a relatively
low priority unless you or someone else who wants it is willing to
work on it.

[himanshukale@gmail]

I had to initialize it both in the console runner and the agent process for it to work. 

I opened an issue to track and will experiment a little more before proposing a solution. Thanks.

[Charlie Poole]

You would have to do it in the console runner if we allowed you to run
tests like those in question in process. I was assuming we would
forbid that, just as you can't run tests with the --x86 option in
process.

I don't see the issue. Are you sure you finished submitting it?

Charlie

[himanshukale@gmail]

I see. you mean the setting can just be used for the agent process after forcing users to use 'separate' process for the option, I take.

Here's the issue,

https://github.com/nunit/nunit/issues/1269

[Charlie Poole]

Exactly. Since we use a process per test assembly by default in 3.0,
that simply means rejecting any options that force running in process
in this situation.

Figuring out how we tell it's needed and exactly what is needed is for
the issue you created, which I now see.

Charlie

On Mon, Feb 15, 2016 at 12:09 PM, himanshukale@gmail