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