Comments on: CallContext and NUnit Woes http://averyblog.com/net/callcontext-and-nunit-woes/ This is not the greatest tagline in the world... this is just a tribute. Mon, 11 Jan 2010 16:36:16 +0000 http://wordpress.org/?v=2.8.4 hourly 1 By: Menard http://averyblog.com/net/callcontext-and-nunit-woes/comment-page-1/#comment-1074 Menard Mon, 13 Dec 2004 16:05:00 +0000 http://averyblog.infozerk.net/?p=303#comment-1074 <p>Try marking your assembly (from AssemblyInfo.cs) with the "AllowPartiallyTrustedCallers" attribute.</p> Try marking your assembly (from AssemblyInfo.cs) with the "AllowPartiallyTrustedCallers" attribute.

]]> By: James Avery http://averyblog.com/net/callcontext-and-nunit-woes/comment-page-1/#comment-1073 James Avery Wed, 10 Nov 2004 15:15:00 +0000 http://averyblog.infozerk.net/?p=303#comment-1073 <p>It could probably do the same thing it does with assemblies now. NUnit loads assemblies and does not lock them, not anymore anyway. Your solution sounds like it would not need any user configuration which would definitly be ideal.</p> <p><br></p> <p><br>-James</p> It could probably do the same thing it does with assemblies now. NUnit loads assemblies and does not lock them, not anymore anyway. Your solution sounds like it would not need any user configuration which would definitly be ideal.

-James

]]> By: Jamie Cansdale http://averyblog.com/net/callcontext-and-nunit-woes/comment-page-1/#comment-1072 Jamie Cansdale Wed, 10 Nov 2004 09:39:00 +0000 http://averyblog.infozerk.net/?p=303#comment-1072 <p>Assembly locking would be the problem. You don't want to load user assemblies into the default test runner app domain.</p> <p><br></p> <p><br>The trick will be to completely isolate the test runner thread in the test domain. This will involve a message pump to avoid making any callbacks on that thread.</p> Assembly locking would be the problem. You don’t want to load user assemblies into the default test runner app domain.

The trick will be to completely isolate the test runner thread in the test domain. This will involve a message pump to avoid making any callbacks on that thread.

]]> By: James Avery http://averyblog.com/net/callcontext-and-nunit-woes/comment-page-1/#comment-1071 James Avery Tue, 09 Nov 2004 13:18:00 +0000 http://averyblog.infozerk.net/?p=303#comment-1071 <p>That is what I suggested to Jamie. Perhaps have an assembly folders configuration option in NUnit where you could specify the folders where your assembly lives.</p> <p><br></p> <p><br>I am not sure if this is the route he will take or not though.</p> <p><br></p> <p><br>-James</p> That is what I suggested to Jamie. Perhaps have an assembly folders configuration option in NUnit where you could specify the folders where your assembly lives.

I am not sure if this is the route he will take or not though.

-James

]]> By: TomB http://averyblog.com/net/callcontext-and-nunit-woes/comment-page-1/#comment-1070 TomB Tue, 09 Nov 2004 13:15:00 +0000 http://averyblog.infozerk.net/?p=303#comment-1070 <p>Maybe if it was possible to set the BaseDirectory property of the AppDomain that nUnit creates... (instead of using nUnit's home directory it could be configured to be the bin folder where your assemblies lived)</p> Maybe if it was possible to set the BaseDirectory property of the AppDomain that nUnit creates… (instead of using nUnit’s home directory it could be configured to be the bin folder where your assemblies lived)

]]> By: Darren Neimke http://averyblog.com/net/callcontext-and-nunit-woes/comment-page-1/#comment-1069 Darren Neimke Tue, 09 Nov 2004 07:42:00 +0000 http://averyblog.infozerk.net/?p=303#comment-1069 <p>Maybe by putting your code on one side of an Interface and, when you run your unit tests, put in some stub code to implement the interface?</p> Maybe by putting your code on one side of an Interface and, when you run your unit tests, put in some stub code to implement the interface?

]]>