.NET Remoting on a NUnit environment

[Pedro]

Hi.

After learning about unit testing and NUnit, I decided to give it a
try. I downloaded NUnit 2.4.8 (CLR Version 2.0.50727.832) and my first
experiences worked out well, but now I'm stuck on a problem.

I have a Visual Studio 2005 (v 2.0.50727) web site project, let's call
it ProjectX. This C# project has the class ClassA, that uses .NET
Remoting.

I created the TestRunner project for running the tests. TestRunner
references the ProjectX dlls and has a class containing all the test
methods.

My problem: when I run the test that validates the creation of an
object of type ClassA, I get an exception, as if the remoting
configuration had not been done.

[Test]
public void ClassACreation()
{
System.Runtime.Remoting.RemotingConfiguration.Configure
(@"<configfilename>", false);
ClassA obj = new ClassA();
Assert.IsNotNull(obj);
}

On the other hand, if I change this method to static...

[Test]
public static void ClassACreation()
{
System.Runtime.Remoting.RemotingConfiguration.Configure
(@"<configfilename>", false);
ClassA obj = new ClassA();
Assert.IsNotNull(obj);
}

... and run it on a console application main, the ClassA object will
be created correctly.

static void Main(string[] args)
{
TestRunner.ClassACreation();
}

So my question is if there is any problem with using .NET Remoting on
a NUnit environment. Or is there some detail that I'm forgetting (I'm
not the most experienced Visual Studio programmer).

Thanks for any help.

[dmcminn_mwd]

Hi Pedro,

You might want to check whether the shadow copy has moved your
assembly but not the .config file. Try checking the Tools->Settings-
>Test Loader->Advanced "Disable Shadow Copy" option or setting the
config file name to a fully qualified path.

[Charlie Poole]

Hi All,

While it's /possible/ that disabling shadow copy may appear to
fix the problem, it requires many more steps than just checking
the box. Most likely, your tests won't even load without first
creating a deployment directory that includes everything needed,
including NUnit itself. If the experiment is successful, it may
be because of the directory restructuring rather than the
elimination of shadow copy.

However, the suggestion leads me to ask these questions:

From where do you get the configuration file name you load?
Is it a full path, relative or just a file name?

Charlie

[Pedro]

Hi all.

dmcminn_mwd said:
>You might want to check whether the shadow copy has moved your
>assembly but not the .config file. Try checking the Tools->Settings-
>>Test Loader->Advanced "Disable Shadow Copy" option or setting the
>config file name to a fully qualified path.

I tried doing that (and played around with some of the parameters),
but the result was the same.

On Apr 23, 6:13 pm, "Charlie Poole" <char...@nunit.com> wrote:
> Hi All,
>
> While it's /possible/ that disabling shadow copy may appear to
> fix the problem, it requires many more steps than just checking
> the box. Most likely, your tests won't even load without first
> creating a deployment directory that includes everything needed,
> including NUnit itself. If the experiment is successful, it may
> be because of the directory restructuring rather than the
> elimination of shadow copy.
>
> However, the suggestion leads me to ask these questions:
>
> From where do you get the configuration file name you load?
> Is it a full path, relative or just a file name?
>
> Charlie

I have the ProjectX dll, the NUnit project file (.nunit) and the
ProjectX.config file all on the same directory. The ProjectX.config is
being correctly loaded, as I can see that some of its parameters were
read.

When doing the
"System.Runtime.Remoting.RemotingConfiguration.Configure
(@"<configfilename>", false);", I refer the file (ProjectX.config,
where the remoting configuration is also located) with full path.

I also tried having two different config files: one called
ProjectX.config (read automaticaly) and one called
ProjectXRemoting.config (read by the RemotingConfiguration.Configure
method). The result was the same, unfortunately.

What do you mean by "creating a deployment directory that includes
everything needed, including NUnit itself". You mean creating a
directory with ProjectX dll, the NUnit project file (.nunit), the
ProjectX.config file and the NUnit executable?...

Thanks for your time...

[Charlie Poole]

Hi Pedro,

> I have the ProjectX dll, the NUnit project file (.nunit) and
> the ProjectX.config file all on the same directory. The
> ProjectX.config is being correctly loaded, as I can see that
> some of its parameters were read.
>
> When doing the
> "System.Runtime.Remoting.RemotingConfiguration.Configure
> (@"<configfilename>", false);", I refer the file
> (ProjectX.config, where the remoting configuration is also
> located) with full path.

I can't see why this would not work, but it's not something
I've done myself in tests.

> What do you mean by "creating a deployment directory that
> includes everything needed, including NUnit itself". You mean
> creating a directory with ProjectX dll, the NUnit project
> file (.nunit), the ProjectX.config file and the NUnit executable?...

Yes, but including all of NUnit except for it's own tests. However,
I see no reason whatsoever to be doing this.

Charlie

> Thanks for your time...
> >
>

[Pedro]

On Apr 23, 8:39 pm, "Charlie Poole" <char...@nunit.com> wrote:
> > What do you mean by "creating a deployment directory that
> > includes everything needed, including NUnit itself". You mean
> > creating a directory with ProjectX dll, the NUnit project
> > file (.nunit), the ProjectX.config file and the NUnit executable?...
>
> Yes, but including all of NUnit except for it's own tests. However,
> I see no reason whatsoever to be doing this.

I had misunderstood you. I thought you were suggesting doing that.

Anyway, I still haven't been able to get this to work. I'll try to
fiddle a little more with the configuration, but guess I'll do the
unit tests through the console application, writelining "green" or
"red" :)

Thanks

[Charlie Poole]

Hi Pedro,

> I had misunderstood you. I thought you were suggesting doing that.
>
> Anyway, I still haven't been able to get this to work. I'll
> try to fiddle a little more with the configuration, but guess
> I'll do the unit tests through the console application,
> writelining "green" or "red" :)

Can you reduce your problem to a simple example that others can
run to replicate it? Maybe we can figure out if it's a mistake
of usage or an actual bug to be fixed.

Charlie

[Charlie Poole]

Hi Pedro,

BTW, I know you started with an example, but it doesn't show how
the path to the config file is acquired.

Charlie