nuclex-shared-dotnet/Nuclex.Windows.Forms
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Updated deependency description

Browse Source
This commit is contained in:
Markus Ewald 2024-07-25 22:28:15 +02:00 committed by cygon
parent 012fc077a5
commit 3a6b9c9dc1
2 changed files with 7 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
Dependencies.md
View File

@ -12,7 +12,7 @@ the following directory layout:
Nuclex.Windows.Forms/ <-- you are here
...
Nuclex.Support.Native/ <-- Git: nuclex-shared-dotnet/Nuclex.Support
Nuclex.Support/ <-- Git: nuclex-shared-dotnet/Nuclex.Support
...
third-party/
@ -24,13 +24,13 @@ repository (with `--recurse-submodules`).
The actual, direct requirements of the code to compile are:
* Nuclex.Support
* nunit (optional, if unit tests are built)
* nmock (optional, if unit tests are built)
* Nuclex.Support (project)
* nunit (NuGet package, optional, if unit tests are built)
* nmock (NuGet package, optional, if unit tests are built)
To Use this Library as a Binary
-------------------------------
* Nuclex.Windows.Forms.dll
* Nuclex.Support.dll
* Nuclex.Windows.Forms (project)
* Nuclex.Support (project)

2
Directory.Build.props
View File

@ -8,7 +8,7 @@
into the root 'obj' directory (instead of the intermediate directory below it),
causing one project to overwrite the other project's dependencies.
There won't be any buld warning, just suddenly one of the projects won't be able to
There won't be any build warning, just suddenly one of the projects won't be able to
access its dependencies and fail to build.
Why such a lackluster system was integrated at that level rather than just left to