| Age | Commit message (Collapse) | Author |
|---|
|
Changes will default Windows SDK version as well as Platform Toolset to
the default versions used in the targeted VS version. If the projects are
opened up in VS2015, it should default to Windows SDK 8.1 and v140, but if
the same projects are opened in VS2019, it will default to latest Windows SDK 10
and v142. This way the project files should adapt to used VS version, meaning
that we could still build them using VS2015 (what's currently used on CI) but also
using VS2017 and VS2019. There should not be a need to install any previous versions
of build tools, unless an older version is targeted. It is also possible to set
PlatformToolset when calling msbuild and that should adapt to corresponding default
Windows SDK version for targeted toolset version.
Commit makes many changes and adjustments, aligning all vcxproj files but changes
should not affect build output.
|
|
They can be used with native line endings.
We now have a shared folder with the dotnet repos and they have CRLF normalization enabled.
This difference leads to conflicts while applying changes from the dotnet repos to mono.
|
|
additional test/debug projects. (#3420)
* Fixing linker warning when building libmono DLL.
After splitting mono runtime into a static library used when building libmono
DLL, we got a linker warning since there were no object files left in the
libmono project. There was also a sematic issue with the current organization
of DllMain since it is located in driver.c that will be compiled into the static
library and then consumed by the linker building the DLL. In cases where the
static library was consumed directly it would still include DllMain entry point.
By splitting the DllMain method implementation into a separate specific windows file
we can both resolve the linker warning and remove the DllMain method implementation from the static
library and only include it when building the libmono DLL.
* Visual Studio projects support to optimally link mono applications using static libmono library.
Added a new property, MONO_USE_STATIC_LIBMONO that can be used to link some
mono applications, for example mono(-sgen).exe, towards static version of libmono.
This gives us the option to build a binary without dependencies on other runtime binaries
minimizing what’s needs to be deployed in order to run mono. This in combination with static linked c-runtime
(another option available through a VS property) will produce a mono runtime binary without
addition dependencies except .NET assemblies deployed by mono runtime users.
The default is still using the dynamic version of libmono as before.
* Visual Studio project to test/debug testdriver tests from within Visual Studio.
Added an additional Visual Studio project preconfigured to run testdriver related tests
directly from within Visual Studio.
Commit also includes an additional configuration script that can be used test projects in order
to setup a mono config file. The testdriver project uses this to create a unique configuration
files pointing to the build libtest.dll for running configuration. The configuration file will then
be used when the tests are executed to make sure the correct libtest.dll for current build configuration
gets used when running test different tests from within the Visual Studio debugger.
The project comes with a number of user macros as well that can be used in order to tailor how the tests are run.
Most of the values are preconfigured and shouldn't need to be changed in order to use
current build. In order to change the test that is executed, use the following user macro
defined in mono-testdriver-test property sheet added to the project:
MONO_TESTDRIVER_RUN_TARGET
and point it to the assembly hosting the tests to execute from within Visual Studio.
* Visual Studio project to test/debug nunit tests from within Visual Studio.
Added an additional Visual Studio project preconfigured to run nunit related tests
directly from within Visual Studio.
The project comes with a number of user macros as well that can be used in order to tailor how the tests are run.
Most of the values are preconfigured and shouldn't need to be changed in order to use
current build. In order to change the test that is executed, use the following user macro
defined in mono-nunit-test property sheet added to the project:
MONO_NUNIT_RUN_TARGET
and point it to the assembly hosting the tests to execute from within Visual Studio.
There is also an additional user macro defined:
MONO_NUNIT_FIXTURE
This can be used to limit the number of nunit test run within a test suite.
|
|
Added a couple of new/updated test/debug Visual Studio utility projects.
These projects can be used to quicker get up to speed when there is a need
to run/test/debug mono runtime tests inside Visual Studio debugger.
Added utility projects can be used to run mini regression tests using JIT as
well as compile/run full AOT:ed versions of mini regression tests or other assemblies.
The different .prop files are also organized so they can be reused when adding additional
run/test/debug projects going forward.
|
|
|
|
on platform.
|
|
|
|
* Added regression test running mono/mini --regression [regression_tests]
* Added regression test running mono/mini --aot [regression_tests]
* Added default debugging options to run regression tests from within visual studio debugger.
* On new build system, setting up include folder if not availalble.
All changes applies to debug/release 32/64 bit.
|
|
* Updated vs project files to resolve winsock, winsock2 build dependecies.
* Added vs project running basic mono-mini regression tests.
|
