+1 :-) NUnit plugins for VS2010: Visual Nunit 2010: http://visualstudiogallery.msdn.microsoft.com/c8164c71-0836-4471-80ce-633383031099?SRC=VSIDE TestDriven.Net: http://visualstudiogallery.msdn.microsoft.com/3a1fdba7-eadd-4b35-84fd-ec3d559e657d?SRC=VSIDE Continuous Testing for Visual Studio 2010: http://visualstudiogallery.msdn.microsoft.com/c074d3c6-71e2-4628-9e7c-7690e706aef4?SRC=VSIDE
to name just a few. And for the express editions of VS2010, one could always use the NUnit Gui and NUnit console applications to run the test suites. --- Adar Wesley On Mon, Feb 14, 2011 at 12:52 PM, Atsushi Eno < atsushi...@veritas-vos-liberabit.com> wrote: > I noticed another issue: the project does not support tests. Test > project will require NUnit addin (am not sure if it exists for 2010) and > thus excludes Express users. > But that should not mean that it's okay for Windows-based hackers to > totally ignore those NUnit tests. > > It might be still possible to not be based on nunit adding but rather > include a standalone test runner project (executable) that includes all > nunit stuff. > > Atsushi Eno > > (2011/02/14 18:52), Atsushi Eno wrote: > > The newer system should be as convenient as dll.sources model. Without > > as easy step as to add just one line for new Foo.cs in Bar.dll.sources > > (or more importantly for contribution, FooTest.cs in > > Bar_test.dll.sources), I'm not likely enthusiastic to contribute new > code. > > > > So far *.dll.sources could be created like this: > > > > ls ../../build/common/*.cs */*.cs | grep -v *-check.cs> > > Foo.dll.sources > > cd Test; ls */*.cs> ../Foo_test.dll.sources; cd .. > > > > Atsushi Eno > > > > (2011/02/13 12:11), Miguel de Icaza wrote: > >> Hello guys, > >> > >> I have resumed my work on creating visual studio project files for > >> our assemblies. I have checked the solutions, currently these > >> solutions are intended to be used by developers that want to build > >> their code with Visual Studio. Although currently you must invoke > >> msbuild/xbuild or virtual studio on a project-by-project basis, the > >> idea would be to do use these files to drive the entire build process > >> on Windows. Since this is a weekend, I do not have a Windows machine > >> handy to test the process there. > >> > >> Ideally, we can turn this into building Mono entirely using > >> msbuild, which should be a lot faster than using the cygwin/makefile > >> setup. > >> > >> The solution files are generated from the actual configuration > >> data used in the Makefiles, so it should be easy to keep the visual > >> studio solutions in sync with any changes that happens to the > >> makefiles. Currently the process works by extracting the arguments > >> list from an actual build of Mono and this produces the flags in the > >> file mono/msvc/scripts/order.xml. Then the genproj tool in > >> mono/msvc/scripts is used to populate all of the solution files from > >> this input. This means that either a cygwin or Unix system is > >> required to maintain the order.xml file, but with an up-to-date > >> order.xml file, we should be able to keep the build in sync. > >> > >> Would love to hear your feedback > >> > >> Miguel > >> _______________________________________________ > >> Mono-devel-list mailing list > >> Mono-devel-list@lists.ximian.com > >> http://lists.ximian.com/mailman/listinfo/mono-devel-list > >> > >> > >> > > _______________________________________________ > > Mono-devel-list mailing list > > Mono-devel-list@lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > > > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list >
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
