2019-11-29 17:35:30 +03:00
|
|
|
|
|
|
|
|
|
|
Microsoft Visual Studio Solution File, Format Version 12.00
|
2023-01-20 20:44:30 +03:00
|
|
|
|
# Visual Studio Version 17
|
|
|
|
|
|
VisualStudioVersion = 17.5.33209.295
|
2017-03-31 19:11:34 +03:00
|
|
|
|
MinimumVisualStudioVersion = 15.0.26124.0
|
2019-11-29 17:35:30 +03:00
|
|
|
|
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "Mono.Linker", "src\linker\Mono.Linker.csproj", "{DD28E2B1-057B-4B4D-A04D-B2EBD9E76E46}"
|
2019-02-28 23:47:03 +03:00
|
|
|
|
EndProject
|
2019-11-29 17:35:30 +03:00
|
|
|
|
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "ILLink.Tasks", "src\ILLink.Tasks\ILLink.Tasks.csproj", "{A7A026C4-DEB4-4EF6-963E-17E7B98A6527}"
|
2017-09-20 21:54:00 +03:00
|
|
|
|
EndProject
|
2019-11-29 17:35:30 +03:00
|
|
|
|
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "Mono.Linker.Tests", "test\Mono.Linker.Tests\Mono.Linker.Tests.csproj", "{400A1561-B6B6-482D-9E4C-3DDAEDE5BD07}"
|
Enable unit tests on .NET Core (#489)
This enables the unit tests to run on .NET Core. CodeDom compilation doesn't exist on core, so I've added the ability to compile in-process with Roslyn APIs. This still uses NUnit, using a recent version of NUnit package references with "dotnet test". This doesn't change how tests run on mono.
Finding the right reference assemblies for compilation is a bit different on .NET Core. As described in https://github.com/dotnet/roslyn/wiki/Runtime-code-generation-using-Roslyn-compilations-in-.NET-Core-App, they can either be found using packages (what the SDK does), or we can just compile against the implementation assemblies. In this change, I'm compiling against implementation assemblies, since that's fairly similar to what the tests do on mono, where they find them in the GAC.
For mono, the common references only included mscorlib. For .NET Core, I'm getting the common references from the "Trusted Platform Assemblies" (TPA) of the test process. As a result, package references of the test project become references during testcase compilation. Explicit references specified via `ReferenceAttribute` in a testcase are looked for alongside the host process's implementations as well (since we have no way to resolve a reference from just the filename since there is no GAC).
Other changes:
- Roslyn outputs the `DebuggableAttribute` by default but mcs does not, so when running on .NET Core, we don't check for the `DebuggableAttribute`.
- Check for core types in `System.Private.CoreLib` instead of `mscorlib`.
- There are some more edge cases that I'm in the process of cleaning up and will update soon.
At the moment, I'm trying to get the tests up and running, and I'm using plenty of compile-time conditions to modify the behavior on core. It would be nice not to have to do this - I haven't given it much thought, but maybe we could provide an abstraction that contains knowledge of the platform libraries, so that we don't have to have a hard dependency on `"mscorlib.dll"` and `"System.Private.CoreLib.dll"` everywhere? @mrvoorhe please let me know if you have any thoughts. Does the approach I'm taking so far seem sane to you?
@marek-safar
2019-03-26 23:05:14 +03:00
|
|
|
|
EndProject
|
2019-11-29 17:35:30 +03:00
|
|
|
|
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "Mono.Linker.Tests.Cases", "test\Mono.Linker.Tests.Cases\Mono.Linker.Tests.Cases.csproj", "{B6BEE6AA-ADA0-4E1D-9A17-FBF2936F82B5}"
|
Enable unit tests on .NET Core (#489)
This enables the unit tests to run on .NET Core. CodeDom compilation doesn't exist on core, so I've added the ability to compile in-process with Roslyn APIs. This still uses NUnit, using a recent version of NUnit package references with "dotnet test". This doesn't change how tests run on mono.
Finding the right reference assemblies for compilation is a bit different on .NET Core. As described in https://github.com/dotnet/roslyn/wiki/Runtime-code-generation-using-Roslyn-compilations-in-.NET-Core-App, they can either be found using packages (what the SDK does), or we can just compile against the implementation assemblies. In this change, I'm compiling against implementation assemblies, since that's fairly similar to what the tests do on mono, where they find them in the GAC.
For mono, the common references only included mscorlib. For .NET Core, I'm getting the common references from the "Trusted Platform Assemblies" (TPA) of the test process. As a result, package references of the test project become references during testcase compilation. Explicit references specified via `ReferenceAttribute` in a testcase are looked for alongside the host process's implementations as well (since we have no way to resolve a reference from just the filename since there is no GAC).
Other changes:
- Roslyn outputs the `DebuggableAttribute` by default but mcs does not, so when running on .NET Core, we don't check for the `DebuggableAttribute`.
- Check for core types in `System.Private.CoreLib` instead of `mscorlib`.
- There are some more edge cases that I'm in the process of cleaning up and will update soon.
At the moment, I'm trying to get the tests up and running, and I'm using plenty of compile-time conditions to modify the behavior on core. It would be nice not to have to do this - I haven't given it much thought, but maybe we could provide an abstraction that contains knowledge of the platform libraries, so that we don't have to have a hard dependency on `"mscorlib.dll"` and `"System.Private.CoreLib.dll"` everywhere? @mrvoorhe please let me know if you have any thoughts. Does the approach I'm taking so far seem sane to you?
@marek-safar
2019-03-26 23:05:14 +03:00
|
|
|
|
EndProject
|
2019-11-29 17:35:30 +03:00
|
|
|
|
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "Mono.Linker.Tests.Cases.Expectations", "test\Mono.Linker.Tests.Cases.Expectations\Mono.Linker.Tests.Cases.Expectations.csproj", "{2C26601F-3E2F-45B9-A02F-58EE9296E19E}"
|
Enable unit tests on .NET Core (#489)
This enables the unit tests to run on .NET Core. CodeDom compilation doesn't exist on core, so I've added the ability to compile in-process with Roslyn APIs. This still uses NUnit, using a recent version of NUnit package references with "dotnet test". This doesn't change how tests run on mono.
Finding the right reference assemblies for compilation is a bit different on .NET Core. As described in https://github.com/dotnet/roslyn/wiki/Runtime-code-generation-using-Roslyn-compilations-in-.NET-Core-App, they can either be found using packages (what the SDK does), or we can just compile against the implementation assemblies. In this change, I'm compiling against implementation assemblies, since that's fairly similar to what the tests do on mono, where they find them in the GAC.
For mono, the common references only included mscorlib. For .NET Core, I'm getting the common references from the "Trusted Platform Assemblies" (TPA) of the test process. As a result, package references of the test project become references during testcase compilation. Explicit references specified via `ReferenceAttribute` in a testcase are looked for alongside the host process's implementations as well (since we have no way to resolve a reference from just the filename since there is no GAC).
Other changes:
- Roslyn outputs the `DebuggableAttribute` by default but mcs does not, so when running on .NET Core, we don't check for the `DebuggableAttribute`.
- Check for core types in `System.Private.CoreLib` instead of `mscorlib`.
- There are some more edge cases that I'm in the process of cleaning up and will update soon.
At the moment, I'm trying to get the tests up and running, and I'm using plenty of compile-time conditions to modify the behavior on core. It would be nice not to have to do this - I haven't given it much thought, but maybe we could provide an abstraction that contains knowledge of the platform libraries, so that we don't have to have a hard dependency on `"mscorlib.dll"` and `"System.Private.CoreLib.dll"` everywhere? @mrvoorhe please let me know if you have any thoughts. Does the approach I'm taking so far seem sane to you?
@marek-safar
2019-03-26 23:05:14 +03:00
|
|
|
|
EndProject
|
2019-11-29 19:11:09 +03:00
|
|
|
|
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "analyzer", "analyzer", "{AA0569FB-73E9-4B42-9A19-714BB1229DAE}"
|
|
|
|
|
|
EndProject
|
|
|
|
|
|
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "analyzer", "src\analyzer\analyzer.csproj", "{96182221-C5C4-436D-9BE0-EC499F9BAF17}"
|
|
|
|
|
|
EndProject
|
2020-05-07 22:44:07 +03:00
|
|
|
|
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "test", "test", "{C2969923-7BAA-4FE4-853C-F670B0D3C6C8}"
|
Add reference assembly build (#1014)
* Add reference assembly build
This adds a new project that builds a reference assembly for some of
the surface area of the linker. The package is called illink. We
should finalize the name before releasing an official package. This
leaves a number of problems unsolved (described below), but provides
something we can use to start experimenting.
The preliminary included surface area contains public members of
BaseStep and its dependencies, in the FEATURE_ILLINK build flavor -
which notably makes the ref assembly incompatible with the monolinker
surface area. (illink has an AssemblyResolver derived from
Mono.Linker.DirectoryAssemblyResolver, whereas monolinker has one
derived from Mono.Cecil.BaseAssemblyResolver). Therefore the reference
assembly is currently designed for consumption by illink plugins, not
by monolinker plugins.
The reference assembly is built for netstandard2.0, chosen because it
is the lowest common denominator for netcoreapp3.0 and net471, the
TFMs for which we currently build Mono.Linker. The illink flavor
actually doesn't need to be built for net471 (only ILLink.Tasks does),
so we could choose a higher version of netstandard if we disabled that
build flavor.
The ref assembly package is unusual in a few ways, described below. We
may be able to change some of these quirks once we have a better
picture of how linker plugins will be produced and consumed.
- The package *does not* contain any implementation assemblies,
because it is not designed to be consumed by a project targeting a
platform TFM - rather it is only designed to be consumed
from *libraries* that will act as linker plugins. Attempting to
consume it directly from a netcoreapp3.0 project will work during
build, but will fail to locate illink.dll at runtime.
- The package *does not* have a transitive package dependency on
Mono.Cecil (nor does it include Mono.Cecil). This is because the
reference assembly is built against a submodule of the cecil sources,
so we do not have direct control over the package version. This
requires the custom step developer to add a dependency on Mono.Cecil.
To consume this package in a custom step, the custom step project
should:
- Target a netstandard version compatible with the reference
assembly's target framework (currently netstandard2.0).
- Include a dependency on Mono.Cecil compatible with the version
referenced during the linker build (currently 0:11:1:0, which
incidentally ships in the official Mono.Cecil package version
11.1). Attempting to use a higher version (the current latest release
is 11.2) will result in the linker failing to load the custom step.
* Add cecil to the package
This adds a new project which builds reference assemblies for
cecil. It should be kept in sync with the upstream cecil project
file. The cecil reference assembly is included into the illink package
alongside the illink.dll reference assembly.
Also prevent arcade from trying to upload a non-existent PDB for a ref
assembly.
* Set up ApiCompat
* Use .NET Foundation file header
* Pare down ref surface area
- Remove most members of Annotations
- Remove MarkingHelpers and references to it
- Remove protected members of LinkContext
- Remove UninitializedContextFactory and references to it
- Remove AssemblyResolver and references to it
* Fix undefined ExpectedFeedUrl error
The error was occurring because the early import of the Tools targets
was including Microsoft.DotNet.Build.Tasks.Feed.targets, which changed
the DefaultTargets to a publish-related target. Importing the Tools
targets later prevents overriding the DefaultTargets, causing building
to work as expected.
* Add back AnnotationStore ctor
Otherwise the implicitly-defined default ctor exists in the ref but
not the implementation. This was caught by ApiCompat.
* Build against official Mono.Cecil package
This adds an option to build against the submodule for local
development, but the new default is to build against the package.
* Minor project file cleanup
* Remove left-over files
* Further restrict public surface
* Build fix
* UseLocalCecil -> UseCecilPackage
* Use local cecil for monolinker build
* Remove Version from Mono.Linker projects
This will result in the version being taken from VersionPrefix
in Directory.Build.Props, matching the package version.
* Remove left-over reference to cecil ref build
* Copy package dependencies to ILLink.Tasks build output
This preserves the behavior of the ProjectReference dependencies,
which are always copied. The integration tests expect to find the
linker and cecil alongside ILLink.Tasks in the build output.
* Remove AssemblyAction
Co-authored-by: Marek Safar <marek.safar@gmail.com>
2020-03-25 21:44:04 +03:00
|
|
|
|
EndProject
|
2020-05-07 22:44:07 +03:00
|
|
|
|
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "ILLink.Tasks.Tests", "test\ILLink.Tasks.Tests\ILLink.Tasks.Tests.csproj", "{5A27FA80-0E28-4243-88DF-EC8A22C8BFD0}"
|
Add reference assembly build (#1014)
* Add reference assembly build
This adds a new project that builds a reference assembly for some of
the surface area of the linker. The package is called illink. We
should finalize the name before releasing an official package. This
leaves a number of problems unsolved (described below), but provides
something we can use to start experimenting.
The preliminary included surface area contains public members of
BaseStep and its dependencies, in the FEATURE_ILLINK build flavor -
which notably makes the ref assembly incompatible with the monolinker
surface area. (illink has an AssemblyResolver derived from
Mono.Linker.DirectoryAssemblyResolver, whereas monolinker has one
derived from Mono.Cecil.BaseAssemblyResolver). Therefore the reference
assembly is currently designed for consumption by illink plugins, not
by monolinker plugins.
The reference assembly is built for netstandard2.0, chosen because it
is the lowest common denominator for netcoreapp3.0 and net471, the
TFMs for which we currently build Mono.Linker. The illink flavor
actually doesn't need to be built for net471 (only ILLink.Tasks does),
so we could choose a higher version of netstandard if we disabled that
build flavor.
The ref assembly package is unusual in a few ways, described below. We
may be able to change some of these quirks once we have a better
picture of how linker plugins will be produced and consumed.
- The package *does not* contain any implementation assemblies,
because it is not designed to be consumed by a project targeting a
platform TFM - rather it is only designed to be consumed
from *libraries* that will act as linker plugins. Attempting to
consume it directly from a netcoreapp3.0 project will work during
build, but will fail to locate illink.dll at runtime.
- The package *does not* have a transitive package dependency on
Mono.Cecil (nor does it include Mono.Cecil). This is because the
reference assembly is built against a submodule of the cecil sources,
so we do not have direct control over the package version. This
requires the custom step developer to add a dependency on Mono.Cecil.
To consume this package in a custom step, the custom step project
should:
- Target a netstandard version compatible with the reference
assembly's target framework (currently netstandard2.0).
- Include a dependency on Mono.Cecil compatible with the version
referenced during the linker build (currently 0:11:1:0, which
incidentally ships in the official Mono.Cecil package version
11.1). Attempting to use a higher version (the current latest release
is 11.2) will result in the linker failing to load the custom step.
* Add cecil to the package
This adds a new project which builds reference assemblies for
cecil. It should be kept in sync with the upstream cecil project
file. The cecil reference assembly is included into the illink package
alongside the illink.dll reference assembly.
Also prevent arcade from trying to upload a non-existent PDB for a ref
assembly.
* Set up ApiCompat
* Use .NET Foundation file header
* Pare down ref surface area
- Remove most members of Annotations
- Remove MarkingHelpers and references to it
- Remove protected members of LinkContext
- Remove UninitializedContextFactory and references to it
- Remove AssemblyResolver and references to it
* Fix undefined ExpectedFeedUrl error
The error was occurring because the early import of the Tools targets
was including Microsoft.DotNet.Build.Tasks.Feed.targets, which changed
the DefaultTargets to a publish-related target. Importing the Tools
targets later prevents overriding the DefaultTargets, causing building
to work as expected.
* Add back AnnotationStore ctor
Otherwise the implicitly-defined default ctor exists in the ref but
not the implementation. This was caught by ApiCompat.
* Build against official Mono.Cecil package
This adds an option to build against the submodule for local
development, but the new default is to build against the package.
* Minor project file cleanup
* Remove left-over files
* Further restrict public surface
* Build fix
* UseLocalCecil -> UseCecilPackage
* Use local cecil for monolinker build
* Remove Version from Mono.Linker projects
This will result in the version being taken from VersionPrefix
in Directory.Build.Props, matching the package version.
* Remove left-over reference to cecil ref build
* Copy package dependencies to ILLink.Tasks build output
This preserves the behavior of the ProjectReference dependencies,
which are always copied. The integration tests expect to find the
linker and cecil alongside ILLink.Tasks in the build output.
* Remove AssemblyAction
Co-authored-by: Marek Safar <marek.safar@gmail.com>
2020-03-25 21:44:04 +03:00
|
|
|
|
EndProject
|
2020-05-07 22:44:07 +03:00
|
|
|
|
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "ref", "ref", "{03EB085F-3E2E-4A68-A7DF-951ADF59A0CC}"
|
2020-04-09 23:06:57 +03:00
|
|
|
|
EndProject
|
2020-10-27 20:02:20 +03:00
|
|
|
|
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "ILLink.RoslynAnalyzer", "src\ILLink.RoslynAnalyzer\ILLink.RoslynAnalyzer.csproj", "{F1A44A78-34EE-408B-8285-9A26F0E7D4F2}"
|
|
|
|
|
|
EndProject
|
|
|
|
|
|
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "ILLink.RoslynAnalyzer.Tests", "test\ILLink.RoslynAnalyzer.Tests\ILLink.RoslynAnalyzer.Tests.csproj", "{90D64CE4-C891-4B98-AF59-EE9B04BA1CBE}"
|
|
|
|
|
|
EndProject
|
2021-03-31 09:43:23 +03:00
|
|
|
|
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "Mono.Linker", "src\linker\ref\Mono.Linker.csproj", "{8DA71B3B-5809-44E5-A018-5DE5C6FF6C2A}"
|
2021-01-15 13:41:24 +03:00
|
|
|
|
EndProject
|
2021-03-31 09:43:23 +03:00
|
|
|
|
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "tlens", "src\tlens\tlens.csproj", "{B218CBE9-ADCE-4086-9DBF-E6C782136E6D}"
|
|
|
|
|
|
EndProject
|
|
|
|
|
|
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "ILLink.CodeFixProvider", "src\ILLink.CodeFix\ILLink.CodeFixProvider.csproj", "{6D20F334-B7E4-4585-854B-8A0E2B29B4AA}"
|
2021-01-15 13:41:24 +03:00
|
|
|
|
EndProject
|
2023-01-20 20:44:30 +03:00
|
|
|
|
Project("{D954291E-2A0B-460D-934E-DC6B0785DB48}") = "ILLink.Shared", "src\ILLink.Shared\ILLink.Shared.shproj", "{FF598E93-8E9E-4091-9F50-61A7572663AE}"
|
2021-07-20 19:58:50 +03:00
|
|
|
|
EndProject
|
2022-02-05 03:00:23 +03:00
|
|
|
|
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "ILLink.RoslynAnalyzer.Tests.Generator", "test\ILLink.RoslynAnalyzer.Tests.Generator\ILLink.RoslynAnalyzer.Tests.Generator.csproj", "{3DDE7064-4B68-4979-8843-FDF4CE5A5140}"
|
|
|
|
|
|
EndProject
|
2023-01-20 20:44:30 +03:00
|
|
|
|
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "external", "external", "{8FD57ADB-B449-4960-A141-845C1E2E26EC}"
|
|
|
|
|
|
EndProject
|
|
|
|
|
|
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Mono.Cecil", "external\cecil\Mono.Cecil.csproj", "{7C068318-84AF-4861-9E5F-6F8A3BF38C9D}"
|
|
|
|
|
|
EndProject
|
|
|
|
|
|
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "cecil", "cecil", "{223B8007-F26C-4E28-B28D-E43C97F7EE23}"
|
|
|
|
|
|
EndProject
|
|
|
|
|
|
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "symbols", "symbols", "{19C783E3-B710-4F25-A977-0ADDA4D2CFEE}"
|
|
|
|
|
|
EndProject
|
|
|
|
|
|
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Mono.Cecil.Pdb", "external\cecil\symbols\pdb\Mono.Cecil.Pdb.csproj", "{AF7722A0-D1A7-4294-A181-B88B6BD67C6E}"
|
|
|
|
|
|
EndProject
|
2017-03-31 19:11:34 +03:00
|
|
|
|
Global
|
|
|
|
|
|
GlobalSection(SolutionConfigurationPlatforms) = preSolution
|
|
|
|
|
|
Debug|Any CPU = Debug|Any CPU
|
|
|
|
|
|
Debug|x64 = Debug|x64
|
|
|
|
|
|
Debug|x86 = Debug|x86
|
|
|
|
|
|
Release|Any CPU = Release|Any CPU
|
|
|
|
|
|
Release|x64 = Release|x64
|
|
|
|
|
|
Release|x86 = Release|x86
|
|
|
|
|
|
EndGlobalSection
|
|
|
|
|
|
GlobalSection(ProjectConfigurationPlatforms) = postSolution
|
2020-02-06 12:57:51 +03:00
|
|
|
|
{DD28E2B1-057B-4B4D-A04D-B2EBD9E76E46}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{DD28E2B1-057B-4B4D-A04D-B2EBD9E76E46}.Debug|Any CPU.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{DD28E2B1-057B-4B4D-A04D-B2EBD9E76E46}.Debug|x64.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{DD28E2B1-057B-4B4D-A04D-B2EBD9E76E46}.Debug|x64.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{DD28E2B1-057B-4B4D-A04D-B2EBD9E76E46}.Debug|x86.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{DD28E2B1-057B-4B4D-A04D-B2EBD9E76E46}.Debug|x86.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{DD28E2B1-057B-4B4D-A04D-B2EBD9E76E46}.Release|Any CPU.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{DD28E2B1-057B-4B4D-A04D-B2EBD9E76E46}.Release|Any CPU.Build.0 = Release|Any CPU
|
|
|
|
|
|
{DD28E2B1-057B-4B4D-A04D-B2EBD9E76E46}.Release|x64.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{DD28E2B1-057B-4B4D-A04D-B2EBD9E76E46}.Release|x64.Build.0 = Release|Any CPU
|
|
|
|
|
|
{DD28E2B1-057B-4B4D-A04D-B2EBD9E76E46}.Release|x86.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{DD28E2B1-057B-4B4D-A04D-B2EBD9E76E46}.Release|x86.Build.0 = Release|Any CPU
|
2019-02-26 11:53:53 +03:00
|
|
|
|
{A7A026C4-DEB4-4EF6-963E-17E7B98A6527}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{A7A026C4-DEB4-4EF6-963E-17E7B98A6527}.Debug|Any CPU.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{A7A026C4-DEB4-4EF6-963E-17E7B98A6527}.Debug|x64.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{A7A026C4-DEB4-4EF6-963E-17E7B98A6527}.Debug|x64.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{A7A026C4-DEB4-4EF6-963E-17E7B98A6527}.Debug|x86.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{A7A026C4-DEB4-4EF6-963E-17E7B98A6527}.Debug|x86.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{A7A026C4-DEB4-4EF6-963E-17E7B98A6527}.Release|Any CPU.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{A7A026C4-DEB4-4EF6-963E-17E7B98A6527}.Release|Any CPU.Build.0 = Release|Any CPU
|
|
|
|
|
|
{A7A026C4-DEB4-4EF6-963E-17E7B98A6527}.Release|x64.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{A7A026C4-DEB4-4EF6-963E-17E7B98A6527}.Release|x64.Build.0 = Release|Any CPU
|
|
|
|
|
|
{A7A026C4-DEB4-4EF6-963E-17E7B98A6527}.Release|x86.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{A7A026C4-DEB4-4EF6-963E-17E7B98A6527}.Release|x86.Build.0 = Release|Any CPU
|
2020-02-06 12:57:51 +03:00
|
|
|
|
{400A1561-B6B6-482D-9E4C-3DDAEDE5BD07}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{400A1561-B6B6-482D-9E4C-3DDAEDE5BD07}.Debug|Any CPU.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{400A1561-B6B6-482D-9E4C-3DDAEDE5BD07}.Debug|x64.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{400A1561-B6B6-482D-9E4C-3DDAEDE5BD07}.Debug|x64.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{400A1561-B6B6-482D-9E4C-3DDAEDE5BD07}.Debug|x86.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{400A1561-B6B6-482D-9E4C-3DDAEDE5BD07}.Debug|x86.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{400A1561-B6B6-482D-9E4C-3DDAEDE5BD07}.Release|Any CPU.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{400A1561-B6B6-482D-9E4C-3DDAEDE5BD07}.Release|Any CPU.Build.0 = Release|Any CPU
|
|
|
|
|
|
{400A1561-B6B6-482D-9E4C-3DDAEDE5BD07}.Release|x64.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{400A1561-B6B6-482D-9E4C-3DDAEDE5BD07}.Release|x64.Build.0 = Release|Any CPU
|
|
|
|
|
|
{400A1561-B6B6-482D-9E4C-3DDAEDE5BD07}.Release|x86.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{400A1561-B6B6-482D-9E4C-3DDAEDE5BD07}.Release|x86.Build.0 = Release|Any CPU
|
|
|
|
|
|
{B6BEE6AA-ADA0-4E1D-9A17-FBF2936F82B5}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{B6BEE6AA-ADA0-4E1D-9A17-FBF2936F82B5}.Debug|Any CPU.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{B6BEE6AA-ADA0-4E1D-9A17-FBF2936F82B5}.Debug|x64.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{B6BEE6AA-ADA0-4E1D-9A17-FBF2936F82B5}.Debug|x64.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{B6BEE6AA-ADA0-4E1D-9A17-FBF2936F82B5}.Debug|x86.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{B6BEE6AA-ADA0-4E1D-9A17-FBF2936F82B5}.Debug|x86.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{B6BEE6AA-ADA0-4E1D-9A17-FBF2936F82B5}.Release|Any CPU.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{B6BEE6AA-ADA0-4E1D-9A17-FBF2936F82B5}.Release|Any CPU.Build.0 = Release|Any CPU
|
|
|
|
|
|
{B6BEE6AA-ADA0-4E1D-9A17-FBF2936F82B5}.Release|x64.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{B6BEE6AA-ADA0-4E1D-9A17-FBF2936F82B5}.Release|x64.Build.0 = Release|Any CPU
|
|
|
|
|
|
{B6BEE6AA-ADA0-4E1D-9A17-FBF2936F82B5}.Release|x86.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{B6BEE6AA-ADA0-4E1D-9A17-FBF2936F82B5}.Release|x86.Build.0 = Release|Any CPU
|
|
|
|
|
|
{2C26601F-3E2F-45B9-A02F-58EE9296E19E}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{2C26601F-3E2F-45B9-A02F-58EE9296E19E}.Debug|Any CPU.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{2C26601F-3E2F-45B9-A02F-58EE9296E19E}.Debug|x64.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{2C26601F-3E2F-45B9-A02F-58EE9296E19E}.Debug|x64.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{2C26601F-3E2F-45B9-A02F-58EE9296E19E}.Debug|x86.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{2C26601F-3E2F-45B9-A02F-58EE9296E19E}.Debug|x86.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{2C26601F-3E2F-45B9-A02F-58EE9296E19E}.Release|Any CPU.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{2C26601F-3E2F-45B9-A02F-58EE9296E19E}.Release|Any CPU.Build.0 = Release|Any CPU
|
|
|
|
|
|
{2C26601F-3E2F-45B9-A02F-58EE9296E19E}.Release|x64.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{2C26601F-3E2F-45B9-A02F-58EE9296E19E}.Release|x64.Build.0 = Release|Any CPU
|
|
|
|
|
|
{2C26601F-3E2F-45B9-A02F-58EE9296E19E}.Release|x86.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{2C26601F-3E2F-45B9-A02F-58EE9296E19E}.Release|x86.Build.0 = Release|Any CPU
|
|
|
|
|
|
{96182221-C5C4-436D-9BE0-EC499F9BAF17}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{96182221-C5C4-436D-9BE0-EC499F9BAF17}.Debug|Any CPU.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{96182221-C5C4-436D-9BE0-EC499F9BAF17}.Debug|x64.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{96182221-C5C4-436D-9BE0-EC499F9BAF17}.Debug|x64.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{96182221-C5C4-436D-9BE0-EC499F9BAF17}.Debug|x86.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{96182221-C5C4-436D-9BE0-EC499F9BAF17}.Debug|x86.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{96182221-C5C4-436D-9BE0-EC499F9BAF17}.Release|Any CPU.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{96182221-C5C4-436D-9BE0-EC499F9BAF17}.Release|Any CPU.Build.0 = Release|Any CPU
|
|
|
|
|
|
{96182221-C5C4-436D-9BE0-EC499F9BAF17}.Release|x64.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{96182221-C5C4-436D-9BE0-EC499F9BAF17}.Release|x64.Build.0 = Release|Any CPU
|
|
|
|
|
|
{96182221-C5C4-436D-9BE0-EC499F9BAF17}.Release|x86.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{96182221-C5C4-436D-9BE0-EC499F9BAF17}.Release|x86.Build.0 = Release|Any CPU
|
2020-04-09 23:06:57 +03:00
|
|
|
|
{5A27FA80-0E28-4243-88DF-EC8A22C8BFD0}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{5A27FA80-0E28-4243-88DF-EC8A22C8BFD0}.Debug|Any CPU.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{5A27FA80-0E28-4243-88DF-EC8A22C8BFD0}.Debug|x64.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{5A27FA80-0E28-4243-88DF-EC8A22C8BFD0}.Debug|x64.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{5A27FA80-0E28-4243-88DF-EC8A22C8BFD0}.Debug|x86.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{5A27FA80-0E28-4243-88DF-EC8A22C8BFD0}.Debug|x86.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{5A27FA80-0E28-4243-88DF-EC8A22C8BFD0}.Release|Any CPU.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{5A27FA80-0E28-4243-88DF-EC8A22C8BFD0}.Release|Any CPU.Build.0 = Release|Any CPU
|
|
|
|
|
|
{5A27FA80-0E28-4243-88DF-EC8A22C8BFD0}.Release|x64.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{5A27FA80-0E28-4243-88DF-EC8A22C8BFD0}.Release|x64.Build.0 = Release|Any CPU
|
|
|
|
|
|
{5A27FA80-0E28-4243-88DF-EC8A22C8BFD0}.Release|x86.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{5A27FA80-0E28-4243-88DF-EC8A22C8BFD0}.Release|x86.Build.0 = Release|Any CPU
|
2020-10-27 20:02:20 +03:00
|
|
|
|
{F1A44A78-34EE-408B-8285-9A26F0E7D4F2}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{F1A44A78-34EE-408B-8285-9A26F0E7D4F2}.Debug|Any CPU.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{F1A44A78-34EE-408B-8285-9A26F0E7D4F2}.Debug|x64.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{F1A44A78-34EE-408B-8285-9A26F0E7D4F2}.Debug|x64.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{F1A44A78-34EE-408B-8285-9A26F0E7D4F2}.Debug|x86.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{F1A44A78-34EE-408B-8285-9A26F0E7D4F2}.Debug|x86.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{F1A44A78-34EE-408B-8285-9A26F0E7D4F2}.Release|Any CPU.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{F1A44A78-34EE-408B-8285-9A26F0E7D4F2}.Release|Any CPU.Build.0 = Release|Any CPU
|
|
|
|
|
|
{F1A44A78-34EE-408B-8285-9A26F0E7D4F2}.Release|x64.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{F1A44A78-34EE-408B-8285-9A26F0E7D4F2}.Release|x64.Build.0 = Release|Any CPU
|
|
|
|
|
|
{F1A44A78-34EE-408B-8285-9A26F0E7D4F2}.Release|x86.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{F1A44A78-34EE-408B-8285-9A26F0E7D4F2}.Release|x86.Build.0 = Release|Any CPU
|
|
|
|
|
|
{90D64CE4-C891-4B98-AF59-EE9B04BA1CBE}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{90D64CE4-C891-4B98-AF59-EE9B04BA1CBE}.Debug|Any CPU.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{90D64CE4-C891-4B98-AF59-EE9B04BA1CBE}.Debug|x64.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{90D64CE4-C891-4B98-AF59-EE9B04BA1CBE}.Debug|x64.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{90D64CE4-C891-4B98-AF59-EE9B04BA1CBE}.Debug|x86.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{90D64CE4-C891-4B98-AF59-EE9B04BA1CBE}.Debug|x86.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{90D64CE4-C891-4B98-AF59-EE9B04BA1CBE}.Release|Any CPU.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{90D64CE4-C891-4B98-AF59-EE9B04BA1CBE}.Release|Any CPU.Build.0 = Release|Any CPU
|
|
|
|
|
|
{90D64CE4-C891-4B98-AF59-EE9B04BA1CBE}.Release|x64.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{90D64CE4-C891-4B98-AF59-EE9B04BA1CBE}.Release|x64.Build.0 = Release|Any CPU
|
|
|
|
|
|
{90D64CE4-C891-4B98-AF59-EE9B04BA1CBE}.Release|x86.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{90D64CE4-C891-4B98-AF59-EE9B04BA1CBE}.Release|x86.Build.0 = Release|Any CPU
|
2021-01-15 13:41:24 +03:00
|
|
|
|
{8DA71B3B-5809-44E5-A018-5DE5C6FF6C2A}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{8DA71B3B-5809-44E5-A018-5DE5C6FF6C2A}.Debug|Any CPU.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{8DA71B3B-5809-44E5-A018-5DE5C6FF6C2A}.Debug|x64.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{8DA71B3B-5809-44E5-A018-5DE5C6FF6C2A}.Debug|x64.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{8DA71B3B-5809-44E5-A018-5DE5C6FF6C2A}.Debug|x86.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{8DA71B3B-5809-44E5-A018-5DE5C6FF6C2A}.Debug|x86.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{8DA71B3B-5809-44E5-A018-5DE5C6FF6C2A}.Release|Any CPU.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{8DA71B3B-5809-44E5-A018-5DE5C6FF6C2A}.Release|Any CPU.Build.0 = Release|Any CPU
|
|
|
|
|
|
{8DA71B3B-5809-44E5-A018-5DE5C6FF6C2A}.Release|x64.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{8DA71B3B-5809-44E5-A018-5DE5C6FF6C2A}.Release|x64.Build.0 = Release|Any CPU
|
|
|
|
|
|
{8DA71B3B-5809-44E5-A018-5DE5C6FF6C2A}.Release|x86.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{8DA71B3B-5809-44E5-A018-5DE5C6FF6C2A}.Release|x86.Build.0 = Release|Any CPU
|
|
|
|
|
|
{B218CBE9-ADCE-4086-9DBF-E6C782136E6D}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{B218CBE9-ADCE-4086-9DBF-E6C782136E6D}.Debug|Any CPU.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{B218CBE9-ADCE-4086-9DBF-E6C782136E6D}.Debug|x64.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{B218CBE9-ADCE-4086-9DBF-E6C782136E6D}.Debug|x64.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{B218CBE9-ADCE-4086-9DBF-E6C782136E6D}.Debug|x86.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{B218CBE9-ADCE-4086-9DBF-E6C782136E6D}.Debug|x86.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{B218CBE9-ADCE-4086-9DBF-E6C782136E6D}.Release|Any CPU.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{B218CBE9-ADCE-4086-9DBF-E6C782136E6D}.Release|Any CPU.Build.0 = Release|Any CPU
|
|
|
|
|
|
{B218CBE9-ADCE-4086-9DBF-E6C782136E6D}.Release|x64.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{B218CBE9-ADCE-4086-9DBF-E6C782136E6D}.Release|x64.Build.0 = Release|Any CPU
|
|
|
|
|
|
{B218CBE9-ADCE-4086-9DBF-E6C782136E6D}.Release|x86.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{B218CBE9-ADCE-4086-9DBF-E6C782136E6D}.Release|x86.Build.0 = Release|Any CPU
|
2021-03-31 09:43:23 +03:00
|
|
|
|
{6D20F334-B7E4-4585-854B-8A0E2B29B4AA}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{6D20F334-B7E4-4585-854B-8A0E2B29B4AA}.Debug|Any CPU.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{6D20F334-B7E4-4585-854B-8A0E2B29B4AA}.Debug|x64.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{6D20F334-B7E4-4585-854B-8A0E2B29B4AA}.Debug|x64.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{6D20F334-B7E4-4585-854B-8A0E2B29B4AA}.Debug|x86.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{6D20F334-B7E4-4585-854B-8A0E2B29B4AA}.Debug|x86.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{6D20F334-B7E4-4585-854B-8A0E2B29B4AA}.Release|Any CPU.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{6D20F334-B7E4-4585-854B-8A0E2B29B4AA}.Release|Any CPU.Build.0 = Release|Any CPU
|
|
|
|
|
|
{6D20F334-B7E4-4585-854B-8A0E2B29B4AA}.Release|x64.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{6D20F334-B7E4-4585-854B-8A0E2B29B4AA}.Release|x64.Build.0 = Release|Any CPU
|
|
|
|
|
|
{6D20F334-B7E4-4585-854B-8A0E2B29B4AA}.Release|x86.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{6D20F334-B7E4-4585-854B-8A0E2B29B4AA}.Release|x86.Build.0 = Release|Any CPU
|
2022-02-05 03:00:23 +03:00
|
|
|
|
{3DDE7064-4B68-4979-8843-FDF4CE5A5140}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{3DDE7064-4B68-4979-8843-FDF4CE5A5140}.Debug|Any CPU.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{3DDE7064-4B68-4979-8843-FDF4CE5A5140}.Debug|x64.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{3DDE7064-4B68-4979-8843-FDF4CE5A5140}.Debug|x64.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{3DDE7064-4B68-4979-8843-FDF4CE5A5140}.Debug|x86.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{3DDE7064-4B68-4979-8843-FDF4CE5A5140}.Debug|x86.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{3DDE7064-4B68-4979-8843-FDF4CE5A5140}.Release|Any CPU.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{3DDE7064-4B68-4979-8843-FDF4CE5A5140}.Release|Any CPU.Build.0 = Release|Any CPU
|
|
|
|
|
|
{3DDE7064-4B68-4979-8843-FDF4CE5A5140}.Release|x64.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{3DDE7064-4B68-4979-8843-FDF4CE5A5140}.Release|x64.Build.0 = Release|Any CPU
|
|
|
|
|
|
{3DDE7064-4B68-4979-8843-FDF4CE5A5140}.Release|x86.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{3DDE7064-4B68-4979-8843-FDF4CE5A5140}.Release|x86.Build.0 = Release|Any CPU
|
2023-01-20 20:44:30 +03:00
|
|
|
|
{7C068318-84AF-4861-9E5F-6F8A3BF38C9D}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{7C068318-84AF-4861-9E5F-6F8A3BF38C9D}.Debug|Any CPU.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{7C068318-84AF-4861-9E5F-6F8A3BF38C9D}.Debug|x64.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{7C068318-84AF-4861-9E5F-6F8A3BF38C9D}.Debug|x64.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{7C068318-84AF-4861-9E5F-6F8A3BF38C9D}.Debug|x86.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{7C068318-84AF-4861-9E5F-6F8A3BF38C9D}.Debug|x86.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{7C068318-84AF-4861-9E5F-6F8A3BF38C9D}.Release|Any CPU.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{7C068318-84AF-4861-9E5F-6F8A3BF38C9D}.Release|Any CPU.Build.0 = Release|Any CPU
|
|
|
|
|
|
{7C068318-84AF-4861-9E5F-6F8A3BF38C9D}.Release|x64.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{7C068318-84AF-4861-9E5F-6F8A3BF38C9D}.Release|x64.Build.0 = Release|Any CPU
|
|
|
|
|
|
{7C068318-84AF-4861-9E5F-6F8A3BF38C9D}.Release|x86.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{7C068318-84AF-4861-9E5F-6F8A3BF38C9D}.Release|x86.Build.0 = Release|Any CPU
|
|
|
|
|
|
{AF7722A0-D1A7-4294-A181-B88B6BD67C6E}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{AF7722A0-D1A7-4294-A181-B88B6BD67C6E}.Debug|Any CPU.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{AF7722A0-D1A7-4294-A181-B88B6BD67C6E}.Debug|x64.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{AF7722A0-D1A7-4294-A181-B88B6BD67C6E}.Debug|x64.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{AF7722A0-D1A7-4294-A181-B88B6BD67C6E}.Debug|x86.ActiveCfg = Debug|Any CPU
|
|
|
|
|
|
{AF7722A0-D1A7-4294-A181-B88B6BD67C6E}.Debug|x86.Build.0 = Debug|Any CPU
|
|
|
|
|
|
{AF7722A0-D1A7-4294-A181-B88B6BD67C6E}.Release|Any CPU.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{AF7722A0-D1A7-4294-A181-B88B6BD67C6E}.Release|Any CPU.Build.0 = Release|Any CPU
|
|
|
|
|
|
{AF7722A0-D1A7-4294-A181-B88B6BD67C6E}.Release|x64.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{AF7722A0-D1A7-4294-A181-B88B6BD67C6E}.Release|x64.Build.0 = Release|Any CPU
|
|
|
|
|
|
{AF7722A0-D1A7-4294-A181-B88B6BD67C6E}.Release|x86.ActiveCfg = Release|Any CPU
|
|
|
|
|
|
{AF7722A0-D1A7-4294-A181-B88B6BD67C6E}.Release|x86.Build.0 = Release|Any CPU
|
2017-09-20 21:54:00 +03:00
|
|
|
|
EndGlobalSection
|
|
|
|
|
|
GlobalSection(SolutionProperties) = preSolution
|
|
|
|
|
|
HideSolutionNode = FALSE
|
|
|
|
|
|
EndGlobalSection
|
Enable unit tests on .NET Core (#489)
This enables the unit tests to run on .NET Core. CodeDom compilation doesn't exist on core, so I've added the ability to compile in-process with Roslyn APIs. This still uses NUnit, using a recent version of NUnit package references with "dotnet test". This doesn't change how tests run on mono.
Finding the right reference assemblies for compilation is a bit different on .NET Core. As described in https://github.com/dotnet/roslyn/wiki/Runtime-code-generation-using-Roslyn-compilations-in-.NET-Core-App, they can either be found using packages (what the SDK does), or we can just compile against the implementation assemblies. In this change, I'm compiling against implementation assemblies, since that's fairly similar to what the tests do on mono, where they find them in the GAC.
For mono, the common references only included mscorlib. For .NET Core, I'm getting the common references from the "Trusted Platform Assemblies" (TPA) of the test process. As a result, package references of the test project become references during testcase compilation. Explicit references specified via `ReferenceAttribute` in a testcase are looked for alongside the host process's implementations as well (since we have no way to resolve a reference from just the filename since there is no GAC).
Other changes:
- Roslyn outputs the `DebuggableAttribute` by default but mcs does not, so when running on .NET Core, we don't check for the `DebuggableAttribute`.
- Check for core types in `System.Private.CoreLib` instead of `mscorlib`.
- There are some more edge cases that I'm in the process of cleaning up and will update soon.
At the moment, I'm trying to get the tests up and running, and I'm using plenty of compile-time conditions to modify the behavior on core. It would be nice not to have to do this - I haven't given it much thought, but maybe we could provide an abstraction that contains knowledge of the platform libraries, so that we don't have to have a hard dependency on `"mscorlib.dll"` and `"System.Private.CoreLib.dll"` everywhere? @mrvoorhe please let me know if you have any thoughts. Does the approach I'm taking so far seem sane to you?
@marek-safar
2019-03-26 23:05:14 +03:00
|
|
|
|
GlobalSection(NestedProjects) = preSolution
|
2020-05-07 22:44:07 +03:00
|
|
|
|
{400A1561-B6B6-482D-9E4C-3DDAEDE5BD07} = {C2969923-7BAA-4FE4-853C-F670B0D3C6C8}
|
|
|
|
|
|
{B6BEE6AA-ADA0-4E1D-9A17-FBF2936F82B5} = {C2969923-7BAA-4FE4-853C-F670B0D3C6C8}
|
|
|
|
|
|
{2C26601F-3E2F-45B9-A02F-58EE9296E19E} = {C2969923-7BAA-4FE4-853C-F670B0D3C6C8}
|
2019-11-29 19:11:09 +03:00
|
|
|
|
{96182221-C5C4-436D-9BE0-EC499F9BAF17} = {AA0569FB-73E9-4B42-9A19-714BB1229DAE}
|
2020-04-09 23:06:57 +03:00
|
|
|
|
{5A27FA80-0E28-4243-88DF-EC8A22C8BFD0} = {C2969923-7BAA-4FE4-853C-F670B0D3C6C8}
|
2020-10-27 20:02:20 +03:00
|
|
|
|
{F1A44A78-34EE-408B-8285-9A26F0E7D4F2} = {AA0569FB-73E9-4B42-9A19-714BB1229DAE}
|
|
|
|
|
|
{90D64CE4-C891-4B98-AF59-EE9B04BA1CBE} = {C2969923-7BAA-4FE4-853C-F670B0D3C6C8}
|
2021-01-15 13:41:24 +03:00
|
|
|
|
{8DA71B3B-5809-44E5-A018-5DE5C6FF6C2A} = {03EB085F-3E2E-4A68-A7DF-951ADF59A0CC}
|
2021-03-31 09:43:23 +03:00
|
|
|
|
{6D20F334-B7E4-4585-854B-8A0E2B29B4AA} = {AA0569FB-73E9-4B42-9A19-714BB1229DAE}
|
2022-02-05 03:00:23 +03:00
|
|
|
|
{3DDE7064-4B68-4979-8843-FDF4CE5A5140} = {C2969923-7BAA-4FE4-853C-F670B0D3C6C8}
|
2023-01-20 20:44:30 +03:00
|
|
|
|
{7C068318-84AF-4861-9E5F-6F8A3BF38C9D} = {8FD57ADB-B449-4960-A141-845C1E2E26EC}
|
|
|
|
|
|
{223B8007-F26C-4E28-B28D-E43C97F7EE23} = {8FD57ADB-B449-4960-A141-845C1E2E26EC}
|
|
|
|
|
|
{19C783E3-B710-4F25-A977-0ADDA4D2CFEE} = {223B8007-F26C-4E28-B28D-E43C97F7EE23}
|
|
|
|
|
|
{AF7722A0-D1A7-4294-A181-B88B6BD67C6E} = {19C783E3-B710-4F25-A977-0ADDA4D2CFEE}
|
Enable unit tests on .NET Core (#489)
This enables the unit tests to run on .NET Core. CodeDom compilation doesn't exist on core, so I've added the ability to compile in-process with Roslyn APIs. This still uses NUnit, using a recent version of NUnit package references with "dotnet test". This doesn't change how tests run on mono.
Finding the right reference assemblies for compilation is a bit different on .NET Core. As described in https://github.com/dotnet/roslyn/wiki/Runtime-code-generation-using-Roslyn-compilations-in-.NET-Core-App, they can either be found using packages (what the SDK does), or we can just compile against the implementation assemblies. In this change, I'm compiling against implementation assemblies, since that's fairly similar to what the tests do on mono, where they find them in the GAC.
For mono, the common references only included mscorlib. For .NET Core, I'm getting the common references from the "Trusted Platform Assemblies" (TPA) of the test process. As a result, package references of the test project become references during testcase compilation. Explicit references specified via `ReferenceAttribute` in a testcase are looked for alongside the host process's implementations as well (since we have no way to resolve a reference from just the filename since there is no GAC).
Other changes:
- Roslyn outputs the `DebuggableAttribute` by default but mcs does not, so when running on .NET Core, we don't check for the `DebuggableAttribute`.
- Check for core types in `System.Private.CoreLib` instead of `mscorlib`.
- There are some more edge cases that I'm in the process of cleaning up and will update soon.
At the moment, I'm trying to get the tests up and running, and I'm using plenty of compile-time conditions to modify the behavior on core. It would be nice not to have to do this - I haven't given it much thought, but maybe we could provide an abstraction that contains knowledge of the platform libraries, so that we don't have to have a hard dependency on `"mscorlib.dll"` and `"System.Private.CoreLib.dll"` everywhere? @mrvoorhe please let me know if you have any thoughts. Does the approach I'm taking so far seem sane to you?
@marek-safar
2019-03-26 23:05:14 +03:00
|
|
|
|
EndGlobalSection
|
2019-11-29 17:35:30 +03:00
|
|
|
|
GlobalSection(ExtensibilityGlobals) = postSolution
|
|
|
|
|
|
SolutionGuid = {E43A3901-42B0-48CA-BB36-5CD40A99A6EE}
|
|
|
|
|
|
EndGlobalSection
|
2023-01-20 20:44:30 +03:00
|
|
|
|
GlobalSection(SharedMSBuildProjectFiles) = preSolution
|
|
|
|
|
|
src\ILLink.Shared\ILLink.Shared.projitems*{dd28e2b1-057b-4b4d-a04d-b2ebd9e76e46}*SharedItemsImports = 5
|
|
|
|
|
|
src\ILLink.Shared\ILLink.Shared.projitems*{f1a44a78-34ee-408b-8285-9a26f0e7d4f2}*SharedItemsImports = 5
|
|
|
|
|
|
src\ILLink.Shared\ILLink.Shared.projitems*{ff598e93-8e9e-4091-9f50-61a7572663ae}*SharedItemsImports = 13
|
|
|
|
|
|
EndGlobalSection
|
2017-03-31 19:11:34 +03:00
|
|
|
|
EndGlobal
|
