[Mono-dev] csproj files for Mono's class libraries.
adar.wesley at gmail.com
Mon Feb 14 06:16:40 EST 2011
NUnit plugins for VS2010:
Visual Nunit 2010:
Continuous Testing for Visual Studio 2010:
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.
On Mon, Feb 14, 2011 at 12:52 PM, Atsushi Eno <
atsushieno at 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
> > 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 at lists.ximian.com
> >> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> > _______________________________________________
> > Mono-devel-list mailing list
> > Mono-devel-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-devel-list