[Mono-dev] csproj files for Mono's class libraries.

[Atsushi Eno]

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 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
>
>
>