PNUnit - .NET target of test files

176 views
Skip to first unread message

Frank Kotarski

unread,
May 6, 2013, 6:05:12 PM5/6/13
to nunit-...@googlegroups.com
Hi guys

I'm further along with my getting started using PNUnit. I've found a strange issue though. If the test example targets .NET 4.0 or above, it fails, with the standard error that assemblies cannot be found. Otherwise, targeting below at 3.0/3.5 and the tests run successfully.

I could use any advice on the best way to fix this. I'm also going to try and debug this to see what's going on.

Any advice appreciated
-Frank
Message has been deleted

Charlie Poole

unread,
May 7, 2013, 4:01:48 PM5/7/13
to NUnit-Discuss

Yes, this is generally true and will cause failures any time you need those assemblies, with or without NUnit.

What may confuse the issue is that NUnit runs tests differently when they use a different runtime than what NUnit is using.

Charlie

On May 7, 2013 11:47 AM, "Frank" <frankk...@gmail.com> wrote:
False alarm again!

For future developers: Downgrading a .NET targeted project to earlier versions removes some important assembly references that aren't re-added when you upgrade the target back to <4.0! Lack of these references , and perhaps other configuration changes, will cause the project to fail when used with PNUnit. This goes for NUnit and PNUnit in general :) I'm new to this if it is not obvious!

Regards
-Frank

--
You received this message because you are subscribed to the Google Groups "NUnit-Discuss" group.
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 http://groups.google.com/group/nunit-discuss?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Frank

unread,
May 7, 2013, 4:03:03 PM5/7/13
to nunit-...@googlegroups.com
Sorry, I thought I solved this but have not. Is there some way to mark a test as 4.0/4.5? Is redirecting assemblies necessary?

If anyone could tell me if they've successfully gotten a PNUnit test targeting .NET 4.0/4.5 to work, that would be very helpful.

-Frank

On Monday, May 6, 2013 6:05:12 PM UTC-4, Frank wrote:

Charlie Poole

unread,
May 7, 2013, 4:07:02 PM5/7/13
to NUnit-Discuss

I haven't tried it but the minimum first step is to run the agent under 4.0/4.5.

--

Frank

unread,
May 7, 2013, 4:22:55 PM5/7/13
to nunit-...@googlegroups.com
Hi Charlie

I've been looking through the NUnit documentation for how to do this. Could you point me in the right direction? I've noticed stuff about Platform attributes on test/testfixtures, and a useLegacyV2RuntimeActivationPolicy in the NUnit conf. Not sure if any of that is useful.

Frank

unread,
May 7, 2013, 5:05:10 PM5/7/13
to nunit-...@googlegroups.com
I've built NUnit 2.6.2 from source using the archive on the NUnit site and the provided VS2012 solution with debug/any CPU. I used the build binaries for my test. It compiles a DLL with a different version than the install, and this new setup works. Would you know why building from source fixes the issue?

Thank you for your time

Charlie Poole

unread,
May 7, 2013, 5:29:30 PM5/7/13
to NUnit-Discuss

It fixes it because you built everything for 4.0. This is another way to make it run under 4.0. :-)

Now you will only encounter issues if you want to run tests under 2.0. :-)

Charlie Poole

unread,
May 7, 2013, 5:34:02 PM5/7/13
to NUnit-Discuss
There is nothing peculiar to NUnit here - to run an executable under a particular runtime, you have to edit its config file to specify that runtime as supported. For example,
 <startup>
    <supportedRuntime version="v4.0.33019" />
    ...
  </startup>

Frank

unread,
May 8, 2013, 10:48:47 AM5/8/13
to nunit-...@googlegroups.com
Thank you very much. You are correct about supportedRuntime. I'm a novice with .NET and I'm still getting a handle on how the backwards and forwards compatibility works. Specifying

   <startup>
      <supportedRuntime version="v4.0"/>
   </startup>

In the pnunit-agent.exe.config fixes this issue. And as you mentioned previously, base on MSDN's documentation:

If the <supportedRuntime> element is not present in the application configuration file, the version of the runtime used to build the application is used.

thanks again for your patience.

-Frank
Reply all
Reply to author
Forward
0 new messages