One for the brave...

devenv nunitaddin.sln /build Debug
sln2wxs nunitaddin.sln /config Debug
candle nunitaddin.wxs
light nunitaddin.wixobj
ren *.msi NUnitAddIn-0.6.207d.msi
dir *.msi

01/05/2004  15:09           845,312 NUnitAddIn-0.6.207d.msi
               1 File(s)        845,312 bytes
               0 Dir(s)   2,674,440,704 bytes free

11 Comments

  • !!!

    what's new?

  • There is indeed lots of new stuff. I'm planning to make a series of posts explaining the new (and old) functionality. Let me know if you have any topic requests.



    Thanks, Jamie.

  • How to test with NProf and all those things would be great.

    A big "what's new" bullet list would be another one I'd like to see.

  • Yes, yes I would like to know! Anything with the Compact FW?

  • Very good version. Principally (at least for me) the ability to debug the tests. But, I'm not able to run tests for the NUnitASP framework. Once a test is derived from NUnit.Extensions.Asp.WebFormTestCase the NUnit add-in does not recognizes it as a test. (But it works ok with NUnit Gui). Am I doing something wrong? Can I make something to do it work? Thanks.

  • Hi Luis,



    Any chance you could zip up a project that shows this issue any make it available somewhere for me?



    Thanks, Jamie.

  • It seems the problem is...



    NUnit.Extensions.Asp.WebFormTestCase

    Assembly: NUnitAsp, Version=1.4.1.4365



    [TearDown]

    protected void BaseTearDown()

    {

    this.TearDown();

    }



    NUnit has always insisted that [Test] methods must be public. It looks like in recent builds [TearDown] must be public as well (as opposed to protected in this case).

  • Thank you very much.

    I've recompiled the NUnitASP DLL with public void BaseTearDown and now it works ok.













  • How do use your add-in with app.config files now? With the 'previous version' I managed a 'bodge' of creating one in my test project bin directory called 'NUnitAddin.TestRunner.Server.exe.config', and copying the contents of my 'real' app.config into that. Ugly but only way I could get it to work. Now this no longer works (you seem to be creating random appdomain config files in temp directory)... Can you please explain how we get it to work ?

  • App.config files should work fine if it's an EXE project. This is because Visual Studio will automaticaly rename and copy it into the bin\Debug directory. For DLL projects you will have to do this yourself. Just copy it into a file called 'bin\Debug\AssemblyName.dll.config'. If this doesn't work, you've found a but and I'll fix it ASAP!



    Thanks, Jamie.

  • Thanks for the reply mate - that does indeed do the trick. Unfortunately it is still an extra 'duplication' step to have to do for every test project assembly (in my case my DAL which my most of my test assemblies reference requires connection string information from a .config file). In the NUnit standalone GUI you can manually point to a specified .config file, rather than having to make a 'copy'. Any ideas on maybe an enhancement for your add-in to support something similar? There has to be a better way than my current copy/paste method when I make a change... ;-)



    Great tool by the way, use it all day every day. I (amongst others I am sure) would love to see a help document for it though - even a sentence on each of the context menu options would be a bonus. Your latest version has a number of interesting looking options...

Comments have been disabled for this content.